This works in the MAS 1.7.0 from a Windows cmd or dos box: mozilla "file:///C|/tmp/test.html" This, however, results in general wierdness: firefox "file:///C|/tmp/test.html" Two tabs are opened, one seemingly random, the other blank. The specified file is not displayed. This affects anyone who rolls up Firefox inside a .BAT file or who invokes Firefox from the commandline. Expected results: as for the MAS.
Bugger, two forward slashes are de riguer, not three. Results are the same in both cases, however. - N.
Two slashes or three, if you change the | (which Firefox uses to separate the URLs of multiple homepages) to a :, it WFM - it apparently doesn't care if you have a colon in your commandline argument.
Sure, but: 1. It works with both : and | in the location bar, so that should be uniform everywhere. 2. : is a reserved character according to RFC 2396. While we might support its accidental use, we should definitely support the semi-official (and historic) encoding, which is |. - N
I've been testing this bug for a little while, and there are no workarounds for chromeless windows. These can't work: firefoxPR1 -chrome 'file://C|/tmp/test.html' firefoxPR1 -chrome 'file://C|/tmp/test.xul' You can't open chrome this way at all; window-less zombie firefoxes or default browser windows result. Confusion is rife. See related bug 133700, bug 235924. My assessment is that Windows programmers who take XUL for a test run this way will hit this bug straight off. Their first experiment will fail, Mozilla's reputation will be destroyed, and they will go elsewhere, lost for good. Example feedback: "for four hours I beat myself senseless trying to get an example to work before I gave up in disgust" This bug affects a developer community larger than that of Linux or Mac. My sole request for the 1.0 radar. A severe stability problem technically. A terrible problem for the command line user. A bug that prevents users from creating Windows shortcuts to content held locally. - N.
Severity: normal → critical
More testing. The following command line will sometimes work for Firefox: firefox -chrome file:///C:/tmp/test.html If other combinations are used, Windows seems to becomes confused and all combinations then stop working. If this happens, a reboot is required. - N.
can you get us a testcase?
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Double slash is technically not correct. In the windows shell you need to escape the pipe symbol (quoting doesn't appear to be sufficient). firefox file:///C:/tmp/test.html worked for me firefox file:///C\|/tmp/test.html also worked, but opened an extra window
Flags: blocking-aviary1.0- → blocking-aviary1.0?
Sorry, renomination was accidental.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Created attachment 164803 [details] Extremely trivial test data Test procedure. 0. save test case in c:\tmp\hello.html 1. reboot. 2. open dos box. 3. cd "program files" 4. cd "firefox" 5. firefox "file:///C|/tmp/hello.html" 6. Note 2 tabs are opened, neither containing hello.html. Expected behaviour: one window showing hello.html The other considerations in this bug are fallout from this behaviour, and from the other bugs noted (until further notice). - N.
Attachment #161645 - Attachment is obsolete: true
I, and other users of the Notetab text editor, have been noticing a problem that, for all we know, is the same bug. Basically, if Notetab calls Firefox to preview a HTML file, we get the described behavior -- i.e., two tabs, one blank, the other with some unrelated web page. Notetab uses the standard Windows syntax, that is, "C:\Program Files\Mozilla Firefox\Firefox.exe C:\dir\file.html" Further testing uncleared a few more things that may be neccessary for the bug to manifest itself: 1- If FF is already opened when the command is invoked, it behaves as expected -- opening a new tab with the desired file. 2- First reports indicated that Seamonkey was not affected -- but then I tried CLOSING the "Quick Launch" icon in the system tray. With Seamonkey not pre-loaded, the bug appeared, the same as Firefox. 3- Some users reported that making Firefox the default browser might help.
Can I get this tested on trunk? I'm pretty sure that the command-line handling stuff has fixed all this.
Assignee: bugs → benjamin
Status: ASSIGNED → NEW
Tested with firefox trunk nightly (zip distribution): Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050406 Still a problem with this build. - N.
The problem is the | (vertical bar), not the file URI, and it is caused by code in browser.js which uses | as a separator for multiple-tab default homepage.
Severity: critical → major
Priority: -- → P4
Summary: Can't load file: URLs from commandline → Can't load URLs with a | (vertical bar) from commandline
Target Milestone: --- → Future
Version: 1.0 Branch → Trunk
This issue happens not only from the command line but also from any client application that launches a browser. This happens with the AIM client in Windows with any URL that contains a | (vertical bar) In the case of an URL with many | (vertical bars) it opens many tabs. An example URL is: This can often be replicated by opening an AIM Client and clicking on an ad at the top. http://twx.doubleclick.net/click;h=v5|33a7|0|0|%2a|t;20526393;0-0;0;11626181;458-175|45;12357049|12374945|1;;~sscs=%3fhttp://servedby.advertising.com/click/site=707867/zpcd=11111/bnum=111111
You need to log in before you can comment on or make changes to this bug.