Scroll and navigate Back does not fire event on Android
Opened this issue · 8 comments
Pushing the Back button on Android's WebKit browser after a page has been scrolled down causes the address to change to the previous one as expected, also scrolls the page to the top, but the hashchange event does not fire.
Plugin works fine without scrolling. Also hashchange event works fine without the plugin on this browser.
Observed on: Mozilla/5.0 (Linux; U; Android 2.1-update1; en-ro; Desire_A8181 Build/ERE27) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17
Does this page work "as expected" both before / after scrolling?
http://jsbin.com/onayu3/7/
Yes, works perfectly before & after scrolling, with one exception. The event doesn't fire during scrolling.
You know how on handhelds you can flick the page (tap hold, drag and release quickly) to make the page slide smoothly. If I press the device's back button while the page is still scrolling, the event won't fire. Same thing if I use one hand to drag the page around and the other one to push the back button while it's still being scrolled.
edit: It seems the browser's built-in onhashchange event suffers from the same issue. Also, I can confirm the original bug I reported was not caused by pushing Back while scrolling.
Do either of the "polling" or "onhashchange" values update when you press the back button while scrolling, or neither?
Neither of them updates.
This sounds like a browser bug. I suggest you report it as a such, and feel free to include a link to this thread or the http://jsbin.com/onayu3/7/ example. If you do report it as a bug, please link that bug's page in this issue. Thanks!
I just realized when you first gave me that test case, I thought it was using the jquery.onhashchange.event plugin. That's why I said the built-in event suffers from the same issue.
My original report still stands though. It seems the plugin is not falling back to Android's built-in event, which is somewhat (not considering the back-while-scrolling issue) functioning, and in the process introduces the bug I reported in OP.
Android issue 8475: http://code.google.com/p/android/issues/detail?id=8475
Because android incorrectly reports "onhashchange" in window as false, there's very little I can do to address this issue. One idea is to bind to the event and start the polling loop. Then, if the event is fired, cancel the polling loop.
Of course, it's not that easy, since due to changes in the HTML5 spec, some browsers handle the event synchronously while others handle it asynchronously, which adds extra complexity in attempting to keep the event from double-firing.
Considering the fact that the polling fallback still works, I'm going to hold off on this issue until I can find a little time to think through all the potential edge-cases.
Also, note that I've submitted Issue 9538 to the android bug tracker for the "onhashchange" in window returning false bug.
I'm closing this issue, since there seems to be nothing that can be done on my end.