[whatwg] push/replaceState interacting with POSTs
Justin Lebar
justin.lebar at gmail.com
Fri Jul 16 10:13:14 PDT 2010
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
More information about the whatwg
mailing list