Html: 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 [e-mail]
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
https://github.com/whatwg/html/issues/2174#issuecomment-269966154, 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.