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.

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.

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

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