Closed Bug 723597 Opened 10 years ago Closed 10 years ago

Spurious mouseover event fired on page load


(Firefox for Android Graveyard :: General, defect, P2)



(firefox11 affected, firefox12 affected, blocking-fennec1.0 +)

Firefox 13
Tracking Status
firefox11 --- affected
firefox12 --- affected
blocking-fennec1.0 --- +


(Reporter: martijn.martijn, Assigned: blassey)




(Keywords: testcase)


(1 file, 1 obsolete file)

See url testcase, I get to see:
mouseover on DIV - e.screenX: 213 e.sceenY: 96
on my LG Optimus Black
mouseover on DIV - e.screenX: 135 e.sceenY: 204

No mouseover event should be firing while I don't touch the screen of my mobile device.
Is this only on the LG Optimus?
No, I can also reproduce this on the Samsung Galaxy Nexus.

I can always reproduce this, when loading the testcase, then focusing the url bar and then pressing enter in the vkb.
blocking-fennec1.0: --- → ?
we need to know what is going on here.
blocking-fennec1.0: ? → +
Priority: -- → P2
I can't reproduce on current trunk or maple. Martijn confirms that.
Closed: 10 years ago
Resolution: --- → WORKSFORME
Ok, I can still reproduce this with the following steps to reproduce:
- Visit
- Tap on black border box at the top
- Tap on the url bar, press 'Enter' to load the url again

I think this is related to bug 679356.
Depends on: 679356
Resolution: WORKSFORME → ---
With the black border box, I mean the top box with the "double tap on this normal div, double tap on this normal div" text in it.
This might not be related to bug 679356 at all. The testcase in that bug ( ) doesn't act as buggy in current Native Fennec.
No longer depends on: 679356
Is it just a synth mouse move? I would think we wouldn't send them unless we got a mouse move event before, but maybe another type of event is recorded and we get a synth mouse move after that.

Since there is no such thing as a mouse cursor in Fennec, maybe we don't need synth mouse moves at all for Fennec?
We used to fire a mouse event every time we got a page resize due to a bug in nsWindow.cpp which I imagine could have been what we were seeing here. That should be fixed now by bug 603008 (in both XUL and Native).
Attached patch patch (obsolete) — Splinter Review
looks like Timothy was right, this patch to bail before sending synth mouse moves fixes the issue. I suspect that this isn't really how we want to fix it though.
Assignee: nobody → blassey.bugs
Attachment #605168 - Flags: review?(tnikkel)
Comment on attachment 605168 [details] [diff] [review]

I don't know enough about touch based browsers to know if we ever want mouse moves, or synth mouse moves at all. It would be nice if someone with knowledge could speak about this.

With that said there appears to already be a pref, layout.reflow.synthMouseMove, that stops synth mouse moves from triggering after a reflow (one of a few points we trigger one). You'd probably just want to use that pref here to accomplish this.
Attached patch patchSplinter Review
Attachment #605168 - Attachment is obsolete: true
Attachment #605168 - Flags: review?(tnikkel)
Attachment #605213 - Flags: review?(tnikkel)
Attachment #605213 - Flags: review?(tnikkel) → review+
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]
Target Milestone: --- → Firefox 13
Verified fixed in today's build on the Samsung Galaxy Nexus.
Blocks: 679356
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.