[brudish]

The Problem:
The android version of a mobile app is producing a repeat-event bug when clicking buttons that navigate screens. This causes it to navigate through to two screens ahead (instead of just the one). The third screen is navigated to using the button on the second screen whose position corresponds to the button on the first where the initial navigation action took place.

Okay, that might be a mouthful. Here’s a visual –

Each column corresponds to the tiers of screens, with the third tier simplified for the purposes of this diagram. Clicking a button on a screen should navigate to the screen connected to it. Simple stuff. The first screen is labeled with a numeral I, the second set of screens with alphabetical, and the third set with numbers. The first two tiers of the tree contain colored boxes representing the buttons on the screen used for navigation.

The app has one section which is laid out in a simple tree structure (seen above as the three sets of labeled, black-bordered boxes). Each screen has 3-4 buttons on it, in addition to navigation buttons for Back and Home at the top (not represented). The problem is – and keep in mind this only happens on the android version of the app and not the iOS – that pressing the red button on “I” navigates to “A” but then immediately navigates to “1,” as though the red button (the top one) on “A” had been pressed. This is true on any of the buttons. The green button (the middle) on “I” will navigate to “B” and then “5” (which is done using the middle button on “B”). The blue button on “I” will navigate to “C” and then “9.” It’s as though the event to change screens is firing twice, with the second one doubling the touch event for the same coordinates. It will also occur when the Back button I’ve added to the top of the screen is used, going back two screens, so it’s not just a gotoScreen-specific problem.

Devices:
So far, this bug has been found on Samsung Galaxy S3 and S4, as well as the old Motorola Photon I’m using for primary testing. It happens most often on the Photon, with only intermittent occurrence on the S3 and S4. The Asus Transformer 201 (a tablet) has the bug. These are all of the devices I’ve been able to test the app on and all of them experience it. It occurs most often on devices with lower RAM and processing speed. On the Photon, it occurs
roughly 80 percent of the time. On the S3 and S4, it seemed to occur roughly 20 percent of the time.

App Design:
The app itself is nearly 18mb for the .apk, with over 120 screens and over 75 images. At first I thought it was a race condition related to my own custom javascript – whose sole purpose is to resize and reformat html elements to style the app, as well as provide touchstart and touchend button feedback by changing their backgrounds to simulate tactile button presses – but removing my own code and any additional jquery libraries and using only what Mobione exports has shown no change in the bug.

Debugging:
In no particular order, here are the various conditions and details I’ve collected while trying to debug this problem –

– The most important detail I’ve noticed is that holding down the button for longer than a half-second causes the bug not to occur. That is, the bug only occurs when tapping a button quickly, but not when held at least slightly longer. This appears to be the only way to prevent the bug from occurring. This would almost be fine if it weren’t extremely ugly to warn users through a message somewhere “Don’t press these buttons too fast, they don’t work right!”

– Installing MobiOne 2.5M3 has shown very little (if any) improvement in the state of the bug versus 2.3M2. I was really hoping this would solve it, since I saw a bug posted fairly recently that somewhat described similar conditions, and the support response mentioned that the newest milestone release was supposed to solve it. It occurs using both Cordova 2.2 and 2.9.

– I have verified using a mouse on the Asus tablet that the bug still occurs even with simple mouse clicks. This experience throws out the idea that it’s an issue with fat-fingering the button.

– As stated before, the bug seems to occur less often on devices with more RAM and processing power. This, combined with the Most Important Detail, is what initially led me to believe that it was a race condition – the touchstart event not yet reaching the point where it tells subsequent events to be ignored.

– Fiddling with my own javascript to remove the touchend events I’ve added (changing button background colors to simulate being pressed) caused me to discover that when the bug occurs and jumps two screens ahead, the intermediary screen’s button doesn’t change color; that is, a touchstart event doesn’t appear to be firing on it. If it were the case that I was getting two touchstarts, the button should change color. This is probably the most maddening detail I’ve come across, since all of my assumptions are that a second or delayed touchstart event was firing immediately after the first. Unless something is suppressing my own touchstart behavior but not the screen transition code, I don’t know why this would be.

– The buttons on each screen are generically named the same, such as “push1” and “push2.” Due to the initial prototype being a little wonky and changes to the tree design, these are not necessary in order from top to bottom as push1, push2, push3, push4. This rules out the possibility that the action on a generic “push2” is being fired twice, since an action on the first screen’s “push4” will still cause the second screen’s “push3” to navigate to the third page.

– The bug does not occur nor can I seem to replicate it in the design center, using the webapp html file in Chrome, or on iOS.

– I’ve double, triple, quadruple, and quintuple checked it is not related to improper screen actions. This occurs on every page and every type of link: buttons, list item buttons, links, and image buttons. I’m aware that Android doesn’t like any transition but Fade as well but the problem persists even through that. (A minor point on top, Slide_Left actually works on certain pages on Android devices, but not these navigation tree pages. I have yet to decipher why this is. The only difference I can tell is that the ones which work have a Panel with a scrollbar enabled).

Moving Forward:
Were this not a commercial app, I would accept a little bit of quirkiness, but it’s designed as a support app for mothers with infants. The last thing I would like to do is hand off a product with unstable controls to a group seeking urgent answers, possibly with a finicky baby in one arm. This is probably a bug you are already familiar with, from what little I’ve been able to find regarding responses on the forums, but if there’s something I can do that doesn’t involve redeveloping the entire thing from the ground up, that would be grand. Thank you.

PS:
I had a heck of a time making this post because I received an error message every time I tried to submit.

“Bad Request

Your browser sent a request that this server could not understand.
Apache/2.2.0 (Fedora) Server at http://www.genuitec.com Port 80″

I thought your server was down for a bit there until after some diagnosis I discovered that that occurs whenever I used a percent sign in my post (obviously I can’t link the exact character here). It’s not relevant to my bug but I thought I’d give you a heads up.

[support-michael]

>- Installing MobiOne 2.5M3 has shown very little (if any) improvement in the state of the bug versus 2.3M2. I was really hoping this would solve it, since I saw a bug posted fairly recently that somewhat described similar conditions, and the support response mentioned that the newest milestone release was supposed to solve it. It occurs using both Cordova 2.2 and 2.9.

Bummer 🙁 I am escalating this issue to the dev team to investigate deeper tomorrow. We specifically worked on this issue in 2.5 milestone-3 and completely changed key internal event handling mechanism to avoid some of this android quirkiness. We noticed great improvement and have not been able to replicate the former issue with our test cases which are very similar to what you describe. Will follow up as soon as I know more. Our first step will be to return to our test cases and reverify that we did not miss something.

[brudish]

Understood. I’ve done everything I can on my end to verify that I’ve upgraded and installed the new version properly, have been using the correct Cordova library, and heck, I even opened up and poked around in the phoneui and Cordova libraries to see if I could spot anything out of place myself. If you’ve got any questions for me, I’ve been elbow deep in this problem for a couple of weeks now.

[support-michael]

We are working to replicate this issue. Please install this sample android application on an effected device and nav through the screens: http://goo.gl/G6kTlm
Please share your experience. Do you see multiple screen changes from a single click?

All help appreciated.

[brudish]

Wayne, here’s what I’ve got for you:

Debugging Details:
Devices used – Motorola Photon (Phone, Android v2.3), Asus Transformer 201 (Tablet, Android v4.1.1)
Test Conditions – All tests were done in portrait mode, with my own apps running in fixed-portrait mode. All of my transitions were Fade on my test app and SlideLeft on my debug/live app.

Genuitec Test App –
Design – Buttons using various transitions. Not nested in panels.

Device – Phone
Status – Unable to reproduce bug.

Device – Tablet
Status – Unable to reproduce bug.

Brudish Test App –
Design 1 – Buttons not nested in panels.
Design 2 – Buttons nested in panels.

Device – Phone
Status – 1) Able to reproduce bug but not with consistency.
2) Able to reproduce the bug consistently.
Cordova – Behavior same on both 2.2 and 2.9.

Device – Tablet
Status – 1) Unable to reproduce bug consistently.
2) Able to reproduce the bug consistently.
Cordova – Behavior same on both 2.2 and 2.9.

Brudish Debug App –
Design – Buttons not nested in panels -> Buttons nested in panels.

Device – Phone
Status – Able to reproduce bug consistently on both nested and non-nested buttons.
Cordova – Behavior same on both 2.2 and 2.9.

Device – Tablet
Status – Non-nested buttons bugged rarely, probably around 1 in 20. Nested buttons bugged roughly 15 in 20.
Cordova – Behavior same on both 2.2 and 2.9.

Brudish Live App –
Design – Buttons all nested in panels.

Device – Phone
Status – Able to reproduce the bug consistently.
Cordova – Behavior same on both 2.2 and 2.9. It sometimes feels like it’s slightly better on 2.9, but that could be wishful thinking.

Device – Tablet
Status – Unable to reproduce the bug consistently. In addition, the SlideLeft transition functions properly. I suspect the time it takes for the transition to complete factors into this.
Cordova – No difference between 2.2 and 2.9.

Final thoughts and observations:
Well, nobody ever said QA was supposed to be fun. The results from the tablet are generally helpful, since it was with that device I was able to reach a state of never experiencing the bug. Unfortunately, one of my other tester’s Galaxy S3 and S4 both suffered the bug, and those are both new and very current phones; it’s more than just a problem with older versions of Android and slower devices, but from my own experience, faster devices experience it less often.

The panels seem to have some impact on its occurrence, too. I distinctly noticed buttons inside of panels experiencing the bug more often, and I also noticed it occurring more often when I tapped directly on the button text versus the larger button. I did my best to keep my methods as scientific as possible, but it’s always possible there was some level of bias towards producing a quantifiable pattern.

The data regarding my own test app – which was roughly 400kb – suggests that the size of the app does not factor into the likelihood of the bug.

Sorry I wasn’t able to do any direct testing using a newer device. Hopefully all of that data helps you guys.

[brudish]

I discovered something very interesting that also inadvertently fixes the problem. So here’s the deal:

One of my screens – a single screen – was set as a panel with a scrollbar enabled. All of the rest did not have a scrollbar enabled. I discovered this because it was the only screen in the tree that transitioned using SlideLeft. Sure enough, when I enabled the scrollbar on the rest of the tree (no bounce and content area height the size of the screen), the transition worked and the time it takes to transition suppresses the bug behavior in essentially all cases. All of this occurs on the phone I’ve been testing with, which has been by far the most buggy and wonky of the environments I’ve worked in. I don’t believe the bug is completely dealt with, but at the very least the behavior has been mitigated.

That said, I was trying to compare why my test app and your test app produced different behaviors. I noticed that all of your screens were labeled as forms. Now, without the mobi files, I have no idea if you were checking the form box or what options you would have selected given that. Was your test app setting the screens to forms? None of mine are. What sort of difference could that make?

That’s all I’ve got for now.

[support-michael]

Here are the project files for the test app shared with you yesterday. form_1.mobi is the starting design file. See attachment linked_mobi.zip
Would you be willing to share your project with us? If yes please email a zipped archive (10 mb limit) of your project files to
support at genuitec dot com
with title: mobione project for android multi-click issue
and include a url in the message back to this thread.

Attachments:

You must be logged in to view attached files.

[brudish]

I sent an email with my test app attached. Using the newer version of your test app included above (the one from the second reply had no panels) I was intermittently able to reproduce the behavior on pages which had scrolling disabled. Again, pages with scrolling disabled also failed to perform transitions that weren’t Fade.

[brudish]

Just responding to mention that we didn’t let this lie. Since I was able to use the scrollable panels to mitigate the bug behavior, we went forward with that as a stand-in fix. I ended up experiencing other issues by building with MobiOne 2.5M3 and reverting to 2.3 got me back on track. Since we were gearing to do a commercial release and 2.5M3 is not suggested for anything other than development use, that seems par for the course. We’re happy with the results though. I do want to thank you guys again for providing me with the kind of constructive dialogue that ultimately led to me finding the work-around.

[support-octavio]

Hi brudish,

Thanks for working with us on this issue. The info you have provided has been most helpful (a model support case). Our dev team has continued investigating and implemented a small change that we believe will be helpful in resolving this issue. We are making a available a dev build (https://drive.google.com/file/d/0B2UbQ9Htq1UWbXFvc2N2TVdkdG8/edit?usp=sharing) that includes this change for use with additional testing.

[Author]

Posts