dojo/touch causing dijit/form/DateTextBox to close on Android 4.4

[Bryan Forbes]

On Android 4.4, tapping on the button of a dijit/form/DateTextBox (for instance, on ​the dijit/form/DateTextBox test page) causes the calendar to show up for a bit and then close. I have tracked it down to the mousedown handler from ​dojo/touch that is hooked up in ​dijit/_HasDropDown#postCreate. By the time the mousedown event fires, the 1 second window has elapsed and dijit/_HasDropDown#_onDropDownMouseDown is run, which closes the calendar. Is there a reason that both touchstart and mousedown are hooked up? Increasing the 1 second window in the dojo/touch handler fixes the problem, but that seems like the wrong way to fix this issue.

[bill]

Is there a reason that both touchstart and mousedown are hooked up?

Yes, it's so dojo/touch will work on machines with both touch screens and mice, see #13048.

I'm not sure how else to achieve mouse and touch support w/out a delay. You might be able to suppress the mousedown event by calling evt.preventDefault() on the touchstart/touchmove/touchend event, but that could lead to unintended side effects so I'd be very nervous about changing it, especially for a point release.

[bill]

Since you mentioned that it fails on the emulator, I did:

1. Installed ​http://developer.android.com/sdk/installing/bundle.html
2. Start Eclipse.app from eclipse/ directory
3. From window menu, launch "Android Virtual Device Manager", and made a configuration called "tablet"
4. From the sdk/tools directory run ./emulator -avd tablet (alternately you can apparently press the "Start" button on the "Android Virtual Device Manager")
5. Press power button and then globe icon (to launch browser)
6. Loaded test_DateTextBox.html and ran test

It's working for me fine except the first time you open a drop down. Opening the same drop down again or subsequently opening another drop down works fine.

Your ticket description implies that the drop down always closes every time you open it, right? How do you reproduce that problem?

[trac-o-bot]

Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!

[Garima]

Are you trying 1.9 version test_DateTextBox.html.I'm also facing the same issue with dojo 1.8 and on android.Someone please help.

[Garima]

Please reopen the ticket

[dylan]

fwiw, I do not see this issue with Android 4.3 (using Sauce Labs) with either master or the 1.9.2 release. Unfortunately Sauce Labs doesn't have Android 4.4 yet for me to test.

(this is testing the test_DateTextBox.html page at ​http://downloads.dojotoolkit.org/release-1.9.2/dojo-release-1.9.2/dijit/tests/form/test_DateTextBox.html and ​http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_DateTextBox.html )

Could you please specify the following:

• Exact version of Dojo
• How you are testing (which device and exact version of Android, or emulator?)

[Bryan Forbes]

• Dojo version: 1.9.2 and nightly
• Android 4.4 emulator (it does not happen in Android 4.3) from SDK version adt-bundle-mac-x86_64-20131030
• The settings I'm using for the VM are here: ​http://cl.ly/image/2q1X381d1X0F
• To reproduce:
  1. Run sdk/tools/android avd
  2. Create a VM with the settings from the included image (optional if one is already included)
  3. Select the VM and click "Start..."
  4. Tap the globe to start the browser
  5. Navigate to ​http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_DateTextBox.html
  6. Tap on the arrow button of the first DateTextBox instance on the page
  7. The calendar will briefly show and then hide with focus going to the text box of the DateTextBox

[Colin Snover]

1.9.3 is released; moving all outstanding tickets to next milestone.

[hal1984]

Replying to BryanForbes:

• Dojo version: 1.9.2 and nightly
• Android 4.4 emulator (it does not happen in Android 4.3) from SDK version adt-bundle-mac-x86_64-20131030
• The settings I'm using for the VM are here: ​http://cl.ly/image/2q1X381d1X0F
• To reproduce:
  1. Run sdk/tools/android avd
  2. Create a VM with the settings from the included image (optional if one is already included)
  3. Select the VM and click "Start..."
  4. Tap the globe to start the browser
  5. Navigate to ​http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_DateTextBox.html
  6. Tap on the arrow button of the first DateTextBox instance on the page
  7. The calendar will briefly show and then hide with focus going to the text box of the DateTextBox

I can confirm this scenario in 4.4 and 4.4.2 emulator (following step by step, settings included), but only using the ARM cpu in the emulator. Downloading the x86 Atom cpu and Intel Virtualization Acceleration via the ADT manager, and executing the same emulator profile, but with x86 cpu, the widget behavior is perfectly normal. The performance is like 10X+ better in x86 mode, i think that proves the timing is the bug cause.

[hal1984]

In Nexus 5 (android 4.4.2) the behavior is normal.

[bill]

OK, I'll try that. Can you point me to some doc about how I can see the browser's console output, or use a debugger?

[hal1984]

​https://developers.google.com/chrome-developer-tools/docs/remote-debugging

The debug of emulator web browser is equal. Open Chrome(pc, mac) while the emulator web browser is open, and it automatically appears in Tools->Inspect Devices, like the USB connected phones.

[hal1984]

But, I think, the fire of both, a touch and a mouse event in emulators really happen in real devices? It two diferents events are fired, i think, one no must invalidate the other. In the 1000ms window from dojo/Touch a user could actually touch the DateTextBox? and quickly click (in the case of Blackberry) again in less than 1000ms. In that case the click prevented is an inconsistent behavior...

[bill]

Open Chrome(pc, mac) while the emulator web browser is open, and it automatically appears in Tools->Inspect Devices

Oh OK cool, so same idea as debugging on a tethered iPad. I will try it.

But, I think, the fire of both, a touch and a mouse event in emulators really happen in real devices? It two diferents events are fired, i think, one no must invalidate the other. In the 1000ms window from dojo/Touch a user could actually touch the DateTextBox? and quickly click (in the case of Blackberry) again in less than 1000ms. In that case the click prevented is an inconsistent behavior...

I didn't understand all of that (you have a few typos?), but I agree that the 1000ms technique isn't perfect. It's just the best I could come up with.

[bill]

I reproduced the problem, and got the debugger to work after (inadvertently) starting some daemon by calling

$ adb devices

After that I still have no "Inspect Devices" menu but I can attach from Chrome's about:inspect page.

I see the long delay between touchstart and mousedown, and also I see two mousedown events for every touchstart.

[bill]

hal1984 is right, it's about the processor speed. I put a fix in ​https://github.com/dojo/dojo/pull/59. If either of you guys want to try it before I push to the mainline, that would be good.

[hal1984]

Replying to bill:

I didn't understand all of that (you have a few typos?), but I agree that the 1000ms technique isn't perfect. It's just the best I could come up with.

My english is very buggy :(, i'm working to improve it. I meant in the previous paragraph that there are two possible scenarios:

1. The mouse and the touch event are counterintuitively fired by the emulator with only one user interaction ... In that case ignore the second event is right.
2. The mouse event and touch event are both triggered on purpose by the user, separated by a fraction of a second. In that case ignore the second event I think it would be wrong.

[Bill Keese <bill@…>]

In db467f31dc27a3eebdd3b3d43856479c2f3151c4/dojo:

Error: Processor CommitTicketReference failed

Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

[Bill Keese <bill@…>]

In b28d5c1297d09296da3f3eede2ac2b52e2c86671/dojo:

Error: Processor CommitTicketReference failed

Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

[bill]

FYI, it turns out that on iOS and Android, it's not really necessary to monitor mouse events at all:

• When you connect a mouse to Android, it generates faux touch events.
• And iOS just doesn't support connecting a mouse at all.

So, that's another approach to fixing the exact problem listed in this ticket. It doesn't however address the duplicate click events (synthetic click immediately after touchend vs. native click 300ms later). For that you still need timers. See recent check to fix #17815.

[bill]

#17578 is a duplicate of this ticket.