264731 - URL incosistent between address bar, page info window, and link calculation

Status: RESOLVED EXPIRED

(Core :: Networking, defect)

Description

[hpalace]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041016 Firefox/1.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041016 Firefox/1.0

The URI displayed in the location bar, in the Page Info window, and the one used
to translate relative paths to absolute paths can differ.  All of these should
use the same URI, to avoid confusion.


Reproducible: Always
Steps to Reproduce:
1. Install the x-protocol.xpi mentioned in the URL.  Due to my lack of knowledge
of the Mozilla architecture, you will have to edit protocol-init.js in
x-protocol.jar to refer to  an actual copy of protocol.js.  Sorry.
2. Go to the URI "x:".  You should be viewing http://getfirefox.com
3. Click on any link, and note where you go.

Actual Results:  
The link with HREF="/" will go to, "http://www.mozilla.org/", for example

Expected Results:  
The link should have gone to "x:/" as shown by the Page Info window.

Comment 1

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

>the one used
>to translate relative paths to absolute paths can differ.  All of these should
>use the same URI, to avoid confusion.

no, the base uri must be allowed to be different. consider <base href="...">.


why are you wrapping an xpcom component in a jar file?? (or is that common for
firefox xpis? no idea)

	QueryInteface: function( iid ) {
this looks like a typo :-)

		var chan = ProtocolHandler( realUri.scheme ).newChannel( realUri );

the usual way to do this is to ask the IO Service for a channel...


Anyway...
www.getfirefox.com redirects to www.mozilla.org/.../. that's why relative links
from it go to www.mozilla.org.

the reason that relative links do not use x: as base uri is that the channel you
create has (initially) http://www.getfirefox.com as spec, and later on (due to
the redirect) http://www.mozilla.org/.../.

if you want a different base uri, your channel should return that (the content
can still override that with <base href>, of course).

your PseudoChannel class is violating necko apis in interesting ways, btw...
(does not add itself to the loadgroup, URI and originalURI are strings (??
xpconnect will not like that), accessing stuff like contentType before
onStartRequest is called will not be very useful)



Note that, when I load x://, both the url bar and page info show
http://www.mozilla.org/products/firefox/ as URL, and this one is used as base
for relative URIs, as expected (this is due to the redirect, I'm sure)

Comment 2

[hpalace]

Serves me right for creating a last minute change to the test case with out
testing it.

Change the URL at the top of protocol.js to some page that doesn't redirect and
you'll notice that the different sections disagree.

I wouldn't doubt that I'm doing something odd or even completely wrong, as I was
able to find no information on what the "correct" way to do this would be, so I
just fiddled around with what seemed like it worked.

Comment 3

[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 4

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.