- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 13 Nov 2014 05:21:36 +0000 (UTC)
- To: cowwoc <cowwoc@bbs.darktech.org>, Michal Zalewski <lcamtuf@coredump.cx>
- Cc: WHATWG <whatwg@whatwg.org>
(pushing this to the top of the queue by request) On Sun, 2 Nov 2014, cowwoc wrote: > > I would like to > bringhttps://code.google.com/p/chromium/issues/detail?id=428583 to your > attention. Quoting comment #9: > > I believe this is a corner case that is not adequately described. I was > imagining adding a clause somewhere around step 8 > inhttps://html.spec.whatwg.org/multipage/browsers.html#unloading-documents:beforeunloadevent > <http://html.spec.whatwg.org/multipage/browsers.html#unloading-documents:beforeunloadevent>. > Specifically, clarifying what the behavior should be if an event handler > modifies the url. > > I believe I have a legitimate use-case (described in comment #9) for > needing to change the URL in "beforeunload". I am open to alternatives > that allow me to achieve the same end-result, but I have not found any > good solutions to date. I don't really understand what's unclear here. Can you elaborate? As far as I can tell this is one of the better defined interactions, since the unload algorithm and the pushState algorithm are pretty specific. Generally speaking, though, for your use case you should just use sessionStorage rather than cookies. That's what sessionStorage is for. If you don't want the tabId to be shared, you shouldn't put it in the location bar in the first place -- removing it from the history is too late, because people copy and paste URLs from the location bar while the page is up. You could replaceState() during page load, but I would generally much more recommend sessionStorage for this purpose. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 13 November 2014 05:22:02 UTC