Closed Bug 694268 Opened 10 years ago Closed 10 years ago
Modifier keys (e
.g . shift Key) always true for touch events (e .g . touchstart)
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.
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
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)
Attachment #567531 - Flags: review?(wjohnston) → review+
Oops, accidentally closed this when pushing to inbound. Re-opening because this is not on mozilla-central yet.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Filed bug 695407 to fix this for real on devices with keyboards.
Status: REOPENED → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.