585653 - history.pushState / replaceState's title parameter is unsatisfactory

Status: RESOLVED WONTFIX

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

Description

[Justin Lebar (not reading bugmail)]

Right now, we ignore pushState / replaceState's title parameter, as does WebKit.  This is unsatisfactory.

I proposed hooking the title parameter into document.title to WhatWG but didn't get any feedback on that [1].  I spoke with WebKit devs Darin Fisher <[e-mail]> and Brady Eidson <[e-mail]> about this, but the conversation petered off before we reached a conclusion.

I think our three options at this point are:

 * Continue ignoring the title parameter
 * Hook up the title parameter to document.title
 * Deprecate pushState and replaceState and replace them with two-parameter functions.

[1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027266.html

Comment 1

[Justin Lebar (not reading bugmail)]

See also the WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=43730

Comment 2

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

# [21:03] <Hixie> jlebar: i recommend experimenting with it, see if it gives authors what they want

I'd just do it.

Comment 3

[Justin Lebar (not reading bugmail)]

Jonas and I talked about this and we don't think we can do this without pretty radically changing how document.title works.  Alas, I think we're stuck ignoring the title argument.

Comment 4

[Max Kanat-Alexander]

I was talking a bit with jlebar about this in another bug, and here's my most recent comment:

I think it's unfortunate, because instead of fixing that problem, browser implementors are effectively pushing it off onto every single consumer of replaceState, no? What are we supposed to do with the problem of title and back/forward?

Comment 5

[Justin Lebar (not reading bugmail)]

I think the idea is that if you want different states to have different titles, you need to set document.title in popstate.

I agree that this whole thing is really unfortunate.  But I don't think we can hook up push/replaceState's title parameter to document.title at this point -- that would be really complicated.

Comment 6

[Max Kanat-Alexander]

I definitely understand the complexity argument. Is it just a refactoring issue, or some logical issue involving specifications?

Comment 7

[Justin Lebar (not reading bugmail)]

It's more of a spec issue, although complexity there leads to complexity in implementation.

Hooking up the title argument to document.title might work as follows:

 * Every time you unload a shentry, save its document.title into the shentry
 * Every time you activate a shentry, load its saved document.title

But that doesn't work quite right.  Suppose you navigate to foo.html and then foo.html#bar.  Then you change document.title and click back.  That shouldn't change the title, but it will with the above algorithm.  To fix this, you have to start introducing different types of shentries, and...you end up in a sad place.  :(

Comment 8

[Max Kanat-Alexander]

Ahh, I do see the problem there.

Could you have back/forward only set document.title if title was set by the history API?

Comment 9

[Justin Lebar (not reading bugmail)]

You could, but you run into the same kinds of problems.

Suppose I navigate to process_bug.cgi which replaceStates to show_bug.cgi.  Then I click a link to show_bug.cgi#c10 and then set document.title.  What should happen when I go back?  Should the old title be restored?