- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 11 Aug 2010 01:17:29 +0000 (UTC)
On Fri, 16 Jul 2010, Justin Lebar 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 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). This seems reasonable. I recommend implementing it and reporting on whether it is considered a success. If it is, I'd be happy to change the spec to require this. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 10 August 2010 18:17:29 UTC