Note: This fails in Mozilla 0.9.7 build using Sun's Forte 6 update 2 compilers on a Sun Ultrasparc system using full optimization. It worked fine in 0.9.6 built using the same compilers. If you have a web page like this: <html> <head> <title>X</title> </head> <body> <A href='inställningar'>Inställningar</A> <BR> <A href='installningar'>Inställningar</A> </body> </html> The first link does not work. It is not underlined, it cannot be activated. It looks like text. Tests show that removing the non-ASCII character as in the second link in the above page, it works as usual. So it looks like between version 0.9.6 and 0.9.7 something was changed so that Mozilla no longer can handle non-ASCII in URLs. This makes our site unusable. Sometimes links with non-ascii characters work, and later suddenly gets corrupted after some reloads or back/forward between pages. It is probably chached pages that fails. Unless the above failure is due to my using very high optimisation (-xO5 -fast) when compiling, this need to be fixed before Mozilla can be used again.
Interesting... DOM Inspector shows the <A> node with that text inside, but the list of style rules applied to that node does not include the *:link and *:-moz-any-link rules....
It's not merely the presence of the character -- it must be in the first part of the URL, or something like that. If I add "http://www.foo.com/" to the beginning of the URL, the link is recognized. I wonder if something got messed up in NS_MakeAbsoluteURIWithCharset that caused nsILink::GetHrefCString to return null? Could this be related to the changes for bug 102656?
Yes, this is a regression from the patch to bug 102656.
Is this bug assigned to the right person? William and/or darin, can you help unregress? /be
*** Bug 119120 has been marked as a duplicate of this bug. ***
Dupe was Win98. Seeing also on Linux. Setting Platform: All, OS: All
OS: Solaris → All
Hardware: Sun → All
pushing over to Networking, who regressed this.
Assignee: attinasi → neeti
Component: Layout → Networking
QA Contact: petersen → benc
With the given test case, the following line is reached, i.e. NS_NewURI has failed, presumably due to it being a non-absolute url (but ExtractUrlPart() did succeed). http://lxr.mozilla.org/seamonkey/source/content/shared/src/nsHTMLUtils.cpp#101 How about doing away with the ExtractUrlPart and return NS_OK when NS_NewURI fails.
QA Contact: benc → petersen
Created attachment 64330 [details] [diff] [review] fixes regression We still need the ExtractUrlPart, changing the return values to NS_OK works.
Comment on attachment 64330 [details] [diff] [review] fixes regression sr=darin of course!! thanks william :-)
Attachment #64330 - Flags: superreview+
Comment on attachment 64330 [details] [diff] [review] fixes regression email@example.com -- darin, can you check in? /be
Attachment #64330 - Flags: review+
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
*** Bug 120295 has been marked as a duplicate of this bug. ***
VERIFIED: mozilla 1.1, win 98. single plat verification b/c this is untargeted. will becomea testcase.
Status: RESOLVED → VERIFIED
QA Contact: petersen → benc
Summary: links with non-ascii characters fail to work in Mozilla 0.9.7 → URL: links with non-ascii characters fail to work in Mozilla 0.9.7
You need to log in before you can comment on or make changes to this bug.