jquery-archive / jquery-mobile

jQuery Mobile Framework
https://jquerymobile.com
Other
9.7k stars 2.41k forks source link

AJAX back button support on Android 2.1 is flaky #403

Closed ai closed 11 years ago

ai commented 13 years ago

I have HTC Hero with official Android 2.1 (Russian). Demos index is show fine. But, when I click on any element, it loaded and “Error Loading Page” alert is showed. Next any clicks on any elements doesn’t work. Sometimes any clicks doesn’t work on index page too (I try “Button”). And sometimes “Button” allow me to open 2-level pages (Button → Button markup options). I know that isn’t big and good bug report, but I doesn’t know how to get some debug data.

toddparker commented 13 years ago

Should be fixed on latest. Can you confirm: http://jquerymobile.com/test

ai commented 13 years ago

Cool, links are work, but I have problem with Back button. On first click there aren’t any changes (instead of go to index of jquerymobile.com/test), on second it show page, that I saw before jquerymobile.com/test.

toddparker commented 13 years ago

Are you using the back button in the header or the physical back button on the device? Are both working the same way?

ai commented 13 years ago

Back button in the header. Physical back button have same issue. But problem come only sometimes.

toddparker commented 13 years ago

I'm not able to reproduce the issue on my devices or emulators so I'd need a specific test case where you're consistently seeing the problem so we can try to track down the problem. Post here if you can nail this down to a specific scenario.

ntziolis commented 13 years ago

I've just found this bug report. I have posted regarding this issue on the forum already: http://forum.jquery.com/topic/demo-not-working-on-htc-hero

My latest test show that the issue for the back button to fail is the swipe scrolling at any point in time.

Just some examples:

Without swipe scroll: Index -> trackball scroll -> click on first link -> loads introduction page - > click on back button -> goes back to index

With swipe scroll: Index -> swipe scroll -> click on first link -> loads introduction page -> click on back button -> url changes (browser bar is shown, you can see that it has the right url) -> but the introduction page is still shown, rather than the index

In general: Its possible to open links after swiping, but its not possible to use any kind of back button (link button or the phones hard button). The only way to get it to work again is to reload the current page (it can be a subpage as well) then all back buttons work again (until another swipe). One exception: Its possible to close dialogs even after swiping.

Hope this helps

ntziolis commented 13 years ago

Anybody had a chance to look into this?

ai commented 13 years ago

Nope, I change my phone to Nexus S. Everything is fine on it.

ntziolis commented 13 years ago

@ai sad to hear ;)
@toddparker you asked for specific test cases, i tried to provide them, if this was not enough I can try to provide further details, please try to explain what else you need to know to reproduce

toddparker commented 13 years ago

I'll try this on our devices this week...

toddparker commented 13 years ago

I can't reproduce this on our test devices. WIth Android, there are so many variables in play with all the manufacturer mods. You're also running the Russian language and we're testing in English. I'm not sure what to do next if we can't reproduce.

If you can dig in and do some testing to identify what is the cause in our code and ideally suggest a pull, that would be helpful.

ntziolis commented 13 years ago

@toddparker actually I'm running an english version of android, but If you could give me some hints on how to start (howto debug js on an android device etc.) I would try to look into this issue.

My device is rooted so I should be able to install everything you suggest.

ntziolis commented 13 years ago

@toddparker ok, I just ran some more tests and I think I found new information:

It seems like after swiping the links are executed as normal links (no js seems to be executed) causing the browser to perform a normal redirection to the new url. This also explains why there is no loading dialog after swiping (even when the connection is very slow and the next page takes some time to load). Could it be that swiping detaches the click handlers somehow? Maybe the hero does not properly fire the necessary 'swipe completed' events? Does this info help? If not can you point me to the place in the code where this (swipe events and click event attachment/detachment) is handled so that I could investigate further? Also can you tell me if the click events (or similar) are detached when starting to swipe and attached afterwards?

toddparker commented 13 years ago

That is really odd. When you say "swipe", you just need that you're just scrolling the page, right? And is your problem that no links work at all with either touch or trackball input after you scroll the page on Android 2.1?

The framework really doesn't do anything with scrolling and just lets the device use it's native behavior so I don't see how this should effect your page. It's a mystery because we have a 2.1 device (nook color) that works great with JQM.

ntziolis commented 13 years ago

yes, with 'swipe' I meant scrolling the page using the finger. Afterwards the links work, but only as 'normal' html links, no js seems to be executed, hence no transitions and in the new page the back button will not work since im guessing the history is not constructed properly. This goes for both clicking the links with the finger or trackball.

Can you tell me if there is a tool like firebug for android? Next week I will take some time to quickly install 2.2 and test if I experience the same behavior. I will not have time before though.

toddparker commented 13 years ago

Any update on this? We still can't reproduce so I'll be closing soon.

toddparker commented 13 years ago

Closing, no response.

aktualsize commented 13 years ago

Todd, can confirm similar issue on my own Hero; It appears as soon the scroll happens, the back link ceases to function until a new pageload - that is anything loaded in via ajax breaks the back button behaviour (all 3 instances - physical device button, android menu back button, jquery generated button).

Running Android 2.1-update1, software number is 3.31.110.1 and Webkit 3.1

toddparker commented 13 years ago

Thanks for the details. Can this reproduced on our docs pages?

aktualsize commented 13 years ago

Works exactly the same on the docs pages; the location hash is updated in the address bar but no page transition fires. If you need more info, let me know...

toddparker commented 13 years ago

Thanks for all your help. Thus issue is open and we'll take a look. Stay tuned.

Digi59404 commented 13 years ago

A client of ours is also having issues with links working. When he clicks a button who's event is handled by a live function. He gets a page is not found. We use $.Mobile.ChangePage("Setup2.html"); in the event along with a event firing to Titanium Developer.

I have tested our application works under Galaxy Tab, Emulator, and Google Chrome. His HTC Hero seems to be the only phone having an issue with the button.

Is there any details I can provide to this to assist in the resolution?

toddparker commented 13 years ago

@Digi59404 - What is the Android version you're running on these devices? Wondering what version the HTC Hero is running especially.

Digi59404 commented 13 years ago

2.1 On the HTC Hero which the client is getting an error stating page not found.

2.2 on the Galaxy Tab. I'm going to test it on another 2.1 phone today.

toddparker commented 13 years ago

I just checked jquerymobile.com/test/ on our 2/1.1 test device and navigation works fine. are you running update 1 for 2.1? Android debugging sure is fun!

Digi59404 commented 13 years ago

I'm not sure what version we're using. I think it may be Update 1. -- I found in our app I had the same issue on the iPhone because I was using $.Mobile.ChangePage(). I didn't need the Ajax and such so I switched it to window.location and it worked fine. It may have just been an issue with my code.

toddparker commented 13 years ago

I think I'm going to close this since it sounds like it just may have been an issue with your code. For me to re-open this, I need a JS Bin page running the latest with a demo, detailed steps to reproduce and info on what device/Android version to test on. Thanks all for your help!

iblank commented 12 years ago

I'm having the same issue with the Droid Eris, Android 2.1 as ntzoilis mentioned above. To recreate the problem all I have to do is go to http://jquerymobile.com/demos/1.0a4.1/ -> scroll down with finger ("swipe") -> click on any list item -> click on back button in header (same for physical back and menu back select). It updates the URL, but doesn't update which page is shown (page reload required). If I avoid scrolling with my finger (by using the scroll wheel) everything works fine.

I also tested it on version 1.0a3 and it works fine there. So, there must be some update that threw it off.

toddparker commented 12 years ago

Can you test this in latest? 4.1 is 6+ week old at this point.

jquerymobile.com/test

iblank commented 12 years ago

Just tried it out and it's behavior is the same as 4.1. Side note, it's also not adding the back button to the header.

toddparker commented 12 years ago

Thanks for testing. Yes, we disabled the auto back button feature by default for the upcoming beta, but it can be turned back on via options.

toddparker commented 12 years ago

And I just tested the latest on our 2.1 and 2.2 devices and don't have this issue so it's hard for us to track down a cause. Wondering if there is some customization going on with the browser on some phones?

ntziolis commented 12 years ago

The issue is still the same as i mentioned in my earlier comments: https://github.com/jquery/jquery-mobile/issues/403#issuecomment-647165 and following.

I would be happy to assist with further test or debugging, but I need some hints on how todo that. Some js debugging/logging possibility would be great.

iblank commented 12 years ago

I am using a phone near the end of it's 2-year lifespan. So, it's honestly not a huge problem to me. It's good to know that it doesn't seem to be a problem for most devices. I would be happy to do a little testing too, if you need it.

toddparker commented 12 years ago

Any help you can provide in terms of narrowing down a cause and even a suggested solution would be appreciated.

ntziolis commented 12 years ago

How do you guys debug issues like that? What tooling do you use? Can you suggest a js debugger for android 2.1?

toddparker commented 12 years ago

Trial and error with a good dose of logging and alerts. Mobile debugging is very tough but we appreciate the help!

ntziolis commented 12 years ago

not the answer i was hoping for, but thx anyway ;)

oddbox commented 12 years ago

I'm having the same problem, both on a Hero with android 2.1-update1 (webkit 3.1), and on a Samsung Galaxy tab (GT-P1000) with android 2.2 (Froyo.xwjj3). After scrolling, clicking on the physical back-button, the page scrolls to the top, and the url updates in the address-field. Another click changes the url again, but the page remains the same. I've been able to check that the hashchange event triggers, but I couldn't follow what the code is supposed to do after that. This happens both with http://code.jquery.com/mobile/1.0b2/jquery.mobile-1.0b2.min.css and http://code.jquery.com/mobile/latest/jquery.mobile.js

Digi59404 commented 12 years ago

Upgrade your jquery version. Had the same prob upgraded an fixed

Sent from my iPhone

On Aug 18, 2011, at 9:08 AM, oddboxreply@reply.github.com wrote:

I'm having the same problem, both on a Hero with android 2.1-update1 (webkit 3.1), and on a Samsung Galaxy tab (GT-P1000) with android 2.2 (Froyo.xwjj3). After scrolling, clicking on the physical back-button, the page scrolls to the top, and the url updates in the address-field. Another click changes the url again, but the page remains the same. I've been able to check that the hashchange event triggers, but I couldn't follow what the code is supposed to do after that. This happens both with http://code.jquery.com/mobile/1.0b2/jquery.mobile-1.0b2.min.css and http://code.jquery.com/mobile/latest/jquery.mobile.js

Reply to this email directly or view it on GitHub: https://github.com/jquery/jquery-mobile/issues/403#issuecomment-1839752

ntziolis commented 12 years ago

@Digi59404 this is incorrect, the problem with the HTC Hero still exists even in the newest version, the newest demo can be found here: http://jquerymobile.com/test (this is development version, might be broken at any time so please check with another device as well).

oddbox commented 12 years ago

Forgot to mention that this was with jquery 1.6.2.

oddbox commented 12 years ago

I now see that this also happens on the iPhone 3G, with iOS 3.1.3. (iOS 4 is unusably slow on the 3G. :p )

There I don't even have to scroll. Perhaps because it automatically scrolls to hide the address-bar? (sometimes I can see it scrolls a few pixels when I click back, (and going forward scrolls the opposite direction).) After clicking back twice on the iPhone, I'm returned to essentially the correct page, but then I've missed the one I'm looking for. :( This can be seen at http://larbib.no/cgi-bin/m (not yet launched version of our mobile library search.) English can be selected with the bottom right button. (Innstillinger). Otherwise, click on "Søking", then enter a search term in the form it takes you to, and submit. Try going back with either the back (Tilbake)-button or the browsers back button. Clicking once seemingly doesn't do anything, but twice will take you back to the start screen, and not the search form you're trying to reach.

I hope somebody can help us with this.

oddbox commented 12 years ago

I've now been able to consistently reproduce this in chrome. (even without scrolling. :/ )

First, let me set the scene. ;) Our program starts with this address: http://larbib.no/cgi-bin/m This generates html for several pages at once, one with the id "enkeltsok", which is a search-form. The form has this attribute: action="/cgi-bin/m" (it is the same program that responds with the search-result, when given different input)

(Before the search is submitted, the address-bar shows this url: http://larbib.no/cgi-bin/m#enkeltsok ) Using that form, the browser goes to an address like this: http://larbib.no/cgi-bin/m#/cgi-bin/m?mode=vt&hpid=11871&pubsok_txt_1=mat&historisk=&pubsok_kval_1=&avgr_spraak=&sortering=

This causes the browser to fetch the result with ajax, by getting this url: http://larbib.no/cgi-bin/m?mode=vt&hpid=11871&pubsok_txt_1=mat&historisk=&pubsok_kval_1=&avgr_spraak=&sortering= This result contains a new page with the id "searchres", which is shown to the user. All seems well so far.

When clicking the back-button, we're trying to get back to http://larbib.no/cgi-bin/m#enkeltsok

I've tried examining the code in jquery mobile, and things seem to go wrong somewhere in $.mobile.loadPage.

When clicking the back-button, $.mobile.changePage is called with the string "#enkeltsok" in the variable toPage, and options-variable is an object. A bit into this, it checks whether toPage is a string, and since it is, it uses $.mobile.loadPage(toPage,settings). When loadPage is done, it causes changePage to be called again, this time with toPage being an object. But this object is not the div with the id "enkeltsok", but the id "searchres", which is the page we're trying to get away from. It seems to be because absUrl is given a wrong value on line 2412, where it has combined the url we got with our ajax-request, with the id we're trying to get to. absUrl has now got this value: http://larbib.no/cgi-bin/m?mode=vt&hpid=11871&pubsok_txt_1=mat&historisk=&pubsok_kval_1=&avgr_spraak=&sortering=#enkeltsok

The browser on the other hand ends up with http://larbib.no/cgi-bin/m#enkeltsok in the addressbar, but with the page "searchres" still showing.

Any help would be appreciated!

benyto commented 12 years ago

If this might help, I've got the same problem with back buttons on both web version of my site and phongap version running on HTC 2.1.

Definitely the issue is related to version 2.1 of Android. Upgrading to 2.2, the same source code runs fine both in the browser and with phonegap.

2.1 is still installed on 8% android mobiles. So a fix is welcome.

toddparker commented 12 years ago

I just re-tested and I'm seeing some flakiness on 2.1, but only sometimes. The back button will work on one click, then only update the hash and stay on a page the next. My guess is that this is just being flaky.

My hope was that the pushState feature was the issue,b ut if I shut this off, the browser still acts flaky with the back button so it's a tougher problem to solve. I can re-open this issue, but the only solution may be to exclude 2.1 from the AJAX nav and transitions to make this 100% reliable with the back button = B grade.

jblas commented 12 years ago

@toddparker

I just tried several pages on /test/ and couldn't repro with my Droid X (Android 2.1 Update 1). Were you testing against /test/? If so can you list the pages you visited so I can try and mimic what you were doing?

Also, does this issue happen with the device back button? Or the back button we inject? Or both?

ocruz commented 12 years ago

Hi to all.

I am seeing this issue in out HTC Aria with Android 2.1 Update 1. I tested it on the test pages and it can be reproduced easily. The problem happens with both the back button and the device back button. To reproduce you can do the following:

Navigate: Components -> Pages & dialogs -> Anatomy of a page

In "Anatomy of a page" scroll down to see the page content. At this point hit the device back button and you will see that the url changes to the previous page but the page is still "Anatomy of a page".

Hope this helps.

toddparker commented 12 years ago

@primillo - It seems that this is some odd bug with some HTC phones running 2.1 because we have a HTC and can see this but other phones from diff. manufacturers are fine with 2.1. Just not sure what is different here and I don't know if it's really fixable...

toddparker commented 12 years ago

I'm going to keep this open because it is a legit issue, but I'm not sure how we're going to be able to test for this flaky behavior. This seems to be an issue only with certain Android devices/builds.