Bug 549680 comment 27: > Josh: one thing I noticed when writing this test is that other Mac apps support > sending the event with either a POSIX path or a file:// URL, whereas Firefox > requires a file:// URL. Oddly enough, the command-line "-url" flag supports a > raw POSIX path, though. This behavior is unrelated to the problems in this bug > AFAICT, but it's probably worth filing and fixing. I'd have to check an actual Firefox build, but I believe it's http://hg.mozilla.org/releases/mozilla-1.9.2/annotate/4300e79948ec/toolkit/xre/MacApplicationDelegate.mm#l343 that breaks this. I don't know if there's anything else you're trying to prevent with the if (!schemeString) part of the check, but it definitely breaks being handed POSIX paths from anywhere (which work in other Mac apps, and worked in the old Carbon AE code--and still work in the command-line code using -url, which the path is going to be passed off to by the AppleEvent code down in line 359).

(In reply to comment #0) > I don't know if there's anything else you're trying to prevent with the if > (!schemeString) part of the check And I guess if there is, you could [NSURL fileURLWithPath:urlString] any !schemeString cases and see if they turn into valid NSURLs, and then pass them on. I'm still not sure what, besides POSIX paths, you might be expecting to get here, so to me the easiest thing seems to be just to drop the (!schemeString) part and get on with it, but I dunno.

The (!schemeString) part of the check also breaks passing something like "www.mozilla.com", which the raw command-line supports and which other Mac apps (e.g., Safari, Camino) support loading via AppleEvents.