Closed Bug 585653 Opened 10 years ago Closed 10 years ago
.push State / replace State's title parameter is unsatisfactory
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 . I spoke with WebKit devs Darin Fisher <firstname.lastname@example.org> and Brady Eidson <email@example.com> 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.  http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027266.html
See also the WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=43730
# [21:03] <Hixie> jlebar: i recommend experimenting with it, see if it gives authors what they want I'd just do it.
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.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
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?
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.
I definitely understand the complexity argument. Is it just a refactoring issue, or some logical issue involving specifications?
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. :(
Ahh, I do see the problem there. Could you have back/forward only set document.title if title was set by the history API?
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?
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.