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

RESOLVED FIXED in Firefox 10

Status

Fennec Graveyard
General
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: Samat Jain, Assigned: mbrubeck)

Tracking

({testcase})

Firefox 8
Firefox 10
testcase
Dependency tree / graph

Details

(Whiteboard: [pushed], QA?)

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
Created attachment 566771 [details]
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.

Updated

6 years ago
Attachment #566771 - Attachment mime type: text/plain → text/html
confirmed.

In mobile/chrome/content/content.js, event seems to be initialized by shiftkey/ctrlKey = true...
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

6 years ago
OS: Linux → Android
Hardware: x86_64 → ARM
(Assignee)

Updated

6 years ago
Assignee: nobody → mbrubeck
Blocks: 544614
tracking-fennec: --- → ?
Keywords: testcase
(Assignee)

Comment 2

6 years ago
Created attachment 567531 [details] [diff] [review]
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.
Attachment #567531 - Flags: review?(wjohnston)
(Assignee)

Updated

6 years ago
Status: NEW → ASSIGNED
status-firefox10: --- → affected
status-firefox9: --- → affected
Whiteboard: [has patch]
Attachment #567531 - Flags: review?(wjohnston) → review+
(Assignee)

Comment 3

6 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/6d4a31aa08ef
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
status-firefox10: affected → fixed
OS: Android → All
Hardware: ARM → All
Resolution: --- → FIXED
Whiteboard: [has patch] → [pushed]
Target Milestone: --- → Firefox 10
(Assignee)

Comment 4

6 years ago
Oops, accidentally closed this when pushing to inbound.  Re-opening because this is not on mozilla-central yet.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Updated

6 years ago
Blocks: 695407
(Assignee)

Comment 5

6 years ago
Filed bug 695407 to fix this for real on devices with keyboards.
Status: REOPENED → ASSIGNED
https://hg.mozilla.org/mozilla-central/rev/6d4a31aa08ef
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED

Updated

6 years ago
Whiteboard: [pushed] → [pushed], QA?
tracking-fennec: ? → ---
You need to log in before you can comment on or make changes to this bug.