Bug 16950

Summary: the base tag overwrites document.documentURI
Product: WebKit Reporter: Sam Weinig <sam>
Component: DOMAssignee: Adam Barth <abarth>
Status: RESOLVED FIXED    
Severity: Normal CC: abarth, ap, collinj, darin, ian
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Mac   
OS: OS X 10.4   
URL: http://crypto.stanford.edu/~abarth/research/webkit/base/
Attachments:
Description Flags
Patch
sam: review-
Step 1: Refactor Document::m_baseURL
sam: review+
Step 2: Implement documentURI
sam: review+
Step 2b: Fix tests sam: review+

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