225845 - Unescaping URLs for status bar display could be more intelligent

Status: NEW

(SeaMonkey :: UI Design, defect)

Description

[Jason Summers]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6b) Gecko/20031114
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6b) Gecko/20031114

When Mozilla displays a URL in the status bar, it blindly unescapes every
occurrance of '%XX', without regard for whether doing so is likely to change the
meaning of the URL or not.

Ostensibly, the unescaping is done primarily for international users, so that
non-ASCII characters can be displayed unescaped (see bug 150620). (Or is it just
a side effect of some mailto URL logic? -- see bug 60178.) I'll concede that,
but it doesn't explain why special characters like %23 (#) and %25 (%) are
unescaped.

I think that, when two URLs are likely to have different effects, some
reasonable attempt should be made to make them be displayed differently in the
status bar.

Sequences that should always stay escaped include:

 %23 (#)
 %25 (%)

Sequences that should stay escaped when they occcur before the '?' include:

 %2F (/)
 %3F (?)

Sequences that should stay escaped when they occur after the '?' include:

 %26 (&)
 %3D (=)
 %2B (+) (unless + is unescaped to ' ', or converted to '%20')
 %3B (;) (maybe. sometimes used as a substitute for &)

Also, if URL ends in a space, maybe it should always be shown escaped.


Reproducible: Always

Steps to Reproduce:
Hover mouse over links on attachment; observe status bar.
Actual Results:  
Status bar indicates that URLs are exactly the same.

Expected Results:  
URLs should be displayed differently in status bar -- certain characters should
not be unescaped.

Comment 1

[Jason Summers]

Attachment: test case

Comment 2

[Boris Zbarsky [:bzbarsky]]

> Ostensibly, the unescaping is done primarily for international users

You make it sound like people are lying to you.  They're not.

> Or is it just a side effect

It's not.

> I'll concede that, but it doesn't explain why

Because the URL string is just run through a "unescape URL" function that
unescapes all %-escapes.

> I think that, when two URLs are likely to have different effects

What would be the benefit of that (and your other demands) to users?

Comment 3

[Jason Summers]

It's just a suggestion. If the way I phrased this report seemed overly
antagonistic, then I apologize.

Most users never look at the URL, so it would be of no benefit to most users.
But for those users, there's no reason to display the URL at all. For users who
do sometimes look at the URL, the benefit would be a more accurate forecast of
what will happen if they follow the link.

Comment 4

[Darin Fisher]

I agree that unescaping URI special and reserved characters (as defined in RFC
2396) in the status bar probably doesn't make much sense.  Those characters can
change the meaning of the URI, so keeping them escaped is probably a good idea.

NOTE: We are talking about the behavior of nsITextToSubURI::unEscapeURIForUI,
which is only used when preparing a URI to be displayed in the UI.

The solution might be to pass esc_Minimal to NS_UnescapeURL.

Comment 5

[Christian Franke]

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6a) Gecko/20031030]

Control chars in URLs are not visible in status bar but should be.

URLs like http://[e-mail]/ are used to exploit the recently
discovered IE parsing vulnerability, see
http://www.securityfocus.com/archive/1/346948

Related: Bug 122445.

Comment 6

[Christian Franke]

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040113]

This is IMO fixed in 1.6, see bug 227176.
Related testcases are now OK:
Attachment 135620 [details] (Comment 1)
Attachment 137366 [details] (Bug 122445, comment 108)
Attachment 137564 [details] (Bug 227176, comment 49)

Comment 7

[Christian Franke]

Sorry, bug 227176 should be bug 228176 in comment 6.

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

hm? how is comment 1's testcase ok?

this is not fixed. reread comment 0.

Comment 9

[Christian Franke]

Agree ... sorry for the spam.

Comment 10

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 11

[alanjstr]

If a site is using a URL crafted with those characters, then I would think that
the links are not very likely to have much meaning even in their unescaped form.

Comment 12

[Peter Weilbacher]

I thought this would be fixed in the %00 frenzy from last summer, but the testcase still shows the same links for me with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008041601 SeaMonkey/2.0a1pre.

Should probably be moved to some Core component...

Comment 13

[Serge Gautherie (:sgautherie)]

Filter "spam" on "guifeatures-nobody-20080610".