221915 - fragment identifiers should not be relative to the base element

Status: RESOLVED DUPLICATE of bug 146441

(Core :: DOM: Core & HTML, defect, P1)

Description

[Anne (:annevk)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031011
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031011

Mozilla doesn't render links with only a fragment identifier correctly if a base
element is used.

Reproducible: Always

Steps to Reproduce:
1. Open the test case
2. Click on 'this link'

Actual Results:  
Mozilla opened the following URI:
- http://www.microsoft.com/#dont-go-to-ms

Expected Results:  
Mozilla should have stayed on the same page, if I have interpretid the test case
of Mimasa correct. 

(I am not sure if this is the right component)

Comment 1

[Anne (:annevk)]

Attachment: test case

Comment 2

[Boris Zbarsky [:bzbarsky]]

Um... why would we use one base URI for some relative URI resolution but another
one for other relative URIs?

Comment 3

[Boris Zbarsky [:bzbarsky]]

I could certainly fix this, by the way -- it's entail going through all the
cases where we call GetBaseURL and only calling that if the relspec is empty or
does not start with a '#'.  Otherwise we would get the document URI.  A bit
messy, and maybe worth factoring out into a helper method, but not fatal.

Of interest is that HTML 4.01 refers normatively to RFC 1808 for relative URIs,
which clearly talks about URLs of the form "#foo" as relative URLs that should
be resolved relative to the base.

Comment 4

[Anne (:annevk)]

After some googling (I trusted Opera, which supports this as described in
comment 0):
http://lists.w3.org/Archives/Public/www-xml-linking-comments/2001AprJun/0158.html
and http://lists.w3.org/Archives/Public/w3c-sgml-wg/1997Jan/0290.html . The last
one quotes RFC 1866:

> Any characters following a `#' character in a hypertext address
> constitute a fragment identifier. In particular, an address of the
> form `#fragment' refers to an anchor in the same document.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Note that said rfc is not internally consistent, since it also talks about the
<base> tag establishing a new base for resolution of all relative URIs (not
excluding anchors there)....

I guess we should fix this for compat reasons.  :(

Comment 6

[Christopher Hoess (gone)]

->Networking

Comment 7

[Boris Zbarsky [:bzbarsky]]

Wrong guess.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Taking.  I doubt this will make 1.5, though... :(

Comment 9

[Christopher Hoess (gone)]

I don't see how this class of bugs is more than tangentially related to the DOM,
but I trust you.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Because all the code involved is DOM code.  See also the baseURI attribute on
the DOM3 Node interface and the xml:base attribute in the XML specifications.

Basically, the base URI for a node depends on the DOM tree, so DOM code has to
be what calculates the base URI.

Comment 11

[Hixie (not reading bugmail)]

If we're fixing this for compat reasons, it should be quirks-mode only, and it 
should be only done if there are major sites depending on this.

This is already filed as Opera bug 122490.

Testcase: http://www.hixie.ch/tests/adhoc/html/meta/base/002.html

INVALID.

Comment 12

[Hixie (not reading bugmail)]

Of note: IE6 does this like we do (i.e. correctly).

Comment 13

[Anne (:annevk)]

Could someone read the following
<http://tecknetix.com/archives/03/oct/index.shtml#oct2403>. It 'someone
important' still thinks it is invalid, I will verify that and don't start all
over again, but this is a reason (I think) to make it _not_ relative to the base
element.

Comment 14

[Boris Zbarsky [:bzbarsky]]

I'm not sure what that post is trying to say, exactly, but <base href=""> is a
no-op in any case.  If you can clearly explain why that post should affect this
decision somehow, feel free to do so (without reopening the bug, please).

This is still invalid, since we are following the URI specs correctly.  Glad to
see so is IE.

Comment 15

[Anne (:annevk)]

You are using the same structure on every page of your site. At the top of your
structure you have a relative link towards a lower part on you site, 'the content'.

Since you want to develop your pages offline you are using the base element to
make it easier to point towards files, witout changing the URI structures within
the hyperlinks.

Since you have to use the base element to do this, it makes it more complecated
to use the relative fragment identifier.

But since it is a no-op and there are ways to work around the above mentioned
problems, I verify this one.

Comment 16

[Hixie (not reading bugmail)]

Note that that would be a minor mis-use of the base href construct, IMHO. <base
href> is about changing the location of the document, not about a convenient
shorthand for authors.

Comment 17

[Anne (:annevk)]

This is actually a duplicate of a much older bug.

*** This bug has been marked as a duplicate of 146441 ***