- From: Justin Lebar <justin.lebar@gmail.com>
- Date: Fri, 16 Jul 2010 15:31:59 -0700
On Fri, Jul 16, 2010 at 3:11 PM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote: > What do other browsers do? Chrome 6.0.458.1 dev on Linux warns on refresh after a pushState or a replaceState. Firefox trunk (Mozilla/5.0 (X11; Linux x86_64; en-US; rv:2.0b2pre) Gecko/20100716 Minefield/4.0b2pre) warns on a refresh only after a replaceState. http://people.mozilla.org/~jlebar/test/general/pushstate-post.html -Justin On Fri, Jul 16, 2010 at 3:11 PM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote: > On Fri, Jul 16, 2010 at 1:13 PM, Justin Lebar <justin.lebar at gmail.com> wrote: >> We have a minor issue using replaceState in Bugzilla that we may or >> may not want to fix up in the spec. >> >> When you make a change to a bug, Bugzilla POSTs you from a nice-looking URL, say >> >> ? ?https://bugzilla.mozilla.org/show_bug.cgi?id=577720 , >> >> to >> >> ? ?https://bugzilla.mozilla.org/process_bug.cgi >> >> This is annoying because it breaks refresh and bookmarking, even >> though process_bug.cgi is logically displaying the same page that >> show_bug.cgi was previously displaying. >> >> Apparently fixing this the Right Way is difficult in Bugzilla, so the >> developers are considering using history.replaceState() to change the >> URL of process_bug.cgi back to show_bug.cgi?id=xxx. > > This is a standard nuisance: you want to display a success/failure > message. ?You don't want to just display it in the POST result, > because then you get browser warnings, the URL can't be copy-pasted, > etc. ?You don't want to tack it on as a URL parameter because then the > success/failure messages can be forged. ?There's no good answer I'm > aware of barring tedious server-side trickery (like queuing up a > message for display on the next view of certain types of pages). > > replaceState() sounds like it should be a decent solution if > implemented as you'd like, although it only works if JavaScript is > enabled, so it's not ideal. > >> This works well, but it has the small problem that when you refresh >> the page after processing a bug, Firefox shows you the warning it >> shows when you refresh a page which was POST'ed to. >> >> I wonder if calling push/replaceState should cause the browser to >> consider the affected history entry as the result of a GET, even if it >> was the result of a POST. ?Bugzilla may be abusing the API here a bit, >> but it's still not clear that we're doing the right thing when we >> prompt the user on a refresh (or if we were to refuse to load the page >> on a session restore since the load isn't idempotent). >> >> I'm curious what the WhatWG thinks of this. > > I'd think that hitting refresh when the URL has been changed by > JavaScript should load the current URL displayed in the location bar. > If this is different from the actual URL that the page was originally > served from, then submitting POST data that was submitted for the > current page probably makes no sense, so treating the new request in > all ways as a GET seems like the only sensible thing. ?So I'd say this > is a Firefox bug, if Firefox does this. ?(What do other browsers do? > WebKit implements replaceState, right?) >
Received on Friday, 16 July 2010 15:31:59 UTC