pushState title is ignored in all implementations?

[foolip]

<title>title</title>
<button onclick="history.pushState({}, 'new title', 'other.html')">click me</button>

I tested this in Chrome, Edge, Firefox and Safari (Desktop) and none update the tab title.

https://html.spec.whatwg.org/#dom-history-replacestate says "The title is purely advisory. User agents might use the title in the user interface" but if it never does anything, some action is needed.

Is this a feature worth trying to save? If so we need to file bugs and see if we can make it happen. If not, then we should probably make this argument explicitly a dummy and recommend using document.title instead.

See also http://stackoverflow.com/questions/13955520/page-title-is-not-changed-by-history-pushstate

[annevk]

Do we know why it's not implemented?

[domenic]

I remember this being mentioned in a @Hixie interview from several years ago: http://html5doctor.com/interview-with-ian-hickson-html-editor/

[Yay295]

Nice interview. After reading it, it looks like they decided that the second argument shouldn't be there, but they couldn't remove it because people had already started using it.

Would it be possible to give it a purpose now? I could see it being used to set the title of the page, but who knows what might show up if that were implemented, given people have been putting whatever in there for so long.

[foolip]

Ah, I remember that interview too, but not that this was the API in question. It does seem pretty unlikely that using its value in the UI should give the desired results after many years of being ignored. Should we make it explicitly a dummy argument by renaming it, then?

[zcorpan]

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4768

In Safari TP it is shown in the back/forward dropdowns.

[zcorpan]

https://lists.w3.org/Archives/Public/public-whatwg-archive/2010Jul/0330.html

https://bugs.webkit.org/show_bug.cgi?id=43730
https://bugzilla.mozilla.org/show_bug.cgi?id=585653

cc @jlebar @cdumez

[jlebar]

I haven't worked on browsers for three-some years, but when I left Mozilla, that was the state, yes. I just checked the implementation, and it seems that we still completely ignore the title. https://github.com/mozilla/gecko-dev/blob/master/dom/base/nsHistory.cpp#L269 https://github.com/mozilla/gecko-dev/blob/master/docshell/base/nsDocShell.cpp#L11807 Cheers, -Justin

…

On Mon, Jan 2, 2017 at 4:26 AM, Simon Pieters ***@***.***> wrote: https://lists.w3.org/Archives/Public/public-whatwg-archive/ 2010Jul/0330.html https://bugs.webkit.org/show_bug.cgi?id=43730 https://bugzilla.mozilla.org/show_bug.cgi?id=585653 cc @jlebar <https://github.com/jlebar> @cdumez <https://github.com/cdumez> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2174 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJMh9TFN5dt6pbVn_FzSPcX5fTuHv-Gks5rOOzzgaJpZM4LMw6t> .

[zcorpan]

@cdumez can you comment on Safari's behavior here? Was there a good reason for this behavior such that it would be a good idea for other browsers to adopt it, or should Safari align with Chromium and Gecko and ignore the argument?

@domenic what does Edge do?

[domenic]

Edge does not appear to use the title.

[mgol]

@cdumez Could you weigh in? I had an impression every browser ignored the title, the WebKit bug was even wontfixed back in the days. It'd be good to restore cross-browser compatibility one way or the other.

[cdumez]

@weinig @beidson are probably better people to answer this question. This seems like fairly old behavior.

[Yay295]

Pinging @cdumez to see if we can get this moving again.

[beidson]

What is being asked - For WebKit to stop using the title in back/forward list entries because other browsers don’t?

Since it’s advisory, what’s wrong with that status quo?

We were never going to allow JavaScript to dynamically script the title displayed in the current browser tab in such an obvious way...
But since these are “state” APIs and one intended use case was that pages push/replace state URLs in a bflist that could actually be restored at a later date, we didn’t see the harm in also scripting a useful title in those entries as the user might actually confront them later.

[domenic]

Yeah, I'm unsure exactly what the right approach is here. It seems like a conflict between a general desire for interop, and the harmlessness of letting browsers innovate on invisible-to-JS UI surfaces.

I lean toward it being better to converge on title being ignored, though. I'm imagining a couple of hypothetical web developers:

• One who tests their site first in Chrome/Edge/Firefox, sees that the title argument does nothing (or reads that from some tutorial site that is itself unaware of the Safari behavior), and writes history.pushState(stateObj, "this is useless", "bar.html"). Soon they start getting bug reports from Safari users about confusing history drop-downs.
• One who tests their site first in Safari, and assumes the title argument is useful in all browsers.

The first scenario is more troubling to me.

[jlebar]

(Disclaimer: Although I implemented this feature in Firefox, it's been almost five years since I've worked on web browsers. Maybe none of this is correct.) The way we expected people to do this was to modify the document's <title>. Firefox should remember the title at the time of the pushState call, and it should put that into the history dropdown. In this way it's consistent with how the history dropdown works for normal navigations.

…

On Mon, Jul 9, 2018 at 8:35 AM Domenic Denicola ***@***.***> wrote: Yeah, I'm unsure exactly what the right approach is here. It seems like a conflict between a general desire for interop, and the harmlessness of letting browsers innovate on invisible-to-JS UI surfaces. I lean toward it being better to converge on title being ignored, though. I'm imagining a couple of hypothetical web developers: - One who tests their site first in Chrome/Edge/Firefox, sees that the title argument does nothing (or reads that from some tutorial site that is itself unaware of the Safari behavior), and writes history.pushState(stateObj, "this is useless", "bar.html"). Soon they start getting bug reports from Safari users about confusing history drop-downs. - One who tests their site first in Safari, and assumes the title argument is useful in all browsers. The first scenario is more troubling to me. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2174 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJMh-ujCzFRbcTjzsRoGo3Tar_7htPxks5uE3gygaJpZM4LMw6t> .

[gijsk]

FWIW, in https://bugzilla.mozilla.org/show_bug.cgi?id=585653 comments 5, 7 and 9, I think some of the implementation issues around having this influence or supersede document.title as used for tab/window titles for the loaded page are articulated well, and I think those problems haven't gone away in the intervening years.

It seems we could reduce confusion in the spec by saying something along the lines of: The title provided in pushState and replaceState is only associated with the current history entry, not with the current document or browsing context. Providing it will not alter document.title, nor will the user agent use a history state's title as a substitute for document.title in its user interface as a label for a given browsing context. The user agent may however use the title as a label for a history entry in history navigation user interfaces.

(The above probably wants word-smithing by someone more familiar with some of the relevant terminology.)

As far as I can tell, that covers the Webkit behaviour as well as making it explicit that using it won't update tab/window labels (anywhere), which was what was originally at issue in the OP.

It may be worth saying something similar in the "Developer's edition", with the additional hint that, if developers want the history state's title used, they can assign it to document.title when using push/replaceState and/or in a popstate event listener.

[domenic]

The thing is, the spec doesn't get to dictate what browsers do in their user interfaces. Browsers could very well use this argument to change the user interface label for the given browsing context if they wanted to. They can't change the value of document.title, which is derived from the <title> element, but they can update their UA using any hints they wish.

This is similar to how specs dictate the value of document.URI, but do not dictate what gets displayed in the address bar.

[gijsk]

The thing is, the spec doesn't get to dictate what browsers do in their user interfaces.

I don't really agree with this assertion, but even if I didn't object to the general case: the very reason this particular spec issue was filed is that the spec does say something about what browsers do in their user interfaces - something which doesn't match what people see in practice. Though the spec uses "may", the implication is that "some browsers do/will", and people by and large do not see that happening. That causes confusion about the spec ¹, as well as compat risks, which you outlined in your earlier comment.

If there's editor consensus that the spec shouldn't definitively say things about browser user interfaces, then perhaps the note should be removed, or replaced with some rephrasing that doesn't lead people to mistaken assumptions either way.

¹ https://www.google.com/search?q=pushstate+tab+title+doesn%27t+change gives me at least 4 different stackoverflow hits of people complaining that title "doesn't work".