history.pushState / replaceState's title parameter is unsatisfactory

RESOLVED WONTFIX

Status

()

Core
DOM
RESOLVED WONTFIX
7 years ago
7 years ago

People

(Reporter: Justin Lebar (not reading bugmail), Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
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 <darin@chromium.org> and Brady Eidson <beidson@apple.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.

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

Comment 1

7 years ago
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.
(Reporter)

Comment 3

7 years ago
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
Last Resolved: 7 years ago
Resolution: --- → WONTFIX

Comment 4

7 years ago
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?
(Reporter)

Comment 5

7 years ago
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

7 years ago
I definitely understand the complexity argument. Is it just a refactoring issue, or some logical issue involving specifications?
(Reporter)

Comment 7

7 years ago
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

7 years ago
Ahh, I do see the problem there.

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

Comment 9

7 years ago
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?
(Reporter)

Updated

7 years ago
No longer blocks: 580066
You need to log in before you can comment on or make changes to this bug.