606800 - location bar should show undecoded URI

Status: RESOLVED INACTIVE

(Firefox :: Address Bar, defect)

Description

[marginal]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100202 Ant.com Toolbar 2.0.1 Shiretoko/3.5.7
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100202 Ant.com Toolbar 2.0.1 Shiretoko/3.5.7

Addition of UTF8 support in URI location identifiers in Firefox has resulted in new functionality which displays different text for the URI in the GUI location-bar, than the text which is submitted to the server. And either of these texts, or both, may in fact also differ from what was provided as input to Firefox via the HTML web page, for example, or from user direct input to the Location Bar, under various circumstances.

The causes of these differences are multifarious, and complex to describe, so will not be a topic for this request. Some background on causes and problems arising from this may be understood from reading for example, 

* https://bugzilla.mozilla.org/show_bug.cgi?id=84032 
* https://bugzilla.mozilla.org/show_bug.cgi?id=412458 
* https://bugzilla.mozilla.org/show_bug.cgi?id=407974 
* https://bugzilla.mozilla.org/show_bug.cgi?id=408890 
* https://bugzilla.mozilla.org/show_bug.cgi?id=124042 
* https://bugzilla.mozilla.org/show_bug.cgi?id=494877
* https://bugzilla.mozilla.org/show_bug.cgi?id=434211
* https://bugzilla.mozilla.org/show_bug.cgi?id=407172

In order that users may understand problems which arise from this functionality, it would assist if the different incarnations of the URI could be displayed, or selected for display, in the Location Bar. The different versions should also be able to be selected for copy-and-paste from the Location Bar.

Users should be able to select which version of the three (?) possible interpretations is displayed by default. (The different versions I expect are, the literal input URI, the 'human-readable' decoded URI, and the literal URI as it has been prepared for sending as part of a server request.)



Reproducible: Always

Steps to Reproduce:
1. Type text A into the location bar, but don't hit enter yet: <http://www.xhaus.com/headers/test's fail>
2. Copy text B from the location bar and paste into a plain-text text editor.
3. Go back to the location bar, and hit enter so that the site is visited.
4. Note text C displayed in the "Requested URI" field of the page.
5. Note text D displayed visually in the Location Bar.
5. Copy text E from the location bar, and paste into your text editor.
Actual Results:  
text A: http://www.xhaus.com/headers/test's fail
text B: http://www.xhaus.com/headers/test's fail
text C: /headers/test%27s%20fail
text D: http://www.xhaus.com/headers/test's fail
text E: http://www.xhaus.com/headers/test%27s%20fail

Expected Results:  
Where discrepencies exist between the different texts A, B, C, D, and E, user should be able to easily find and understand the discrepencies and their significance through obvious, intuitive GUI interface features of firefox.

Note: xhaus.com mentioned above is a site I found through a search engine, which happens to provide a useful test function which enables demonstrating this problem. I have no affiliation whatsoever. The same function of revealing the actual content of the request header transmitted by Firefox can be improvised without much effort, using any web server which you have adminstrator capability over, or using the Firebug debugging plugin for Firefox.

Comment 1

[marginal]

I have found a similar request already exists in bugzilla, perhaps these two bugreports could be merged somehow. Mine contains more detail, though I had not made note of the reasoning behind this other report,

* https://bugzilla.mozilla.org/show_bug.cgi?id=596840

The (valid) reasoning of the report mentioned is that since the glyphs available to display the text may not include all of the glyphs to be displayed, it is useful to provide the ability to show an escaped (7-bit ASCII) version of the URI.

Comment 2

[marginal]

I have filed additional, associated bugreports, see

* https://bugzilla.mozilla.org/show_bug.cgi?id=606889
* https://bugzilla.mozilla.org/show_bug.cgi?id=606929