Persona is no longer an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 679356 - After tapping link, panning down causes mouseout and mouseover events
: After tapping link, panning down causes mouseout and mouseover events
: regression, testcase
Product: Core
Classification: Components
Component: Layout: View Rendering (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: Timothy Nikkel (:tnikkel)
: Jet Villegas (:jet)
Depends on: 723597
Blocks: 655267
  Show dependency treegraph
Reported: 2011-08-16 08:07 PDT by Martijn Wargers [:mwargers] (not working for Mozilla)
Modified: 2012-03-13 08:37 PDT (History)
5 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

testcase (5.66 KB, text/html)
2011-08-16 08:07 PDT, Martijn Wargers [:mwargers] (not working for Mozilla)
no flags Details

Description Martijn Wargers [:mwargers] (not working for Mozilla) 2011-08-16 08:07:11 PDT
Created attachment 553479 [details]

Steps to reproduce:
- Use Fennec, visit testcase
- Tap on one of the links. After this 'mouseover - mousemove - mousedown - mouseup - click - ' text is shown, which is correct.
- Pan down

Expected result:
- Only 'touchmove' text is getting added, no other links suddenly getting the hovered look.

Actual result:
- After the 'touchmove' text, 'mouseout' and 'mouseover' is being added. Also, another link gets the blue background color (from the css :hover rule). This is also the reason I discovered this bug. Links getting hovered without a good reason in Fennec.

This seems to have regressed between 2011-05-11 and 2011-05-12:

Considering the branch dates, I guess this bug also occurs in Fennec 6:
Comment 1 Timothy Nikkel (:tnikkel) 2011-08-17 12:14:43 PDT
Which part of the problems mentioned does the regression range correspond to? All of them?
Comment 2 Martijn Wargers [:mwargers] (not working for Mozilla) 2011-08-17 13:46:30 PDT
I assume this is a regression from bug 655267. It seems to me the most logical.

All of the problems are caused by this regression. A mouseover causes the :hover rule to be applied, that's a natural consequence of the mouseover event getting fired over the element.
Comment 3 Timothy Nikkel (:tnikkel) 2011-08-17 13:52:11 PDT
So no mouseover event was fired at all before 2011-05-11?
Comment 4 Martijn Wargers [:mwargers] (not working for Mozilla) 2011-08-17 13:59:10 PDT
Indeed, no mouseover event was fired, only touchmove.
It should act like before you tapped on one of the links. Also compare with the stock Android browser.
Comment 5 Timothy Nikkel (:tnikkel) 2011-08-31 20:33:16 PDT
Fennec uses nsIDOMWindowUtils::SendMouseEventToWindow to send some mouse events to the content process. This sends them directly to the presshell and bypasses the widget and view manager. So moving synth mouse move code from the view manager made us start sending synth mouse moves where we didn't before simply because the view manager of the content process never sees any mouse events.

The coordinates of the synth mouse move that we do send are wrong because the content process only gets a few mouse events (clicks I guess) so we don't get to update the mouse position to be accurate.

Does Fennec even need synth mouse moves at all? Do we even have a concept of where the mouse is? Can we just disable them?
Comment 6 Timothy Nikkel (:tnikkel) 2011-08-31 20:35:00 PDT
Not sure who should see my question in comment 5.
Comment 7 Martijn Wargers [:mwargers] (not working for Mozilla) 2012-03-13 08:37:04 PDT
This seems to be fixed in today's Nightly Fennec trunk build on mozilla-central, so I think this was fixed by bug 723597.

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