390807 - Status bar does not display URL correctly when it contains composed characters

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[David D. Kilzer (ddk)]

Attachment: Screenshot of issue

* SUMMARY
When hovering over a link with URL containing a composed character (like an accented "e": é), the status bar shows some garbage characters (due to incorrect encoding?) before the accented character.

* STEPS TO REPRODUCE
1. Launch Firefox.
2. Open this bug.
3. Hover over URL link.
4. Note status bar.

* EXPECTED RESULTS
The URL in the status bar should be shown undecoded:
http://tech.groups.yahoo.com/group/testing-webkit-bug-7340/files/Uno%20Esp%80%A0%A0%E9cial%20Character/

Or it should be shown escaped properly:
http://tech.groups.yahoo.com/group/testing-webkit-bug-7340/files/Uno%20Espécial%20Character/

* ACTUAL RESULTS
See attached screenshot.

* REGRESSION
Only tested with Firefox 2.0.0.6 on Mac OS X 10.4.10 (8R218).

Comment 1

[David D. Kilzer (ddk)]

Attachment: Web page, complete of the original web page

This is the original web page where the issue was seen, and it faithfully reproduces the issue.

Comment 2

[David D. Kilzer (ddk)]

(In reply to comment #0)
> * STEPS TO REPRODUCE
> 1. Launch Firefox.
> 2. Open this bug.
> 3. Hover over URL link.
> 4. Note status bar.

The above doesn't work.  This does:

1. Download and unzip the attached web page (Attachment 275128 [details]).
2. Open the bug-390807-test.html in Firefox.
3. Hover over the "Uno Espécial Character" link.
4. Note status bar.

Comment 3

[David D. Kilzer (ddk)]

Attachment: Reduced test case

Reduced test case demonstrating the issue.

Comment 4

[David D. Kilzer (ddk)]

(In reply to comment #3)
> Created an attachment (id=275130) [details]
> Reduced test case
> 
> Reduced test case demonstrating the issue.

GRRR!  This works if the file is loaded from a local disk.

Comment 5

[David D. Kilzer (ddk)]

Attachment: Reduced test case 2

This one should work when accessed through a web server.

Comment 6

[David D. Kilzer (ddk)]

Okay, I give up trying to create a Bugzilla attachment that reproduces the issue.

It occurs on the Yahoo! Groups web site, and it will work if you download the files and open them via file:/// URLs.  :)

Comment 7

[:Gavin Sharp [email: [e-mail]]]

Have you tried a trunk build of Firefox (Minefield or one of the Gran Paradiso alphas)? IIRC this code has changed quite a bit since Firefox 2.0.

Comment 8

[David D. Kilzer (ddk)]

(In reply to comment #7)
> Have you tried a trunk build of Firefox (Minefield or one of the Gran Paradiso
> alphas)? IIRC this code has changed quite a bit since Firefox 2.0.

The Aug 03, 2007 nightly build (firefox-3-1.0a7pre.en-US.mac.dmg) still exhibits the broken behavior using a local copy of Attachment #275131 [details].

Comment 9

[Jesse Ruderman]

I'm looking at "Reduced test case 2".  

I don't know of any charsets in which %80%A0%A0%E9 decodes to either the character "é" or the combination of characters "e" and "combining acute accent" (é).  "é" is C3 A9 in UTF-8 and 00E9 in UTF-16 (from ISO-8859-1).  It can't even be represented in the testcase's character set (ASCII).  I don't think you can expect it to show up as "é" anywhere.  Is that really what Yahoo is doing?  Do other browsers display "é"?

Are you proposing that Firefox should notice that the URL is not all valid UTF-8 and display it entirely undecoded?  Is that what Safari does?

Comment 10

[Dão Gottwald [:dao]]

The Yahoo page is served as ISO 8859-1, where 0xE9 translates to é and 0xA0 to NBSP. That's what your screenshot shows correctly (and what I see in the test case, too). 0x80 is not allocated; I'm not what Firefox should display and why it displays €. Anyway, this bug is most likely invalid.

Comment 11

[David D. Kilzer (ddk)]

(In reply to comment #9)
> I'm looking at "Reduced test case 2".  
> 
> I don't know of any charsets in which %80%A0%A0%E9 decodes to either the
> character "é" or the combination of characters "e" and "combining acute
> accent" (é).  "é" is C3 A9 in UTF-8 and 00E9 in UTF-16 (from
> ISO-8859-1).  It can't even be represented in the testcase's character set
> (ASCII).  I don't think you can expect it to show up as "é" anywhere.  Is that
> really what Yahoo is doing?  Do other browsers display "é"?
> 
> Are you proposing that Firefox should notice that the URL is not all valid
> UTF-8 and display it entirely undecoded?  Is that what Safari does?

When loading "Reduced Test Case 2" (Attachment 275131 [details]), the following browsers display "http://tech.groups.yahoo.com/group/testing-webkit-bug-7340/files/Uno%20Esp%80%A0%A0%E9cial%20Character/":

- Safari 3 Public Beta v. 3.0.3 (522.12.1) in its status bar
- Opera 9.22 (3687) in a tooltip when hovering on the link
- OmniWeb 5.5.4 (v607.17) in its status bar

Firefox 2.0.0.7 behaves as seen in "Screenshot of issue" (Attachment 275127 [details]).

MSIE 5.2.3 (5815.1) shows ".../Uno EspƆÈcial Character/".

I'm not sure what MSIE 6/7 on Windows shows as I don't have a system to test with.

Comment 12

[Tyler Downer [He/Him]]

This bug is part of a query for Firefox bugs that have Status set to NEW, but have version field set to 2.0 or older and have not changed in over 800 days.

http://tiny.cc/forgottennewbugs

If you still see this bug, or if it is still valid with Firefox 3.6.10 or a firefox 4 nightly build, please update the version field and steps to reproduce.