Bug 43730 – history.pushState / replaceState's title parameter is unsatisfactory

• Component: DOM
• Status: RESOLVED WONTFIX

[Justin Lebar]

See also the corresponding Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=585653

WebKit currently ignores the title parameter in history.push/replaceState.  This is unsatisfactory.

I see three ways we can proceed from here:

 * Continue ignoring the title parameter
 * Hook up the title parameter to document.title
 * Deprecate pushState and replaceState and replace them with two-parameter functions.

Whatever we do, I'd like it to be coordinated between WebKit and Mozilla, if at all possible.  It's largely lack of coordination that got us into this mess in the first place.

[Eric Seidel (no email)]

At some point webkit started respecting the title parameter...  I'm not sure when.  FF also did.

[Justin Lebar]

AFAICT (and I wrote this code) Firefox does not respect the title parameter.  Notice that the |aTitle| parameter is not used anywhere in this function.

http://hg.mozilla.org/mozilla-central/file/c4de6de47382/docshell/base/nsDocShell.cpp#l10132

[Eric Seidel (no email)]

Sorry, I started using History.js and that must have "Fixed" this bug for me.  Apologies for the confusion:
https://github.com/balupton/History.js/

[Eric Seidel (no email)]

It appears that we store the title information in our HistoryItems, but must not use it on restore:
http://trac.webkit.org/browser/trunk/Source/WebCore/loader/HistoryController.cpp#L862

I'm not particularly familiar with the history sub-system, and am no on my work computer with a checkout atm. :)

[Brady Eidson]

So... we clearly use it as Eric spotted.  What is the bug?

Please don't point to outside sources - Attach an example with a step to reproduce that still repros in a WebKit nightly.

[Brady Eidson]

(In reply to comment #5)
> So... we clearly use it as Eric spotted.  What is the bug?
> 
> Please don't point to outside sources - Attach an example with a step to reproduce that still repros in a WebKit nightly.

The point of this request being if you cannot attach an example because nothing still reproduces, we can close this bug instead.

[Eric Seidel (no email)]

I think Justin's original request was to either remove or fix the title parameter.  My understanding is that WebKit (in agreement with Mozilla) ignores title parameter, despite having it plumbed through the history system.

I believe Justin is mostly sad about this ugly pushState API with an ignored parameter, which we presumably will never change to not ignore its second argument.

[Justin Lebar]

> I believe Justin is mostly sad about this ugly pushState API with an ignored 
> parameter, which we presumably will never change to not ignore its second 
> argument.

That's a pretty good description of how I feel.  :)

I think we can close this bug, though, because like you say, we're presumably never going to be able to change this.

[Brady Eidson]

Saying that the parameter is ignored now doesn't mean it will always be ignored.

Display of the title parameter is an individual user-agent concern more than a web engine concern.

Thanks for the feedback that you'd like it not to be ignored.

[Eric Seidel (no email)]

I can tell you from personal experiance, that I switched a web app of mine from using history.pushState directly to History.js and was very surprised to see the title being respected (and thus the title of my app being reset to default).  I previously had used "" for the title parameter.  Mozilla's docs even recommend using "":
https://developer.mozilla.org/en-US/docs/DOM/Manipulating_the_browser_history#The_pushState().C2.A0method
But doing so with Hisotry.js causes clearing of the title (where in Moz/WebKit it's ignored).

I guess what I'm saying is that we are likely stuck ignoring it (or at least ignoring "") in the future, as I'm sure much larger web apps than mine, may be depending on ignoring the title attribute now. :)

(The fact that History.js doesn't ignore "" for backwards compat with mozilla's docs seems like a bug here too.)