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 10:13:14 -0700
Message-ID: <AANLkTinedG42ZDd9WIOSfv0jHspuIuA4GXLCWZQnv603@mail.gmail.com>
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 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.

-Justin
Received on Friday, 16 July 2010 10:13:14 UTC

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