1210416 - Bug in window.history / Location Bar

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[andreruediger]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.93 Safari/537.36

Steps to reproduce:

Visit http://baustelleninfo.thueringen.de/sperr-app-bis/de.novasib.sperr.gwt.app.Bis/Bis.jsp. Scroll to zoom the map or change the address in the location bar.


Actual results:

Map doesn't zoom and location cannot be edited. Both always jump back to the previous state.


Expected results:

Map should zoom and location should be editable. Both work in previous version of FF (<41) and other browsers (tested with IE and Chrome).

Comment 1

[andreruediger]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0

Comment 2

[Alice0775 White]

Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=0881f9a22f4a&tochange=3d4ea993d8f0

Triggered by: Bug 1093611


And It works if UA spoofed.
user_pref("general.useragent.override", "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.65 Safari/537.36");


So this should be the site problem

Comment 3

[Kohei Yoshino]

Reporter: This change has been documented. Please send this link to the site's webmaster if you can.

https://www.fxsitecompat.com/en-US/docs/2015/urlutils-hash-no-longer-decodes-fragment/

Comment 4

[andreruediger]

Thanks for the quick replies!

I can confirm that it works with a spoofed UA.

I guess it's the space that makes trouble here, as that seems to be the only difference between window.location.hash and the URI in the location bar.

What I still can't explain is why I'm unable to edit the address in the location bar. What triggers it to constantly change back to the previous URI?

Comment 5

[andreruediger]

I guess that the decodeFragment method in https://gwt.googlesource.com/gwt/+/2.5.1/user/src/com/google/gwt/user/client/impl/HistoryImplMozilla.java#25 is no longer valid for FF > v40.

Comment 6

[Hallvord R. M. Steen [:hallvors]]

Good find - seems we have to contact the Google Web Toolkit devs..

Comment 7

[andreruediger]

It's fixed in the current version of GWT: https://gwt-review.googlesource.com/#/c/5356/.

Comment 8

[Karl Dubost💡 :karlcow]

So I guess we can close this?

Comment 9

[Hallvord R. M. Steen [:hallvors]]

No, I guess we should now contact someone running http://baustelleninfo.thueringen.de/ and recommend they build the site with the very latest version of Google Web Toolkit.

A good first step would be if somebody finds a contact person for that site..

Comment 10

[andreruediger]

That contact person seems to be me. ;) The site will get fixed.

Could somebody explain to me why I'm unable to edit the address in the location bar? Why does it constantly jump back to the previous URI? I guess it's the way how GWT's history is implemented. But should a web page be able to "block" the location bar?

If that behaviour is expected I'd vote for marking this one RESOLVED.

Comment 11

[Hallvord R. M. Steen [:hallvors]]

If location is set from a timeout/interval, I assume you'll get this effect.

Certain browsers (like Opera (Presto)) implemented a clearer distinction between "showing" the URL you're at and "editing". This ensured the URL wasn't changed by the page while you attempted to edit it, but was risky in a different way: if you focused the URL bar, the page caused navigation, and you landed on a different site the URL bar would still show the previous URL. It was a phishing risk, but very hard to actually exploit in a real-world attack (how do you make sure a trusted page navigates to an untrusted one while the user has focus in the address bar??)

TL;DR: Yes, the current behaviour is sort of expected, and it's pretty hard to define any *100% ideal* way to do this..

Comment 12

[Adam Stevenson [:adamopenweb]]

This seems to work for me in Firefox 46 on OSX. Can someone else confirm?

Comment 13

[Hallvord R. M. Steen [:hallvors]]

:)