694268 - Modifier keys (e.g. shiftKey) always true for touch events (e.g. touchstart)

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Samat Jain]

Attachment: Testcase for shiftKey, ctrlKey and touchstart, touchmove, touchend

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0a2) Gecko/20111012 Firefox/9.0a2
Build ID: 20111012092043

Steps to reproduce:

Attempt to fire touch events (touchstart, touchmove, touchend, possibly others?) across an element (i.e. start dragging over a colored area in attached test case).

Tested w/ Fennec 8b2 on both Linux on x86-64 and Android 2.3 on T-Mobile G2 (HTC Vision).


Actual results:

Event handler is called with an event object whose shiftKey and ctrlKey (possibly others?) attributes are set to true.


Expected results:

Since shift or control keys were not pressed (or rather, they do not exist for most mobile devices), both shiftKey and ctrlKey attributes should be false.

For consistency, with WebKit on the same device the attributes are also false. I've not tried WebKit's behavior w/ a BlueTooth keyboard attached to see whether it is different.

Comment 1

[Makoto Kato [:m_kato] (fever, slow response)]

confirmed.

In mobile/chrome/content/content.js, event seems to be initialized by shiftkey/ctrlKey = true...

Comment 2

[Matt Brubeck (:mbrubeck)]

Attachment: patch

Huh, I'm not sure how this slipped through.

To start with, this patch just sets the modifier flags to "false" all the time.  I'll file a followup bug to set them correctly based on which keys are actually pressed.

Comment 3

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/6d4a31aa08ef

Comment 4

[Matt Brubeck (:mbrubeck)]

Oops, accidentally closed this when pushing to inbound.  Re-opening because this is not on mozilla-central yet.

Comment 5

[Matt Brubeck (:mbrubeck)]

Filed bug 695407 to fix this for real on devices with keyboards.

Comment 6

[Marco Bonardo [:mak]]

https://hg.mozilla.org/mozilla-central/rev/6d4a31aa08ef