Closed Bug 723597 Opened 10 years ago Closed 10 years ago
Spurious mouseover event fired on page load
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.
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.
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.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → REOPENED
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 ( https://bugzilla.mozilla.org/attachment.cgi?id=553479 ) 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).
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
Status: REOPENED → ASSIGNED
Attachment #605168 - Flags: review?(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.
that pref is already set to false for fennec http://mxr.mozilla.org/mozilla-central/source/mobile/android/app/mobile.js#159
Attachment #605213 - Flags: review?(tnikkel) → review+
Status: ASSIGNED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 13
Verified fixed in today's build on the Samsung Galaxy Nexus.
Status: RESOLVED → VERIFIED
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.