390120 - Autoscroll goes crazy when I move the cursor up into the autoscroll square

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Jesse Ruderman]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a7pre) Gecko/2007072204 Minefield/3.0a7pre

Steps to reproduce:
1. Middle-click in a long web page.
2. Move the cursor a bit below the autocomplete square.
3. Slowly move the cursor back up into the autocomplete square.

Result: When the cursor is just over the square's bottom border, it starts scrolling up very fast.

Expected: Go directly from scrolling down very slowly to not scrolling at all.

This is not a regression from bug 321447; I can reproduce this bug in a 2007-07-13 build as well as a more recent build.

Comment 1

[Steven Michaud [:smichaud] (Retired)]

Bizarre.

I can reproduce this on OS X, but it doesn't happen on Windows (I
tested on a 2007-07-10 nightly).

I suppose it's a Cocoa Widgets bug (some kind of math error).

Comment 2

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

This is probably more Mac suckage.  I suspect the mouse position is being reported as something strange when it's over a popup, which is inconsistent with the other platforms.   To confirm that, add some dumps to http://mxr.mozilla.org/seamonkey/source/toolkit/content/widgets/browser.xml#810 - it's probably a widget bug.

Comment 3

[Markus Stange [:mstange]]

Attachment: Patch v1.0

When sending a mouse move event to a different view, the mouse location has to be converted into the new view's coordinate system.

Comment 4

[Markus Stange [:mstange]]

There's some funny stuff going on here. The patch only fixes this bug but doesn't address the core problem.

The real problem is the fact that we use two competing methods of hit testing that don't always agree with each other:
1. [[mWindow contentView] hitTest:...] [1] and
2. nsCocoaUtils::FindWindowUnderPoint(...) [2].

From what I have seen, I think we can say that NSView-hitTest [3] is the inaccurate one.

So what happens when the mouse is moved over the autoscroll square bottom border?

1. nsChildView-mouseMoved [4] is called on the main window ([mWindow frame] returns a large rect).
2. [self ensureCorrectMouseEventTarget:theEvent] is called.
3. ensureCorrectMouseEventTarget calls nsCocoaUtils::FindWindowUnderPoint. [2]
4. FindWindowUnderPoint traverses all windows from front to back, doing hit tests using NSPointInRect(aPoint, [currentWindow frame]).
5. FindWindowUnderPoint correctly finds the autoscroll square. NSPointInRect returns YES.
6. ensureCorrectMouseEventTarget correctly reroutes the event to the view of the autoscroll square. [5]
7. nsChildView-mouseMoved [4] is entered again, but this time on the autoscroll square window ([mWindow frame] returns a small, 28x28 rect). windowEventLocation.y == 0, so the cursor is definitely located in the lowermost pixel row of the autoscroll square. (The y position is measured from the bottom of the view, it's flipped.)
8. ensureCorrectMouseEventTarget is called again, traversing the windows from front to back a second time, coming to the same conclusion and consequently not rerouting again.
9. We've finally arrived at the call to hitTest, line 2675. [1]
10. hitTest returns nil, which means that the mouse cursor is not inside the current view.
(This is wrong - NSPointInRect(windowEventLocation, [[mWindow contentView] frame]) still returns YES.)
11. Our code assumes that the mouse has left the window, but processes the event anyway, rerouting it to sLastViewEntered.
This is where my patch inserts a missing conversion of the mouse location (viewEventLocation is still relative to the current view, not to sLastViewEntered).
12. event.screenY gets a wrong value, browser.xml does wrong calculations, autoscroll goes crazy.

So hitTest seems to be off exactly one pixel to the top: It returns nil in the bottom border of the view and it doesn't return nil in the pixel row above the top border of the view. Maybe this has to do with the Y coordinate being flipped - I don't know.

What should we do here? Remove all calls to hitTest and replace them with calls to nsCocoaUtils::FindWindowUnderPoint where necessary?

Should I file a follow-up bug on this issue?

[1] http://mxr.mozilla.org/firefox/source/widget/src/cocoa/nsChildView.mm#2675
[2] http://mxr.mozilla.org/firefox/source/widget/src/cocoa/nsCocoaUtils.mm#101
[3] http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSView_Class/Reference/NSView.html#//apple_ref/occ/instm/NSView/hitTest:
[4] http://mxr.mozilla.org/firefox/source/widget/src/cocoa/nsChildView.mm#2635
[5] http://mxr.mozilla.org/firefox/source/widget/src/cocoa/nsChildView.mm#2448

Comment 5

[Markus Stange [:mstange]]

The patch has become obsolete. The issue has been fixed by the patch to bug 411597.

Comment 6

[Markus Stange [:mstange]]

marking as RESOLVED FIXED by bug 411597

Comment 7

[Markus Stange [:mstange]]

The underlying bug with the two conflicting ways of hit testing has been fixed by bug 515003. We now use NSMouseInRect instead of NSPointInRect, because it treats rectangle edges the same way [NSView hitTest:] does.