I considered logging an issue about this, but I think I'm advocating a different, incompatible history encoding strategy (don't encode/ decode) and it will likely cause issues for some people if the change were made.
As I understand the history of history encoding, originally it was encoded using encodeURIComponent, then it was switched to encodeURI as discussed here: http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/5100d5e59edb2e2b It's also mentioned in issues #1549 and #1949. The problem I ran into is that I treat & as a special character in history tokens. It's basically a normal URL appearing after the # as a history token instead of after a ? in a traditional query URL. As an example, if I were implementing a search engine, instead of a URL like /search?q=gwt&start=10, I use a GWT history token like / search#q=gwt&start=10 Now suppose that the user is searching for "g&t" instead of "gwt". I'd need to encode the & in the query so that I can distinguish it from other &s in the history token. So I use %26 because that's a typical encoding for URLs, e.g. /search#q=g%26t&start=10 The problem is that this history token becomes q=g&t&start=10 and doesn't parse properly. This decode happens automatically in some browsers (Firefox decodes window.location.hash) and manually by the HistoryImpl code in some other cases (note HistoryImplMozilla doesn't decode because Firefox decodes window.location.hash for you). I considered double encoding the location as #q=g%2526&start=10 but that solution was complicated and error prone. Some links may be generated by the server as part of an HTML block, some by the client as Anchor and Hyperlink widgets, and it's not clear when 1 encoding pass is enough. I settled for an alternate implementation of HistoryImpl that can be seen on the rawhistory branch of our gwt-traction project here: http://code.google.com/p/gwt-traction/source/browse/?r=b9cf29c1f471773f9265f30780954707a46ddef6#hg/src/com/tractionsoftware/gwt/history It uses the part after the # of window.location.href to avoid the Firefox hash decoding issue and seems to work well in all browsers. I'm planning to eventually release it so that people that know what they're doing and understand the tradeoffs can include this implementation in their project. It assumes that the developer will properly encode the hash and doesn't decode the history for them. So for /search#q=g%26t&start=10 the history token is just "q=g%26t&start=10" as it appears in the URL. It also assumes the developer will decode it as they see fit. I personally prefer this approach as I've been having to encode/decode normal URL parameters for years and this is no different. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
