Opened 6 years ago

Closed 6 years ago

Last modified 5 years ago

#17634 closed defect (fixed)

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

Reported by: Bryan Forbes Owned by: bill
Priority: high Milestone: 1.9.4
Component: Dijit - Form Version: 1.9.2
Keywords: Cc:
Blocked By: Blocking:

Description

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.

Change History (23)

comment:1 Changed 6 years ago by Bryan Forbes

Milestone: tbd1.9.3
Owner: set to Douglas Hays
Priority: undecidedblocker
Status: newassigned

comment:2 Changed 6 years ago by Douglas Hays

Owner: changed from Douglas Hays to bill

comment:3 Changed 6 years ago by 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.

comment:4 Changed 6 years ago by bill

Owner: changed from bill to Bryan Forbes
Status: assignedpending

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?

comment:5 Changed 6 years ago by trac-o-bot

Resolution: invalid
Status: pendingclosed

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!

comment:6 Changed 6 years ago by 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.

Last edited 6 years ago by Garima (previous) (diff)

comment:7 Changed 6 years ago by Garima

Please reopen the ticket

comment:8 Changed 6 years ago by dylan

Priority: blockerhigh
Resolution: invalid
Status: closedreopened

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?)

comment:9 Changed 6 years ago by Bryan Forbes

Owner: changed from Bryan Forbes to bill
Status: reopenedassigned
  • 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

comment:10 Changed 6 years ago by Colin Snover

Milestone: 1.9.31.9.4

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

comment:11 in reply to:  9 Changed 6 years ago by 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.

comment:12 Changed 6 years ago by hal1984

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

comment:13 Changed 6 years ago by 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?

comment:14 Changed 6 years ago by 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.

Last edited 6 years ago by hal1984 (previous) (diff)

comment:15 Changed 6 years ago by 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...

comment:16 Changed 6 years ago by 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.

comment:17 Changed 6 years ago by 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.

comment:18 Changed 6 years ago by 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.

comment:19 in reply to:  16 Changed 6 years ago by 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.
Last edited 6 years ago by hal1984 (previous) (diff)

comment:20 Changed 6 years ago by Bill Keese <bill@…>

Resolution: fixed
Status: assignedclosed

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? 

comment:20 Changed 6 years ago by Bill Keese <bill@…>

Resolution: fixed
Status: assignedclosed

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? 

comment:21 Changed 6 years ago by 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.

comment:22 Changed 5 years ago by bill

#17578 is a duplicate of this ticket.

Note: See TracTickets for help on using tickets.