Jaharmi’s Irreality renewable hyperlinks with 0% transfat since 1999

As you may know, I absolutely live to submit crash and bug reports to vendors.

Normally, these reports are staid affairs involving copious amounts of detail, exquisite reproduction steps, and both expected and actual results. I’m sure that these kinds of reports get a certain amount of attention from software developers. I say that with confidence because at least one person in that position has told me my bug reports are his favorite. Sure, it was a few years ago now, but I’m sure I’ve still got some mojo.

Occasionally, I get the opportunity to take some creative license with these submissions. For example, there was that one involving the hockey game. The standard was raised after I saw my current all-time favorite crash report.

So, when I had a particularly frustrating crash in Safari, I decided I needed to raise my game. After all, I’ve probably submitted 33 boring crash reports on Safari already. Here’s what I came up with this time:

For those of you reading with Lynx, the text of the submission was:

Safari was launched by me. It had tabs. The set of tabs evolved. They were created to help me. There were so many of them there may have been copies. And I had a plan for them.

I hope someone enjoyed this crash report. And, for all I know, they fixed the problem in Safari 5.0.3.

It’s certainly an understatement to say that there’s been a lot of talk about the Adobe Flash Player on Apple platforms in the last year. On Mac OS X, Apple bundles the Flash Player and tends to distribute some — but not all — updates to it.

I wanted compare the bundled Flash Player version against the latest version from Adobe, which is currently v10.1.82.76. So, let’s look at what comes with Snow Leopard from the perspective of a codesigned executable.

A quick look at the bundled plugin shows that it is codesigned. This means that it has a known signature. If the executable is modified, the signature will no longer be valid. The signature is tied to the identity of a signing authority, which is generally the source of the software.

It may be helpful to think of codesigning as a tamper-resistant seal from the manufacturer. It’s not going to protect you from lots of different kinds of vulnerabilities, but if its cryptographic signature is intact and valid, you have a good idea that the software hasn’t been modified by a third party.

Mac OS X Leopard and Snow Leopard have shipped with applications signed by Apple. The Flash Player plugin comes from Adobe. So, who signs the bundled Flash Player?

You’d be forgiven for not having your eye drawn to the answer immediately, but it’s right there on the “Authority” lines. Just as with the rest of Mac OS X, Apple signed the Flash Player plugin they bundled with the OS.

Now, let’s upgrade the plugin to the latest version available from Adobe and see what happens to the signature. Courtesy of Preston’s WatchedInstall tool, we can see that the plugin’s CodeResources file is removed during this upgrade. Interestingly, the “Adobe Flash Player Install Manager” application installed with the update is codesigned.

The newer Flash Player version, however, seems to consist of two new plugins contained within the overall structure of a parent plugin. Neither the parent nor the new applications within the same bundle install a new code signature. This results in three unsigned executables:

Therefore, you trade the known security vulnerabilities of the older version of Flash Player bundled with the operating system with a different kind of security problem with the new version. It would be silly to not make that trade if you are browsing the Web at all on a Snow Leopard-based computer.

However, it’s also difficult to understand why a large corporation with the resources of Adobe cannot codesign a piece of software as critical to the Mac OS X browsing experience as the Adobe Flash plugin is — especially when its “Install Manager” application is signed.

It’s also puzzling why Apple continues to trail well behind the latest releases of Flash Player. Add to that mystery the question of why Apple never updates the absolutely antique bundled version of the Shockwave Player plugin.

I’ve long had a problem with the search fields that are omnipresent in the toolbars of so many Mac OS X applications. My problem? I wanted to quickly jump up to them so I could enter text directly, but I wanted to do so with a keyboard shortcut.

This is particularly true in Safari and Keychain Access, two applications where I frequently want to use the toolbar search field.

It turns out that I was too lazy to look for it, and the option is labeled in a misleading way. I’ll admit, I just plain missed the keyboard shortcut.

The command can be labeled as “Find” where I’ve seen it. It may vary and carry some additional text, as in Safari where it is “Google Search” and MarsEdit where the label is “Search Weblogs,” both of which make sense when the resulting action is to jump to the search field. In both of these applications, the command is in a submenu under Edit > Find.

In Keychain Access, it’s just “Find” — so it doesn’t even match the label on the “Search” field it sends cursor focus to.

The keyboard shortcut is Option-Command-F, and appears as ⌥⌘F.

It’s sad when you can’t find the “Find” command, isn’t it? Grin.

I recently took a trip to Seattle, and reminded myself of a useful practice I’d developed a while ago. When I’m traveling, I collect import URLs for that trip in my browser — URLs for my organization’s travel booking/information system, airlines, hotels, maps, conference information, etc. — and put them in Safari’s Bookmarks Bar.

It’s pretty easy to collect them:

1. Right-click on the Safari Bookmarks Bar. (If it’s not on, enable it with View > Show Bookmarks Bar.)
2. Choose “New Folder” from the pop-up contextual menu.
3. Enter the name of the folder in the sheet that slides down from the Safari browser window. I usually name it something short (because despite having widescreen displays, I want to conserve space in my Bookmarks Bar) that reminds me of the trip.
4. Visit a site that I want to bookmark for the trip.
5. Add a bookmark for that site, either by:
• clicking the “+” button in the Safari toolbar when I’m there, and then choosing which folder to put it in from the list of folders in the pop-up menu, or by
• clicking the proxy icon in the URL field, and dragging it onto the folder in the Bookmarks Bar.
6. Repeat the last two steps for each site relevant to the trip.

The resulting bookmarks can be rearranged, if necessary, in Safari’s bookmarks editor. (It’s the “open book” icon in the Bookmarks Bar.)

The entire group of pages can be opened all at once by clicking-and-holding on the folder in the Bookmarks Bar. When the menu drops down for the folder, choose the last command: “Open in Tabs.” This opens all of the sites bookmarked in the folder in separate tabs in the Safari window. I find that it’s useful to have them all open while I’m traveling to my destination, since that way I can see them even if I can’t get an Internet connection — free Wi-Fi is not always available.

When I’m done with the trip, I can delete the entire folder or just some of the bookmarks it contains. To delete the folder quickly, right-click on its name in the Bookmarks Bar and choose “Delete” from the contextual menu.

Frankly, I had utterly ignored drag and drop tabs in Safari. This feature didn’t work in older versions of the app and only appeared in Safari 3, so I hadn’t yet adjusted to it. The recent article on tag dragging modes at Daring Fireball comes about a week after my own interest in the feature suddenly piqued.

So, yes, drag and drop for tabs appeared relatively late in Safari’s development. I fail to use this feature even though I’ve wanted it for a long time. Together, these facts buttress my conviction that certain features need to be in a product on day one, or they will not get used. I refer to this as the “PageMaker window” problem, for it wasn’t until PageMaker 6-ish that you could open up more than one document at a time in PageMaker. By that time, I’d been using PageMaker for long enough that I had user interface scar tissue built up around the single-window limitation. Even though I had a feature I wanted, it was left unused most of the time.

Even if I did want to use tag drag and drop, its behavior in Safari is weird. I probably wouldn’t have taken the time to understand what was going on if it hadn’t been for the DF post. Or, at least, I wouldn’t have realized there were different modes at all. (It’s like user-interface-by-Zork-text-adventure. You have to discover the odd set of steps — which make some sense in hindsight — that drops the critical key from the keyhole onto the placement you’ve carefully slid under the door.)

My own experience with Safari 3 has shown that if the tab is the leftmost one in a Safari window, dragging it in any direction results in both the inter- and intra-window drag behavior described on DF. That’s the only tab position that works in this manner, though.

I also thought that holding down Option or Command during a drag would make a difference; I could swear that happened last week when I tried drag and drop, but I must be wrong. I can’t reproduce it today.

Update: There’s an older article at Betalogue that describes tab drag and drop, and mentions the behavior of the first tab.