URL: links with non-ascii characters fail to work in Mozilla 0.9.7

VERIFIED FIXED

Status

()

--
major
VERIFIED FIXED
17 years ago
16 years ago

People

(Reporter: Dan.Oscarsson, Assigned: neeti)

Tracking

({regression, testcase})

Trunk
regression, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
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

Comment 6

17 years ago
*** Bug 119120 has been marked as a duplicate of this bug. ***

Comment 7

17 years ago
Dupe was Win98. Seeing also on Linux.

Setting Platform: All, OS: All
OS: Solaris → All
Hardware: Sun → All

Updated

17 years ago
Keywords: regression
pushing over to Networking, who regressed this.
Assignee: attinasi → neeti
Component: Layout → Networking
Keywords: testcase
QA Contact: petersen → benc

Comment 9

17 years ago
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.
Keywords: testcase
QA Contact: benc → petersen

Comment 10

17 years ago
Created attachment 64330 [details] [diff] [review]
fixes regression

We still need the ExtractUrlPart, changing the return values to NS_OK works.

Comment 11

17 years ago
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

r=brendan@mozilla.org -- darin, can you check in?

/be
Attachment #64330 - Flags: review+

Comment 13

17 years ago
fixed-on-trunk
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 14

17 years ago
*** Bug 120295 has been marked as a duplicate of this bug. ***

Comment 15

16 years ago
VERIFIED:
mozilla 1.1, win 98.
single plat verification b/c this is untargeted.
will becomea testcase. 
Status: RESOLVED → VERIFIED
Keywords: testcase
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.