-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pushState title is ignored in all implementations? #2174
Comments
Do we know why it's not implemented? |
I remember this being mentioned in a @Hixie interview from several years ago: http://html5doctor.com/interview-with-ian-hickson-html-editor/ |
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. |
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? |
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4768 In Safari TP it is shown in the back/forward dropdowns. |
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>
.
|
Edge does not appear to use the title. |
@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. |
Pinging @cdumez to see if we can get this moving again. |
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... |
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:
The first scenario is more troubling to me. |
(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>
.
|
...because apparently browsers ignore the title argument for some reason see: whatwg/html#2174
...because apparently browsers ignore the title argument for some reason see: whatwg/html#2174
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 It seems we could reduce confusion in the spec by saying something along the lines of: The title provided in (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 |
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 This is similar to how specs dictate the value of |
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 1, 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. 1 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". |
The claim that Firefox uses it is incorrect - it's Safari: whatwg/html#2174 (comment) However, Safari still will use the current `document.title` as a fallback (aligning with other browsers' only behavior), so using it isn't mandatory there, either.
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
The text was updated successfully, but these errors were encountered: