Closed Bug 594271 Opened 9 years ago Closed 9 years ago

don't send synth mouse moves if we are in a hidden document

Categories

(Core :: Layout, defect)

defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: tnikkel, Assigned: tnikkel)

References

Details

Attachments

(1 file, 1 obsolete file)

I think that sending synth mouse moves for background tabs may be causing bug 592954 and/or bug 592093, because we send a synth mouse move after we do any reflow. I think we should stop doing that in hidden documents.
Attached patch patch (obsolete) — Splinter Review
Assignee: nobody → tnikkel
Attachment #472953 - Flags: review?(dbaron)
Comment on attachment 472953 [details] [diff] [review]
patch

I think the way this used to work was that if the mouse pointer left the widget, the view manager would have the mouse position set to NSCOORD_NONE, NSCOORD_NONE, since it would get an NS_MOUSE_EXIT event (exit the widget, not to be confused with NS_MOUSE_EXIT_SYNTH).  I think we broke this when we linked view managers between chrome and content and stopped having a widget for the content VM, since then the root VM could be across a hidden/shown boundary.

Does the view manager itself know whether it's active?  It might make more sense to have this check inside SynthesizeMouseMove, right at the start, where it chains up to the root VM.  Then again, this approach is fine, except I think you should also change the other two locations that  call SynthesizeMouseMove, and probably refactor them into an inline method on the pres shell so you don't have the same code in 4 places.
Attachment #472953 - Flags: review?(dbaron) → review-
Attached patch patch v2Splinter Review
(In reply to comment #2)
> Does the view manager itself know whether it's active?  It might make more
> sense to have this check inside SynthesizeMouseMove, right at the start, where
> it chains up to the root VM.  Then again, this approach is fine, except I think
> you should also change the other two locations that  call SynthesizeMouseMove,
> and probably refactor them into an inline method on the pres shell so you don't
> have the same code in 4 places.

The view manager doesn't know directly if it's active, it can probably get basically the same information from the visibility of it's root view. I think we should put this logic in the presshell. I converted the other two calls.
Attachment #472953 - Attachment is obsolete: true
Attachment #473218 - Flags: review?(dbaron)
Comment on attachment 473218 [details] [diff] [review]
patch v2

I didn't realize that was going to need a virtual method, but that's ok.

r=dbaron
Attachment #473218 - Flags: review?(dbaron) → review+
Attachment #473218 - Flags: approval2.0?
Attachment #473218 - Flags: approval2.0? → approval2.0+
http://hg.mozilla.org/mozilla-central/rev/2b952f4d0df2
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.