Last modified: 2014-02-12 23:47:46 UTC
Observed on Nexus One 4.0.4 (works fine on other browsers including Chrome on same phone) Click a link in an article Notice that the address bar does not change but the article content does. I created a minimum test case here: http://jonrobson.me.uk/PushStateWorks This shows pushState doesn't work from within functions. Not sure what to do about this.
*** Bug 41670 has been marked as a duplicate of this bug. ***
https://gerrit.wikimedia.org/r/#/c/36593/3 merged
Whoops looks like the bug number was wrong on that commit - not sure how to resolve that. That commit should have referred to bug 41446 so reopening
Correct link http://jonrobson.me.uk/mobile/pushState.html
http://caniuse.com/#search=history Older iOS versions and Android 4.0.4 claim support, but implementation is too buggy to be useful. Partial support in other Safari browsers refers to other buggy behavior.
This is a known upstream bug which is not being fixed (see http://stackoverflow.com/questions/10620843/pushstate-in-android-4-0 for background) Bizarrely it's a regression - it worked in native browser for Android 2 but not 4 (!?!). It however does work in Chrome. We will have to carefully feature detect this. I suggest blacklisting ua.match( /Android 4\./ ) && !ua.match( /Chrome/ ) - hacky - but necessary :( (Jon switches Chrome to be default browser) Bad user agent: Mozilla/5.0 (Linux; U; Android 4.0.4; en-gb; Galaxy Nexus Build/IMM76K) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30 Working user agent: Mozilla/5.0 (Linux; Android 4.0.4; Galaxy Nexus Build/IMM76K) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.166 Mobile Safari/535.19
Jon, is there a workaround for this for affected android browsers? Or an alternative way to approach the problem generally? If we want to vary behavior for android chrome vs android 4* stock browser, we will have to look carefully at how X-Device currently works for these browsers (I haven't looked into this yet) - I'd prefer we not do this if we wind up having to introduce a new X-Device type (at least not until we have esi support in MobileFrontend) because that would mean we'll have to vary the varnish cache on yet-another-device/browser type. From the threads I just breezed through on the subject, it sounds like this is not likely going to receive an upstream fix since Android is supposedly moving to use Chrome as the default browser in the future. But you can still vote to get the fix done: http://code.google.com/p/android/issues/detail?id=23979
We can feature detect this in JavaScript and turn off functionality for these browsers there - so no need to change X-Device related thing. It's just a shame... ! :)
Ok cool - it is srsly a bummer.
Looking into this now
https://gerrit.wikimedia.org/r/37321
