Mouse wheel scrolls list even after moving out of the list when window is not focused

Assigned to



Widget: Cocoa
10 years ago
8 years ago


(Reporter: mossop, Assigned: smichaud)


({regression, testcase})

Mac OS X
regression, testcase
Bug Flags:
wanted1.9.1 ?

Firefox Tracking Flags

(Not tracked)



(2 attachments)



10 years ago

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.
Keywords: regression, testcase
Created attachment 339169 [details]
testcase with several types of elements-with-scrollbars

Comment 3

10 years ago
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
  * open attached test case in WebKit
  * scroll list
  * move 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

Comment 4

10 years ago
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
Assignee: joshmoz → smichaud
Flags: wanted1.9.1?
Priority: -- → P2
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.
Blocks: 312831

Comment 9

9 years ago
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).
Created attachment 505019 [details] [diff] [review]
Patch v1.0

I *guess* this patch fixes this bug but I've not tested yet.
You need to log in before you can comment on or make changes to this bug.