W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2010

[whatwg] push/replaceState interacting with POSTs

From: Justin Lebar <justin.lebar@gmail.com>
Date: Fri, 16 Jul 2010 15:31:59 -0700
Message-ID: <AANLkTilrLfXNYjTgWK29YE4mepsrLIv1l0rJ9WzKvrOo@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:25 UTC