After tapping link, panning down causes mouseout and mouseover events

RESOLVED FIXED

Status

()

Core
Layout: View Rendering
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: Martijn Wargers (dead), Assigned: tnikkel)

Tracking

({regression, testcase})

Trunk
regression, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
Created attachment 553479 [details]
testcase

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:
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2011-05-11+03%3A00%3A00&enddate=2011-05-12+06%3A00%3A00

Considering the branch dates, I guess this bug also occurs in Fennec 6:
https://wiki.mozilla.org/RapidRelease/Calendar
Assignee: nobody → tnikkel
(Assignee)

Comment 1

6 years ago
Which part of the problems mentioned does the regression range correspond to? All of them?
(Reporter)

Comment 2

6 years ago
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.
(Assignee)

Comment 3

6 years ago
So no mouseover event was fired at all before 2011-05-11?
(Reporter)

Comment 4

6 years ago
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.
(Assignee)

Comment 5

6 years ago
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?
(Assignee)

Comment 6

6 years ago
Not sure who should see my question in comment 5.
(Reporter)

Updated

6 years ago
Blocks: 723597
(Reporter)

Updated

6 years ago
No longer blocks: 723597
(Reporter)

Comment 7

6 years ago
This seems to be fixed in today's Nightly Fennec trunk build on mozilla-central, so I think this was fixed by bug 723597.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Depends on: 723597
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.