This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 18459 - So, this makes it sound like the document base URL is computed every time that it's needed. But that doesn't seem to be true in Gecko/WebKit - in particular after pushState they don't recompute the document base URL. So the value probably needs to be stor
Summary: So, this makes it sound like the document base URL is computed every time tha...
Status: RESOLVED FIXED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-01 09:41 UTC by contributor
Modified: 2013-06-12 19:05 UTC (History)
6 users (show)

See Also:

Attachments

Description contributor 2012-08-01 09:41:17 UTC 
Specification: http://www.whatwg.org/specs/web-apps/current-work/
Multipage: http://www.whatwg.org/C#resolving-urls
Complete: http://www.whatwg.org/c#resolving-urls

Comment:
So, this makes it sound like the document base URL is computed every time that
it's needed. But that doesn't seem to be true in Gecko/WebKit - in particular
after pushState they don't recompute the document base URL. So the value
probably needs to be stored somewhere and computed only at specified times.

Posted from: 2001:4c28:a030:30:2d33:76:f557:82e4
User agent: Opera/9.80 (X11; Linux x86_64; U; Edition Next; en) Presto/2.11.310 Version/12.50
Comment 1 James Graham 2012-08-01 10:33:06 UTC 
TC, sort of: http://hoppipolla.co.uk/tests/pushState/001.html
Comment 2 Ian 'Hixie' Hickson 2012-08-24 18:51:36 UTC 
Wow, this makes my head hurt.

So, _without_ the base element, the pushState() call _does_ cause the base URL to update. But somehow the <base> element is resolved relative to something different than the document's address.

So the question is, what on earth is <base href=""> actually resolved against?
Comment 3 Ian 'Hixie' Hickson 2012-10-30 22:19:12 UTC 
bz, do you have any input on this one? (Or know who might know more?)
Comment 4 Boris Zbarsky 2012-11-26 04:46:46 UTC 
Maybe Justin Lebar?
Comment 5 Ian 'Hixie' Hickson 2013-02-07 03:49:00 UTC 
Justin: any ideas?
Comment 6 Justin Lebar 2013-02-18 18:25:27 UTC 
> So, _without_ the base element, the pushState() call _does_ cause the base URL 
> to update.

Correct: http://jsfiddle.net/c7GVu/

> But somehow the <base> element is resolved relative to something different than 
> the document's address.

It's resolved relative to the document's address at the time the base element is created.  http://jsfiddle.net/zZ6Ft/

> So the question is, what on earth is <base href=""> actually resolved against?

The document's current URI at the time the node is created.  If that node's href is later modified, the href is again resolved against the document's current URI.  http://jsfiddle.net/LkvaR/2/
Comment 7 Ian 'Hixie' Hickson 2013-04-09 17:40:45 UTC 
So the base URL for <base> elements is a stored value, which is saved:
 * when the element is created
 * when the href="" attribute is set or changed

And this is used to determine the absolute URL that is then used as the document's base URL.

And fixing just that would resolve this bug.

Everyone agree?
Comment 8 Boris Zbarsky 2013-04-09 17:50:40 UTC 
Sounds about right to me.
Comment 9 Justin Lebar 2013-04-09 17:55:03 UTC 
This doesn't quite match what Firefox does.

Suppose I add <base href="foo"> and then add <base href="bar">.  Comment 7 suggests that the second base's href will be resolved immediately, relative to the first base's href.  But in fact the second base's href is not resolved until it becomes the first base!

  var base = document.createElement('base');
  base.href = 'foo';
  document.body.appendChild(base);

  var base2 = document.createElement('base');
  base2.href = 'bar';
  document.body.appendChild(base2);

  document.body.removeChild(base);

  console.log(document.baseURI); // prints 'bar', not 'foo/bar'.

http://jsfiddle.net/rZfnY/
Comment 10 Justin Lebar 2013-04-09 17:57:04 UTC 
The testcase works the same if I replace "foo" and "bar" with "foo/" and "bar/".
Comment 11 Ian 'Hixie' Hickson 2013-05-30 21:51:30 UTC 
I made a bigger testcase:
   http://www.hixie.ch/tests/adhoc/dom/level0/history/pushState/003.html

Looks like when a <base> becomes the relevant <base> (either by being inserted first, or by the only earlier <base> being removed), and when a <base> that is the relevant <base> gets its href="" changed, its href="" is to be resolved against the document URL, and that becomes the new document base URL.

That sound better?
Comment 12 Justin Lebar 2013-05-30 22:06:45 UTC 
> That sound better?

Yes!
Comment 13 Boris Zbarsky 2013-05-31 02:03:37 UTC 
Comment 11 matches what Gecko does, I believe.  See SetBaseURIUsingFirstBaseWithHref in http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/HTMLSharedElement.cpp
Comment 14 contributor 2013-06-12 19:05:21 UTC 
Checked in as WHATWG revision r7962.
Check-in comment: Make <base> elements not be affected by changes by to the document's address
http://html5.org/tools/web-apps-tracker?from=7961&to=7962