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
- Only 'touchmove' text is getting added, no other links suddenly getting the hovered look.
- 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:
Which part of the problems mentioned does the regression range correspond to? All of them?
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.
So no mouseover event was fired at all before 2011-05-11?
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.
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?
Not sure who should see my question in comment 5.
This seems to be fixed in today's Nightly Fennec trunk build on mozilla-central, so I think this was fixed by bug 723597.