Bug in window.history / Location Bar

RESOLVED FIXED

Status

RESOLVED FIXED
3 years ago
2 years ago

People

(Reporter: andreruediger, Unassigned)

Tracking

({site-compat})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [needscontact])

(Reporter)

Description

3 years ago
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).
(Reporter)

Comment 1

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

Comment 2

3 years ago
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
Blocks: 1093611
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/
Keywords: site-compat
(Reporter)

Comment 4

3 years ago
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?
(Reporter)

Comment 5

3 years ago
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.

Updated

3 years ago
Component: Untriaged → Desktop
Product: Firefox → Tech Evangelism
Version: 41 Branch → unspecified
Good find - seems we have to contact the Google Web Toolkit devs..
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(kdubost)
(Reporter)

Comment 7

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

Comment 8

3 years ago
So I guess we can close this?
Flags: needinfo?(kdubost)
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..
Whiteboard: [needscontact]
(Reporter)

Comment 10

3 years ago
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.
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..
This seems to work for me in Firefox 46 on OSX. Can someone else confirm?
:)
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.