STR: 1. Have a page open with scrollable lists (bug with a long enough CC list is perfect. 2. Click on another app so Firefox is unfocused but still visible. 3. Move the mouse over the list and see that you can scroll it with the mouse wheel 4. Move the mouse out of the list and see that the mouse wheel still scrolls the list.

This worked OK in 1.8.1 but is broken in 1.9. It's not just lists, either; it's (probably) anything that creates a child widget; e.g. <select size/multiple>, <div> with overflow:auto, <iframe>, etc. In the background, it looks like any mouse events sent to us are being sent to the last-focused-in-the-foreground child widget instead of the currently-"hovered" child widget.

1a. with Camino 2.0a1 pre (Gecko 1.9.0) I can reproduce step 3 in comment 0, but not step 4. 1b. I can reproduce exactly the same with the latest WebKit nightly (steps: * open attached test case in WebKit * scroll list * move Mail.app in front * list is still scrollable when mouse pointer is over it ) 2. With the latest Minefield nightly, I can repro step 3 and step 4 from comment 0. 10.5.5/Intel in case it matters, (dirty) Kensington mouse-in-a-box

This bug sounds closely related to bug 425556. And I'd bet a variant of my patch for bug 425556 (one that effected mouse-scroll events, instead of mouse-moved events) would fix this bug.

To be clear, step 4 is the actual bug (and I was able to reproduce it easily with my Camino 2.0a1pre build from last night, Intel/10.5.4, MBP trackpad).

I don't think this is similar to bug 425556. It's rather the opposite - I think sending mouse move events to background windows would fix it. My guess is: Due to the fact that we don't send mousemove events to background windows, the mouse wheel transaction manager in nsEventManager.cpp gets confused over which scrollView is the active one. Maybe we can fix it by updating the mouse wheel transaction on mousescroll, too (not only on mousemove).

(In reply to comment #6) > windows, the mouse wheel transaction manager in nsEventManager.cpp I meant nsEventStateManager.cpp.

commment 6 is exactly.

I suggest we find out how other Cocoa apps handle mouse-moved events, and emulate that behavior. Ditto for how all mouse events are handled in background windows. If we do end up sending mouse-moved events to background windows, we'll probably also need to make a bunch of other changes -- since the code now generally assumes this won't happen. I'll get around to this eventually. But I certainly wouldn't mind if someone else gets to it first.

The current plan for mouse event handling on background events is in bug 392188 comment 20 to 23. Another, maybe easier way to fix this bug would be to have a field on scroll events that says "bypass scroll transaction manager" that would be set when it's dispatched to a background window.

Can anybody still reproduce this bug (or bug 617621)?

> Can anybody still reproduce this bug I still can, even in today's most recent nightly (testing on OS X 10.6.5).

I *guess* this patch fixes this bug but I've not tested yet.

Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information