235042 - '#' character (anchor) in links get converted to unreadable character

Status: VERIFIED WORKSFORME

(Core :: XPCOM, defect)

Description

[Robert Kaiser]

I could reproduce this regression on my machine with my current CVS trunk build
on Linux, as well as the current latest available Linux nightly builds from
mozilla.org, but not on the 1.7a Linux candidate builds - so the regression must
have happened since the tree opening after tagging 1.7a and yesterday, when I
first did a build that had the string branch merge and saw this happening.

Steps to reproduce:
1) Turn on manual proxy (I have a Squid proxy in use here).
2) Open http://www.kairo.at/download/
3) Click on the link titled "LCARStrek"
What happens:
The target page does load, but doesn't jumped to the named anchor.
URL bar shows "http://www.kairo.at/download/mozskins.php*LCARStrek" (The
character I replaced with * here is shown as a dotted square, i.e. an unreadable
character)

This happens on all pages that I tested when the link is pointing to an anchor
in a different page (e.g. clicking on the link to chapter 4.1 in
http://www.w3.org/TR/CSS21/) and the target page has to be fetched from the proxy.

It does perform correctly if
a) I use direct connection (no proxy)
b) the target page is in the cache (not newly fetched from proxy)
c) the link is inside the page (page is already loaded)

I normally wouldn't file this to you, but it happened after 1.7a tagging, your
checkin was the first one after that, and I pulled the first regessed build
shortly after that, before the tree was closing and reopening again.

Comment 1

[Karsten Düsterloh]

I can see a similar behaviour of TB (0.5+ (20040220)) which I believe is
actually the same problem:

This line of code (where aoTreeItem is a <xul:treeitem>)
       
aoTreeItem.setAttribute("mnenhyFlags#bak","({label:"baseURL",value:"jar:resource:/chrome/mail.jar!/content");

leads to this error at the Javascript Console:

Error: uncaught exception: [Exception... "String contains an invalid character"
 code: "5" nsresult: "0x80530005 (NS_ERROR_DOM_INVALID_CHARACTER_ERR)" 
location: "chrome://mnenhy-chroman/content/mnenhy-chroman.js Line: 976"]

Comment 2

[Karsten Düsterloh]

Ugh, cut'n'waste. :(
Should be read as:

aoTreeItem.setAttribute('mnenhyFlags#bak','({label:"baseURL",value:"jar:resource:/chrome/mail.jar!/content"})');

Comment 3

[:glob ✱]

i see this on windows 2000 and windows xp using squid.
i also confirm that bypassing squid does not cause this bug.
i don't get any errors in the javascript console.

i find that a link to any bz comment always results in the error.
ie  http://bugzilla.mozilla.org/show_bug.cgi?id=235042#c1

Comment 4

[:glob ✱]

(In reply to comment #3)
> http://bugzilla.mozilla.org/show_bug.cgi?id=235042#c1

oops, you also need to open in a new tab/window

Comment 5

[:glob ✱]

2004-02-18-08-trunk Firefox-win32.zip -- ok
2004-02-19-08-trunk Firefox-win32.zip -- broken

caused by bug 231995 ?

can someone confirm this bug and change the os to all please?

ps.  i think the unprintable character is a nul

Comment 6

[Robert Kaiser]

byron:
Thanks for confirming this happens on win32 for you. What I said in comment 0 is
that it seems to have been caused by the checkin to the bug you noted.
And no, we don't need more "I see this as well" comments. The only new thing you
added so far is that you see it on Windows. Everything else was already noted
here. What we really need is someone who finds out where the problem is
happening and make up a patch. If you can do that, then keep adding comments. If
you can't, wait for darin (or someone else) to do the work. Thanks.

Comment 7

[Karsten Düsterloh]

I repent; please see bug 16603. :(
Please ignore my comments #1 and #2.
Sorry for spamming.

Comment 8

[sleddog]

I do Windows/MinGW builds. This bug has been present in builds after Feb 19 up
to and including Mar 1. I didn't build on Mar 2. In a build I made today, Mar 3,
(CVS checkout about 9:30am Eastern) it is gone. 

Comment 9

[Darin Fisher]

marking WORKSFORME based on previous comment.  this was probably fixed by one of
the other string landing regression fixes.

Comment 10

[Robert Kaiser]

true. looks fixed here as well. nice :)