Page MenuHomePhabricator

History pushState misbehaving on 4.0.4
Closed, ResolvedPublic

Description

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.


Version: unspecified
Severity: normal

Details

Reference
bz41605

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:00 AM
bzimport set Reference to bz41605.
  • Bug 41670 has been marked as a duplicate of this bug. ***

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

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