Last Comment Bug 585653 - history.pushState / replaceState's title parameter is unsatisfactory
: history.pushState / replaceState's title parameter is unsatisfactory
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: All All
-- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Andrew Overholt [:overholt]
Depends on:
  Show dependency treegraph
Reported: 2010-08-09 10:04 PDT by Justin Lebar (not reading bugmail)
Modified: 2010-10-01 23:36 PDT (History)
7 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Justin Lebar (not reading bugmail) 2010-08-09 10:04:42 PDT
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 <> and Brady Eidson <> 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.

Comment 1 User image Justin Lebar (not reading bugmail) 2010-08-09 10:10:46 PDT
See also the WebKit bug:
Comment 2 User image :Ms2ger (⌚ UTC+1/+2) 2010-08-09 12:56:17 PDT
# [21:03] <Hixie> jlebar: i recommend experimenting with it, see if it gives authors what they want

I'd just do it.
Comment 3 User image Justin Lebar (not reading bugmail) 2010-08-10 17:06:19 PDT
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 User image Max Kanat-Alexander 2010-08-13 15:59:02 PDT
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 User image Justin Lebar (not reading bugmail) 2010-08-13 16:02:54 PDT
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 User image Max Kanat-Alexander 2010-08-13 16:10:48 PDT
I definitely understand the complexity argument. Is it just a refactoring issue, or some logical issue involving specifications?
Comment 7 User image Justin Lebar (not reading bugmail) 2010-08-13 16:18:21 PDT
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, end up in a sad place.  :(
Comment 8 User image Max Kanat-Alexander 2010-08-13 16:29:05 PDT
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 User image Justin Lebar (not reading bugmail) 2010-08-13 16:34:33 PDT
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?

Note You need to log in before you can comment on or make changes to this bug.