#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 9 years ago by
Milestone: | tbd → 1.9.3 |
---|---|
Owner: | set to Douglas Hays |
Priority: | undecided → blocker |
Status: | new → assigned |
comment:2 Changed 9 years ago by
Owner: | changed from Douglas Hays to bill |
---|
comment:3 Changed 9 years ago by
comment:4 Changed 9 years ago by
Owner: | changed from bill to Bryan Forbes |
---|---|
Status: | assigned → pending |
Since you mentioned that it fails on the emulator, I did:
- Installed http://developer.android.com/sdk/installing/bundle.html
- Start Eclipse.app from eclipse/ directory
- From window menu, launch "Android Virtual Device Manager", and made a configuration called "tablet"
- From the sdk/tools directory run
./emulator -avd tablet
(alternately you can apparently press the "Start" button on the "Android Virtual Device Manager") - Press power button and then globe icon (to launch browser)
- 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 8 years ago by
Resolution: | → invalid |
---|---|
Status: | pending → closed |
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 8 years ago by
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.
comment:8 Changed 8 years ago by
Priority: | blocker → high |
---|---|
Resolution: | invalid |
Status: | closed → reopened |
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 follow-up: 11 Changed 8 years ago by
Owner: | changed from Bryan Forbes to bill |
---|---|
Status: | reopened → assigned |
- 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:
- Run
sdk/tools/android avd
- Create a VM with the settings from the included image (optional if one is already included)
- Select the VM and click "Start..."
- Tap the globe to start the browser
- Navigate to http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_DateTextBox.html
- Tap on the arrow button of the first
DateTextBox
instance on the page - The calendar will briefly show and then hide with focus going to the text box of the
DateTextBox
- Run
comment:10 Changed 8 years ago by
Milestone: | 1.9.3 → 1.9.4 |
---|
1.9.3 is released; moving all outstanding tickets to next milestone.
comment:11 Changed 8 years ago by
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:
- Run
sdk/tools/android avd
- Create a VM with the settings from the included image (optional if one is already included)
- Select the VM and click "Start..."
- Tap the globe to start the browser
- Navigate to http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_DateTextBox.html
- Tap on the arrow button of the first
DateTextBox
instance on the page- 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:13 Changed 8 years ago by
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 8 years ago by
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.
comment:15 Changed 8 years ago by
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 follow-up: 19 Changed 8 years ago by
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 8 years ago by
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 8 years ago by
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 Changed 8 years ago by
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:
- 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.
- 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.
comment:20 Changed 8 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:20 Changed 8 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:21 Changed 8 years ago by
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.
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.