Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061125 Minefield/3.0a1 Bug 69114 taught nsFileProtocolHandler about opening .url shortcut files, but at least for current trunk and Windows XP, the results are odd, and not what I think we want. STR: In IE, open https://bugzilla.mozilla.org and drag the page proxy icon from the addressbar to the desktop, to create a .url file. Close IE, use the control panel to clear IE's cache. Open Firefox or SeaMonkey with a clean new profile, and drag-drop the file into Fx/SM. Expected and actual: see https://bugzilla.mozilla.org/ - both the content, and in the addressbar. Clear IE's cache again, open Fx/SM again, with a new profile, and bookmark the file: URL for the .url file, then select the bookmark. Actual: the page is requested, but relative URLs are resolved relative to the file: URL, so images and CSS don't load; the addressbar shows the file: URL, but has the yellow background and lock icon of a secure connection. Here's where it gets fun: clear IE's cache again, open Fx/SM again, with a new profile again, and File - Open the .url file. Expected: see bmo's content and URL. Actual: a hang, dependent on your connection speed, once the file is selected in the filepicker, then the HTML of bmo with no style or images is shown, with a file: URL in the addressbar pointing into /Local%20Settings/Temporary%20Internet%20Files/Content.IE5/ (and watching traffic or changing the .url file's URL= field to a server where you can watch request logs will verify that it's IE requesting the page). I'd think that in both the second and third cases, we'd like to get the URL= field from the .url file, and request that URL ourselves, rather than either requesting it with the wrong base URL, or having IE request it for us, wrongly.

See also bug 361847, which would like it just fine if we threw up our hands, and wrote our own cross-platform parser for .url files instead of using the Windows-only one.

Fixed by the checkin for bug 455311.