Opened 6 years ago

Closed 5 years ago

#17003 closed defect (wontfix)

Non "dojox.mobile.ListItem" items receive event upon view transition (Android 2.x)

Reported by: Sebastien Pereira Owned by: Adrian Vasiliu
Priority: undecided Milestone: tbd
Component: DojoX Mobile Version: 1.8.3
Keywords: Cc: Patrick Ruzand, bill, cjolif
Blocked By: Blocking:

Description (last modified by Sebastien Pereira)

Given the following source (see attachment), this creates a home View with two List Items which transition to two further views. Each of these other view contain some element which when the transition ends receives the initial event which triggered the transition.

Test case 1
From the home View, select the first List Item but be sure to place your finger above where the input field is in the transitioned view. The input element receives the event from the selection of the first view from the home View.

Test case 2
From the home View, select the second List Item. After the transition the event is triggered on the DIV element.

Initially reported and reproduced : 1.8.3 on Android 2.x

Partially reproduced (test case 1 only) : 1.9.0b2 on Android 2.x, 1.9.1 on Android 2.x/4.x

Attachments (2)

test_transition-touch-events.html (3.7 KB) - added by Sebastien Pereira 6 years ago.
Provides 2 test cases for dojox/mobile/tests
17003_dojo1.9.patch (1.0 KB) - added by Sebastien Pereira 6 years ago.
Virtual Keyboard (VK) is displayed on mousedown events. mousedown is fired ~>300ms after touchend. View transition is done on touchstart. In some cases mousedown happens after the transition and the focus on the target element cause the VK to show up. This patch aims to prevent VK to show up when a destination transition contains an input text (or any other element that trigger the VK).

Download all attachments as: .zip

Change History (23)

comment:1 Changed 6 years ago by Eric Durocher

Component: EventsDojoX Mobile
Owner: changed from Kris Zyp to Eric Durocher

Changed 6 years ago by Sebastien Pereira

Provides 2 test cases for dojox/mobile/tests

comment:2 Changed 6 years ago by Sebastien Pereira

This file (test_transition-touch-events.html) should be added to dojox/mobile/tests to enhance test coverage for current and future releases.

Sebastien Pereira (IBM, CCLA)

comment:3 Changed 6 years ago by Adrian Vasiliu

Owner: changed from Eric Durocher to Adrian Vasiliu
Status: newassigned

Indeed, test case 1 is still reproducible with 1.9.0 and current trunk. For the time being, we still lack the fix..., but seb's test is anyway helpful. seb, there would be some improvements to do in the test:

  • It imports deviceTheme as an AMD module, which is NOT recommended (should import it using <script>).
  • Indent using tab, not blank.
  • Use /, not . for module names in data-dojo-type.
  • Add visibility:hidden on <body>.
  • For consistency with our other tests, put the <script> inside <head>, not inside <body>.
  • And a tiny typo in the prose of the GUI: ListeItem? => ListItem?.

Could you please update the test to fix that? Ideally, take this opportunity to submit it as a git pull request, and include in the commit the addition of an entry for this new test to tests/index.js.

comment:4 Changed 6 years ago by Sebastien Pereira

Changes are reported in pull request dojo/dojox#6.

comment:5 Changed 6 years ago by Patrick Ruzand <pruzand@…>

Resolution: fixed
Status: assignedclosed

In 114653d68e2f4f25b7e5d57aac6e53f4a861afab/dojox:

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

comment:6 Changed 6 years ago by Adrian Vasiliu

Resolution: fixed
Status: closedreopened

Unless I'm missing something, the issue is not fixed (I still reproduce the issue titled "test case 1" in the description on Galaxy Tab Android 2.2), and the commit only includes Sébastien's test case, not the fix of the issue. Hence I reopen.

comment:7 in reply to:  6 Changed 6 years ago by Patrick Ruzand

Replying to Adrian:

Unless I'm missing something, the issue is not fixed (I still reproduce the issue titled "test case 1" in the description on Galaxy Tab Android 2.2), and the commit only includes Sébastien's test case, not the fix of the issue. Hence I reopen.

you are right, I should have used #refs. thanks !

comment:8 Changed 6 years ago by rgillan

Not sure if it's the same issue but we've seen something similar with textboxes on the transitioned to view triggering the keyboard to popup.

Our configuration is two scrollable views, with a dGrid in the first view, which on selection moves to a second scrollable view with a form which is built programmatically. If there is a text box on the second view in line with where the user clicked on the dGrid in the first view then the keyboard pops up.

We're on 1.9.1, and the way we have stopped it happening is to debounce (using the dGrid utility) the touch event on the dGrid about 500mS, which seems to prevent the keyboard popping up (but also delay the transition which is not the preference). Looks like the touch event is somehow still propagating through to the second view. We don't know whether it is something to do with dojoClick although it was a more rare occurrence on 1.8.x. Hope this helps

comment:9 Changed 6 years ago by Sebastien Pereira

Cc: Patrick Ruzand bill added

Changed 6 years ago by Sebastien Pereira

Attachment: 17003_dojo1.9.patch added

Virtual Keyboard (VK) is displayed on mousedown events. mousedown is fired ~>300ms after touchend. View transition is done on touchstart. In some cases mousedown happens after the transition and the focus on the target element cause the VK to show up. This patch aims to prevent VK to show up when a destination transition contains an input text (or any other element that trigger the VK).

comment:10 Changed 6 years ago by Sebastien Pereira

Description: modified (diff)

comment:11 Changed 6 years ago by Sebastien Pereira

Description: modified (diff)

comment:12 Changed 6 years ago by cjolif

Cc: cjolif added

comment:13 Changed 6 years ago by Patrick Ruzand

Milestone: tbd1.10

comment:14 Changed 6 years ago by Adrian Vasiliu

The description says the case 1 is reproducible with 1.9.1 on Android 2.x/4.x, I do not reproduce it with either 1.9.1 or current master on

  • Galaxy Tab 10.1 GT-P7510 Android 4.0.4 (stock browser and chrome)
  • Galaxy Tab 3 10.1 GT-P5210 Android 4.2.2 (stock browser and chrome)

with either stock browser or Chrome, while I do reproduce on

  • Galaxy Tab GT-P1000 Android 2.2
  • HTC Desire Android 2.2
  • HTC Sensation Android 2.3.4

On these Android 2.x devices, the issue is indeed gone with @seb's patch applied.

@seb, was there any Android 4.x device where you reproduced the issue?

If indeed this is reproducible only on Android 2.x, it's a bit a pity to take a risk by doing a dojo/touch change for it, but since we do support Android 2.x, it might be worth doing it. Hence, @seb, I suggest you create a pull request for it (according to the current process).

Last edited 6 years ago by Adrian Vasiliu (previous) (diff)

comment:15 Changed 6 years ago by Adrian Vasiliu

On further advice, it appears that it would be worth going for a dojo/touch change only if this would be reproducible on Android 4.x (not only on Android 2.x). As on my side I only reproduced on Android 2.x, remains to see if it goes differently for seb.

comment:16 Changed 5 years ago by Sebastien Pereira

I am not able to reproduce the issue on:

  • Nexus 5 Android 4.4.2
  • Samsung GS4 Active Android 4.2.2
  • Samsung Galaxy Tab3 Android 4.1.2

Unfortunately I do not recall the device I used to test in the first place. However I can still reproduce on Android 2.3.4. So it is consistent with Adrian's last observations. I think we should exclude this ticket from 1.10 as the risk-benefit balance is questionable.

Last edited 5 years ago by Sebastien Pereira (previous) (diff)

comment:17 Changed 5 years ago by Patrick Ruzand

Milestone: 1.10tbd

comment:18 Changed 5 years ago by Adrian Vasiliu

Or maybe close it as "won't fix"? Ok, after 1.10 the risk would be lower because we'd have more time to test, but most of the reasoning would still hold.

comment:19 Changed 5 years ago by cjolif

and I would that if we come up with 1.11 in a year Android 2.x priority will be even lower so maybe wontfix is better indeed.

comment:20 Changed 5 years ago by Sebastien Pereira

Ok, agreed to close it as wontfix.

comment:21 Changed 5 years ago by Adrian Vasiliu

Resolution: wontfix
Status: reopenedclosed
Note: See TracTickets for help on using tickets.