This works in the MAS 1.7.0 from a Windows cmd or dos box:
This, however, results in general wierdness:
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.
Created attachment 161645 [details]
trivial tag soup HTML
Bugger, two forward slashes are de riguer, not three.
Results are the same in both cases, however.
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.
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 |.
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
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.
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
can you get us a testcase?
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
Sorry, renomination was accidental.
Created attachment 164803 [details]
Extremely trivial test data
0. save test case in c:\tmp\hello.html
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).
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.
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.
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.
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.