[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