[whatwg] push/replaceState interacting with POSTs

[Justin Lebar]

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?)
>