263701 - Can't load URLs with a | (vertical bar) from commandline

Status: RESOLVED WORKSFORME

(Firefox :: File Handling, defect, P4)

Description

[Nigel McFarlane]

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.

Comment 1

[Nigel McFarlane]

Attachment: trivial tag soup HTML

Comment 2

[Nigel McFarlane]

Bugger, two forward slashes are de riguer, not three.
Results are the same in both cases, however.

- N.

Comment 3

[Phil Ringnalda (:philor)]

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.

Comment 4

[Nigel McFarlane]

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

Comment 5

[Nigel McFarlane]

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.

Comment 6

[Nigel McFarlane]

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.

Comment 7

[Asa Dotzler [:asa]]

can you get us a testcase?

Comment 8

[Daniel Veditz [:dveditz]]

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

Comment 9

[Daniel Veditz [:dveditz]]

Sorry, renomination was accidental.

Comment 10

[Nigel McFarlane]

Attachment: 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.

Comment 11

[Marcelo Bastos]

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.

Comment 12

[Benjamin Smedberg]

Can I get this tested on trunk? I'm pretty sure that the command-line handling
stuff has fixed all this.

Comment 13

[Nigel McFarlane]

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.

Comment 14

[Benjamin Smedberg]

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.

Comment 15

[Ed Brandmark]

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

Comment 16

[Andrei Purice]

Marking this as Resolved > Worksforme since the issue no longer is reproducible on the latest versions of Firefox Nightly 95.0a1 (2021-10-14), beta 94.0b6 or release 93.0 on Windows 10.
If anyone can still reproduce the issue either re-open it or file a new one.