304000 - URLs with commas handled incorrectly

Status: RESOLVED WORKSFORME

(Firefox :: Shell Integration, defect)

Description

[Mark Knoop]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b3) Gecko/20050729 Fedora/1.1-0.2.5.deerpark.alpha2 Firefox/1.0+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b3) Gecko/20050729 Fedora/1.1-0.2.5.deerpark.alpha2 Firefox/1.0+

Deer Park seems to mishandle URLs passed from the commandline or from other
applications incorrectly. The URL is clipped at the first comma, usually
resulting in a 404 error. 

Reproducible: Always

Steps to Reproduce:
1. Pass a URL with a comma, eg: firefox http://www.guardian.co.uk/0,6961,,00.html
2. Deer Park opens http://www.guardian.co.uk/0 - resulting in an error page.

Actual Results:  
Redirected to the site's error page. 

Expected Results:  
Opened the correct page - in this case the Guardian's home page.

The URL is handled correctly when entered directly into the address bar. I first
noticed the bug when opening links from Liferea (an rss aggregator). This
behavior occurs with both the firefox-1.1-0.2.5.deerpark.alpha2 rpm from fedora
rawhide and with the Deer Park Installer from mozilla.org. Quoting the URL or
escaping the commas does not work either.

Note that firefox 1.0.6 handled these URLs correctly, as do epiphany, mozilla
and konqueror.

Comment 1

[Jaime Mitchell (use [e-mail] for email)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050808
Firefox/1.0+ ID:2005080806

WFM

Does it occur in firefox safe mode? What about todays trunk build?

Comment 2

[Uri Bernstein]

WFM on Mac OS X (opening the provided link from Thunderbird).
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050808
Firefox/1.0+
So this may be a Linux-specific problem.

Adding "regression" keyword per description.

Comment 3

[Mark Knoop]

Just tried today's trunk build and it works fine again.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050809 Firefox/1.0+

Comment 4

[Bob Clary [:bc] (inactive)]

(In reply to comment #3)
> Just tried today's trunk build and it works fine again.
> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050809 Firefox/1.0+

Cool -> WFM.

Comment 5

[Christian Nolte]

It seems that 1.5 RC3 has this problem again. I am using Linux, Fedora Core 4 and Mozilla Firefox 1.5 RC3 and opening links like the original reporter wrote, lead to "cut off" URLs.

Comment 6

[Mark Knoop]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051125 Firefox/1.5

That's strange - it's still working for me.

Comment 7

[Christian Nolte]

Sorry, I forgot the version information:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051118 Fedora/1.5-0.5.0.rc3 Firefox/1.5

Seems that this is an older build of Gecko.

Comment 8

[Florian E.J. Fruth]

got the same problem here with firefox-1.5. i also tried with '' and "" - but it's not a solution.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051130 Firefox/1.5
Gentoo Linux (www-client/mozilla-firefox-1.5 -debug -gnome +ipv6 -java -mozdevelop -mozsvg +xinerama -xprint)

Comment 9

[Christian Nolte]

Even the release version shows the same problem:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051201 Fedora/1.5-1.1.fc4.nr Firefox/1.5

I guess this BUG should be reopened.

Comment 10

[Mark Knoop]

The official mozilla builds seem to work but the bug is evident in the nrpms release in comment #9. Two possibilities:

1. Official builds are built with gcc 3.3.2; nrpms release with gcc 4.0.2

2. The builds have different configure arguments:

official build: --enable-application=browser --enable-update-channel=release --enable-update-packaging --disable-debug '--enable-optimize=-Os -freorder-blocks -fno-reorder-functions -gstabs+' --disable-tests --enable-official-branding --enable-default-toolkit=gtk2 --enable-xft --disable-freetype2 --enable-svg --enable-canvas --enable-static --disable-shared

nrpms release: --enable-application=browser --with-system-nspr --with-system-jpeg --with-system-zlib --with-system-png --with-pthreads --disable-tests --disable-debug --disable-installer '--enable-optimize=-Os -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32 -march=i386 -mtune=pentium4 -fasynchronous-unwind-tables' --enable-xinerama --enable-default-toolkit=gtk2 --disable-xprint --disable-strip --enable-pango --enable-system-cairo --enable-svg --enable-canvas --enable-official-branding

Perhaps someone more knowledgeable could spot a likely culprit here.

Comment 11

[Mark Knoop]

See also: http://bugzilla.atrpms.net/show_bug.cgi?id=687

Comment 12

[Mike Connor [:mconnor]]

Please file a new bug about the root cause once the issue with the nrpms build is determined.  Downstream packages may have any number of issues, aside from build-config they may have additional patches applied, and we can't track those.  If there is a code-level issue at fault, please file a bug against the appropriate component once the downstream packager has an idea of the problem.

Comment 13

[Matthew Hall]

Chalk up another WFM (nrpms maintainer).

The guardian url comes up fine in my build on i386 and ppc (haven't tested x86_64).

Which makes me think it's a local settings issue (or one of those terribly irreproducable bugs).

It also works for a new user (ie. not something it's picked up from an change made in an old version).

Comment 14

[Mike Connor [:mconnor]]

I have a feeling this is actually related to using -remote instead of just passing the URL, there's a bug that was recently fixed about that.

Comment 15

[Matthew Hall]

A bit more information on this. my last comment was from trying to enter the url into the address bar (which works).

The problem is specific to a) opening the url as an argument (from the command line or passed via another program) and b) already having firefox open (ie, how mozilla-xremote-client is parsing the 'openurl'.

So, to reproduce:

1) open a terminal and execute "firefox http://www.guardian.co.uk/0,6961,,00.html"
2) open another terminal and execute the same command.

The first window (opened with /usr/lib/firefox-1.5/firefox) will work fine; the second (opened with /usr/lib/firefox-1.5/mozilla-xremote-client) should be broken.