723597 - Spurious mouseover event fired on page load

Status: VERIFIED FIXED

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

Description

[Martijn Wargers (dead)]

See url testcase, I get to see:
mouseover on DIV - e.screenX: 213 e.sceenY: 96
on my LG Optimus Black
and:
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.

Comment 1

[Doug Turner (:dougt)]

Is this only on the LG Optimus?

Comment 2

[Martijn Wargers (dead)]

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.

Comment 3

[Doug Turner (:dougt)]

we need to know what is going on here.

Comment 4

[Brad Lassey [:blassey] (use needinfo?)]

I can't reproduce on current trunk or maple. Martijn confirms that.

Comment 5

[Martijn Wargers (dead)]

Ok, I can still reproduce this with the following steps to reproduce:
- Visit http://people.mozilla.com/~mwargers/tests/touch%20events/doubletap.htm
- 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.

Comment 6

[Martijn Wargers (dead)]

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.

Comment 7

[Martijn Wargers (dead)]

This might not be related to bug 679356 at all. The testcase in that bug ( https://bugzilla.mozilla.org/attachment.cgi?id=553479 ) doesn't act as buggy in current Native Fennec.

Comment 8

[Timothy Nikkel (:tnikkel)]

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?

Comment 9

[Wesley Johnston (:wesj)]

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).

Comment 10

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: patch

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.

Comment 11

[Timothy Nikkel (:tnikkel)]

Comment on attachment 605168 [details] [diff] [review]
patch

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.

Comment 12

[Brad Lassey [:blassey] (use needinfo?)]

that pref is already set to false for fennec

http://mxr.mozilla.org/mozilla-central/source/mobile/android/app/mobile.js#159

Comment 13

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: patch

Comment 14

[Brad Lassey [:blassey] (use needinfo?)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/e77ca0c6e435

Comment 15

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

https://hg.mozilla.org/mozilla-central/rev/e77ca0c6e435

Comment 16

[Martijn Wargers (dead)]

Verified fixed in today's build on the Samsung Galaxy Nexus.