Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 692183 - Incorrect behavior of preventDefault() when used with context menu
: Incorrect behavior of preventDefault() when used with context menu
Product: Fennec Graveyard
Classification: Graveyard
Component: General (show other bugs)
: Trunk
: All All
: -- normal (vote)
: Firefox 9
Assigned To: Wesley Johnston (:wesj)
Depends on:
Blocks: 544614
  Show dependency treegraph
Reported: 2011-10-05 11:31 PDT by Dan Walkowski
Modified: 2011-10-18 07:03 PDT (History)
6 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---

testcase (768 bytes, text/html)
2011-10-05 15:14 PDT, Martijn Wargers [:mwargers] (not working for Mozilla)
no flags Details
Patch (877 bytes, patch)
2011-10-05 18:51 PDT, Wesley Johnston (:wesj)
mbrubeck: review+
asa: approval‑mozilla‑aurora+
Details | Diff | Splinter Review

Description Dan Walkowski 2011-10-05 11:31:40 PDT
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Build ID: 20110928134238

Steps to reproduce:

Please visit this page:

I am overriding the press-and-hold behavior by preventDefault() on the context menu event, and substituting my own.

I am using the latest nightly of Fennec.

Actual results:

If, and only if, the page is not scrolled at all, then press-and-hold on an icon behaves correctly.  Pressing for 1 second lifts the icon from the page, allowing you to reposition it.  No context menu is shown.  
However, if the page is scrolled up even 1 pixel, this behavior does NOT happen, but instead it appears the the coordinate system is changed out from under me, causing the press and hold to fail.

Expected results:

The correct behavior should happen no matter how the page is scrolled.
Please note that the correct behavior is observed on every other platform tested:
Safari Mobile
Android default webkit browser.
Comment 1 Martijn Wargers [:mwargers] (not working for Mozilla) 2011-10-05 11:53:38 PDT
A testcase would be nice.
Comment 2 Dan Walkowski 2011-10-05 13:19:16 PDT
I gave you a test case.  Visit the page mentioned above:, and follow the trivial steps mentioned above.
Comment 3 Martijn Wargers [:mwargers] (not working for Mozilla) 2011-10-05 15:14:05 PDT
Created attachment 565031 [details]

This is probably because e.touches[0].clientY returns something different in Fennec. That value seems in Fennec the vertical offset in the window plus the amount scrolled. In the Android stock browser, it's the vertical offset in the window.
Comment 4 Wesley Johnston (:wesj) 2011-10-05 15:35:23 PDT
The github example page seems to work now? Have you fixed something on your end? Is there still a bug in Fennec that we need to address.

Martjin, your problem seems different. If there's a difference, can you file a separate bug to find out which impelementation is right.
Comment 5 Dan Walkowski 2011-10-05 16:39:42 PDT
No, the github page does not work.  Be sure to scroll the page slightly to see the problem. I can demonstrate it for you if you are local to MV, I'm on second floor.
Comment 6 Wesley Johnston (:wesj) 2011-10-05 18:51:45 PDT
Created attachment 565109 [details] [diff] [review]

Not in MV.

Looked into this some more, but I think the description here is wrong and Martijn's right. In every test I can throw at it, contextmenu is fired and preventDefault works. But AFAICT, your page doesn't use the contextmenu event for anything but hiding the context menu, which works. A reduced test case would probably have made this much easier to diagnose.

The page is doing its own "longtap" detection by setting a timer on touchdown. They also register to pick up mouse events. We fire a mousemove event a few hundred ms after touchdown. The page compares the coordinates of touchdown and mousemove events and they don't match.

We fire mouse events using DOMWindowUtils which automatically does the correct pixel conversions for us. We fire touchdown events using our own coordinates. This just makes us correct for client offset. I'm a bit worried about iframes... may need to look at this more.

Note for Dan, if you call preventDefault on the touch events, we won't fire mouse events and you won't have this cross pollination problem. You also won't see our sidebars or the urlbar in us or other browsers pan in. Glad we found the real bug though.
Comment 7 Dan Walkowski 2011-10-06 10:48:35 PDT
wesj: and the real bug is that the e.touches[0].clientY is incorrect?
any chance this will make it into a soonish nightly?
Comment 9 Martijn Wargers [:mwargers] (not working for Mozilla) 2011-10-06 11:28:37 PDT
Dan, you could adjust your code to circumvent this bug.
Comment 10 Ed Morley [:emorley] 2011-10-07 04:17:22 PDT
Comment 11 Wesley Johnston (:wesj) 2011-10-07 10:47:38 PDT
Comment on attachment 565109 [details] [diff] [review]

nominating this for aurora. this is low risk and fixes bad behavior in our original touch events implementation.
Comment 12 Matt Brubeck (:mbrubeck) 2011-10-07 11:42:44 PDT
Additional comments for Aurora approval:  This is a two-line Fennec-only patch that is a straightforward fix for a miscalculation.  It fixes a web compatibility bug that affects at least one JavaScript library in the wild (and published by Mozilla!); see comment 0 for details.
Comment 13 Mark Finkle (:mfinkle) (use needinfo?) 2011-10-13 06:33:11 PDT
Comment 14 Camelia Urian 2011-10-18 05:09:54 PDT
Build ID: Mozilla/5.0 (Android; Linux armv7l; rv:9.0a2) Gecko/20111017 Firefox/9.0a2 Fennec/9.0a2
Device: HTC Desire Z
OS: Android 2.3

Verified issue on above environment:
- If page is scrolled then press-and-hold on an icon behaves correctly: pressing for 1 second lifts the icon from the page, allowing you to reposition it. No context menu is shown. - OK

- If page is NOT scrolled then pressing for 1 second lifts the icon from the page, allowing you to reposition it and also the entire page is scrolled up/down or left/right panels are displayed if moving icon left/right. Is this related to this bug or is it a new issue? 
I will reopen the bug for now. If this is a different issue I will close this bug and open a new one.
Comment 15 Martijn Wargers [:mwargers] (not working for Mozilla) 2011-10-18 05:42:37 PDT
Sounds like a new bug, seems to work for me, btw.
Comment 16 Camelia Urian 2011-10-18 07:03:06 PDT
Bug #695317 was logged for issue described in comment #14.

BAsed on previous 2 comments, marking bug as verified fixed.

Note You need to log in before you can comment on or make changes to this bug.