Bug 16950 - the base tag overwrites document.documentURI
Summary: the base tag overwrites document.documentURI
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Adam Barth
URL: http://crypto.stanford.edu/~abarth/re...
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-20 15:25 PST by Sam Weinig
Modified: 2008-06-16 00:26 PDT (History)
5 users (show)

See Also:


Attachments
Patch (8.29 KB, patch)
2008-06-14 13:22 PDT, Adam Barth
sam: review-
Details | Formatted Diff | Diff
Step 1: Refactor Document::m_baseURL (9.62 KB, patch)
2008-06-15 03:11 PDT, Adam Barth
sam: review+
Details | Formatted Diff | Diff
Step 2: Implement documentURI (11.84 KB, patch)
2008-06-15 03:12 PDT, Adam Barth
sam: review+
Details | Formatted Diff | Diff
Step 2b: Fix tests (3.58 KB, patch)
2008-06-15 23:15 PDT, Adam Barth
sam: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sam Weinig 2008-01-20 15:25:29 PST
This is a follow up bug for bug 16775.
Comment 1 Adam Barth 2008-06-14 13:22:55 PDT
Created attachment 21701 [details]
Patch

This patch corrects the documentURI getter and drops support for setting documentURI (which we didn't implement correctly before anyway), aligning our behavior with Firefox.
Comment 2 Sam Weinig 2008-06-14 14:11:49 PDT
What is the correct behavior for setting document.documentURI?
Comment 3 Adam Barth 2008-06-14 15:08:12 PDT
> What is the correct behavior for setting document.documentURI?

I'm not an expert in reading specs, but here is my interpretation:

http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-documentURI says:

<blockquote>
No lexical checking is performed when setting this attribute; this could result in a null value returned when using Node.baseURI.  Beware that when the Document supports the feature "HTML" [DOM Level 2 HTML], the href attribute of the HTML BASE element takes precedence over this attribute when computing Node.baseURI.
</blockquote>

Which says to me that you can set documentURI to any string whatsoever.  Setting documentURI does have an effect on baseURI.  http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-baseURI says:

<blockquote>
The absolute base URI of this node or null if the implementation wasn't able to obtain an absolute URI. This value is computed as described in Base URIs. However, when the Document supports the feature "HTML" [DOM Level 2 HTML], the base URI is computed using first the value of the href attribute of the HTML BASE element if any, and the value of the documentURI attribute from the Document interface otherwise.
</blockquote>

I think the correct behavior is this:

1) document.documentURI is initialized to m_url;
2) Script can set document.documentURI to any string whatsoever.

The rules for computing baseURI are as follows:

1) If the baseURL has been set explicitly via <base href="...">, return that URL.
2) Otherwise, parse documentURI as a URL.
  a) If the parse succeeds, return that URL.
  b) If the parse fails, return null.

I can implement this behavior, if you like, or I can implement something else if you have a different interpretation.  I don't know of any other browsers that support setting documentURI.
Comment 4 Sam Weinig 2008-06-14 19:29:20 PDT
Comment on attachment 21701 [details]
Patch

Yeah, I think we should implement the specified behavior and not regress these tests.

r- for now.
Comment 5 Adam Barth 2008-06-15 03:11:15 PDT
Created attachment 21708 [details]
Step 1: Refactor Document::m_baseURL

This cleans up our handling of baseURLs to makes it easier to implement documentURI correctly.
Comment 6 Adam Barth 2008-06-15 03:12:25 PDT
Created attachment 21709 [details]
Step 2: Implement documentURI

This patch implements both get and set for documentURI.
Comment 7 Adam Barth 2008-06-15 23:15:39 PDT
Created attachment 21721 [details]
Step 2b: Fix tests