Your browser is not supported.

So I found another sort-of issue with Snow Leopard today. It used to be, in Leopard, that I could open up a bunch of images at once in Preview.app by just highlighting all the images in Finder, then either dragging them to the Preview icon in the dock, or by selecting Open With > Preview.app from the contextual menu (or, yes, typing ⌘O). I discovered that when I tried to do the same in Snow Leopard, only a few of the images would open up, and oddly, at that—if I tried to open, say, 30 images, only the first one of them would open in one window, and then the 2nd would open in a separate window. If I tried again, then 2 would open in one window, and the 3rd in a separate one, and so on.

Very strange. After some Googling, I found out that my problem was being caused by the fact that these particular images I was trying to open had been downloaded from the internet. Now, you’re no doubt familiar with the fact that Mac OS X tags every file you download so that when you try to open it for the first time, it asks you if you’re sure you want to open the file, since it’s been downloaded from the internet. The way this is accomplished is by setting an extended attribute (com.apple.quarantine) on the file itself, so that the OS knows to display the “Are you sure?” warning.

So the solution to the opening-multiple-downloaded-images problem is to run the following command in Terminal, inside the folder the affected images are in:

xattr -d com.apple.quarantine *.jpg

Where of course you’d replace the “jpg” with the correct extension. You can also run the command on directories and their contents recursively:

xattr -rd com.apple.quarantine <directory-name>

Now Preview behaves as I expect it to. Yay!

Update 2009/10/29 11:18—Updated the path on the final setuid command per commenter David.

If you use a Mac as your work machine, chances are that you’ve had to use VPN at some point, and therefore the current de facto SSL VPN client, Juniper Network Connect. If you’ve recently upgraded to Snow Leopard, you’ve probably already run into the problem of NC not working correctly, and likely found the common solution to fixing the problem.

This solution works great if you’ve got a fully functional installation of NC, but what happens if your installation has become corrupted on Snow Leopard? What if, for example, some of the installation files are corrupted or missing, but some aren’t? That’s what happened to me, and here’s how I fixed it.

(more…)

Ran into this one today, in somewhat unique circumstances: I had a hover style where buttons inside a table row only appeared when the mouse was over the row, and if you clicked on one of the buttons but moved the mouse into another row before releasing the mouse button, the previous row would stay highlighted.

The authoritative writeup of the bug, and most others, refer to the problem happening with dynamically-displayed submenus, but make little mention of my particular problem. There was some hope that triggering hasLayout would fix the problem, as it’s the closest thing we have to a magic bullet, but it (shocker!) didn’t work for me.

What did work for me was reverting back to the brute-force method one had to use for older versions of IE: using JavaScript onmouseover/onmouseout events to trigger a hover style¹ rather than the :hover pseudoclass. So much for IE7 implementing :hover on non-anchor elements. Sigh.

¹ See the first comment. And shame on you, Webmaster World, for not having permalinks to the comments. Get a load of their generated source, too: they’re still using font tags. Seriously?! And this is a resource for webmasters? Come on.

In these times of effectively unlimited quotas, there’s no need to ever delete email. And I don’t—all my various accounts’ inboxes combined add up to somewhere around 20,000 emails. Having all your emails is great, but accessing them quickly is at least as important as having them on hand. However, of late, I’d been experiencing some severe performance problems in Mail.app—it was taking literally on the order of minutes for Mail to start up and shut down for me. Just brutal.

Today, in an effort to alleviate some of that pain, I stumbled across a solution that worked magnificently for me: cleaning up Mail.app’s SQLite database.

Here’s how you do it:

1. Quit Mail.app.
2. Launch Terminal, then type cd ~/Library/Mail/.
3. Back up Envelope Index in whatever fashion you prefer. I did cp Envelope\ Index EnvelopeIndexBackup.
4. Open Envelope Index with SQLite: sqlite3 Envelope\ Index. At the sqlite> prompt, type: vacuum subjects;. Once the prompt returns, type Ctrl-D or .exit to quit SQLite.

This reduces the size of Mail.app’s database and cleans it up, usually to dramatic effect. I reduced my database from ~34 MB to ~22 MB, and Mail now starts up in seconds, not minutes. Boom!

References: procedure and information about the vacuum statement.

So I was just trying to figure out how to center an image inside a div with hidden overflow when the image is larger than the div, and it turns out it’s not as easy as you think. Vertical alignment is easy using vertical-align: middle. However, giving the div container text-align: center, for example, doesn’t work—the image’s left edge still aligns with the left edge of the div. After a little Googling, I found this rather ingenious solution.

<style type="text/css">
  .centre
  {
    position: relative;
    margin: 100px auto;
    width: 200px;
    height: 150px;
    overflow: hidden; /* the centered bigger image's overflow is clipped at all four sides */
    background:#cfc;
  }

  .centre span
  {
    position: absolute; /* makes block-box wrapped around its content */
    top: 50%; /* absolute %-unit referes to the selector's first positioned ancestor */
    left: 50%; /* places the selector's top left corner in the centre of the container div */
  }

  .centre img
  {
    position: relative; /* does not move the original object, positions the image of it */
    top: -50%; /* relative %-unit referes to the selector itself */
    left: -50%; /* places the centre of itself in its original top left corner position */
  }
</style>

<div class="centre">
  <span><img src="image.jpg" alt=""/></span>
</div>

Follow the link to see the code snippet in its entirety, but in short what you do is that you wrap the image inside a span that is absolutely positioned at top: 50% and left: 50%, so that its top left corner is placed in the exact center of its parent, the div with the overflow. Then you relatively position the image so that its top and left are both -50%, et voilà, you have a centered image! Brilliant!

I’ve made no secret of the fact that I’m no fan of Adobe products, especially the bloated, sluggish Adobe Reader—unless I want to fill out PDF forms, it’s of absolutely no use to me when Preview does everything I need, faster and better.

So when I installed Leopard from scratch on my personal laptop, I decided that under no circumstance would I install Adobe Reader. Problem was, every time I tried to open a PDF in Safari, I’d get a dialog box prompting me to choose an Adobe product to view the PDF in—and to add insult to injury, all non-Adobe products were not selectable.

When I obviously couldn’t choose Adobe Reader and clicked Cancel, the Safari window would just go grey and sit there, forcing me to download the file^* and open it in Preview if I wanted to view it, even though Safari was supposed to support inline PDF viewing as of Tiger.

As you might imagine, this drove me ABSOLUTELY BATTY. Gnashing teeth, foaming mouth, shaking fist, the whole enchilada. ARGH. <pause for deep breathing exercises />

Anyway. This state of affairs was mildly irritating, so I was pretty happy (okay, okay, I did the Snoopy dance) when I found out how to fix this problem this morning. You need to do two things:

1. Go to /Library/Internet Plug-Ins and remove AdobePDFViewer.plugin.
2. Open up Terminal and type

   defaults write com.apple.Safari WebKitOmitPDFSupport -bool false

   at the prompt. This ensures that Safari will open PDFs rather than forcing Preview to.

What I can’t figure out is how the PDF viewer plugin got installed on a vanilla Leopard installation. I suspect it happened when I installed Photoshop. Sneaky bastards. (cf. reference 1, reference 2)

^* That is, if the referring web page didn’t redirect through some dumb download script, but don’t even get me started on that.

If you have WordPress 2.5, chances are you’ve run across the media upload problem. As for me, I didn’t so much run across it as into it. At 100 miles an hour.

A brief background on the problem: it’s not that uploads don’t work at all, but that the asynchronous Flash uploader doesn’t work—in fact, you can disable the Flash Uploader and go back to the old one-at-a-time upload method if nothing else works for you. Every time you try to upload a file or batch of files, you get the nondescriptive “http error” message and the file upload fails. Most of the time this is caused by a configuration problem on your webserver.

Now, for most people a workaround listed on the official WP support topic will fix the issue. But—wait for it—not me. I’d been breaking my head against the problem for the better part of two full days before finally getting the Flash uploader working just a little while ago.

I won’t bore you with the troubleshooting details, but my problem wasn’t that the mod_security module was causing a problem, or that my uploads folder didn’t have the right ownership/privileges. It was the fact that the entire WP installation was protected by HTTP authentication such that only a few users on our work server could access it. Since Flash is entirely incapable of authenticating uploads, all attempted file uploads were failing.

Specifically, two files in the WP installation were getting 401 Authentication Required errors: wp-admin/async-upload.php and wp-admin/admin-ajax.php. To fix this problem, you need to (in addition to disabling auth for the wp-content/uploads folder) add the following lines to an htaccess file in the wp-admin directory:

# Disable HTTP authentication for Flash uploads
<FilesMatch "(async-upload|admin-ajax).php">
  Allow from all
  Satisfy Any
</FilesMatch>

This solution, of course, assumes that your webserver allows htaccess file overrides.

this ALA article about conflicting absolute positions changed my life. No, really.

And on the subject, here’s an intriguing new CSS layout technique: faux absolute positioning.

Update 2009/09/12 09:19—The jQuery version of the dynamic z-index function has been optimized to use hover instead of mouseover/mouseout. Thanks to commenter Eric Conner for pointing out my mistake.

Update 2009/08/04 22:22—The jQuery version of the dynamic z-index function has been added.

Update 2009/07/09 10:52—The code has been updated to make use of the latest innovations in the Prototype library, and to take suggestions from commenters into account.

Now that we’ve officially transferred support of our big application from IE6 to IE7, I’ve been spending more and more time delving into the nitty gritty details of making that hugely complicated layout (recently made less complicated, but that’s another blog post) work in IE7.

I had thought, initially, that IE7′s superior CSS support would make my life a lot easier, and it did in some ways: my IE7-specific stylesheet is a fraction of the size of the IE6-specific one, and the ability to use attribute selectors is huge for me. But as I should have expected, I just traded one set of headaches for another. While IE7 is far superior to IE6 in terms of CSS support (and far inferior in other ways, user interface chief among them—but that’s another blog post, too), the bugs that still exist are more subtle and far more difficult to work around.

The IE z-index bug had been around since IE4 or 5, and was finally fixed in IE8. It’s still an issue in IE7, however, and chances are that you, the web developer, still have to support it. You should read Aleksandar Vacić’s in-depth characterization of the problem to really understand what’s happening, but what it boils down to is this: the CSS 2.1 spec says that a positioned element with any integer z-index value (i.e. not auto) should create its own zero-based stacking context, and use the integer value specified to decide its place in its parent stacking context. In other words, if the positioned element has a z-index of auto, its stacking context is inherited from its parent. Internet Explorer, however, creates a new stacking context for elements with any z-index value, including auto, which wreaks all kinds of havoc and generally causes mayhem in your previously neat and orderly layouts.

(more…)

So I’ve been piloting del.icio.us this week to see if we can use it at work as a common bookmark bucket, and I just found something very cool there. According to this, you can combine PDFs in Mac OS X without using (read: paying an exorbitant price for) Adobe Acrobat Distiller:

Launch Automator. Click on Finder > Get Selected Finder Items and add to the right. Add “Sort Finder Items” too. Click on PDF>Combine PDF Pages and click “Appending”. Then add “Open Finder Items”. Save it as a Plug-In called “Combine PDFs”.

After all that, select your PDFs with Contro-Click, then in your menu, you’ll see Automator>Combine PDFs. Click that and you’ll see your combined PDFs.

(sic) Neat-o mosquito.