218690 - [10.1] Mouse pointer doesn't change over links when moving pointer from tab

Status: RESOLVED FIXED

(Camino Graveyard :: General, defect)

Description

[Stefan [:stefanh]]

Camino 2003081810 and 2003090802 on OS 10.1.5

When you swith to a new tab and move the pointer straight down from the tab to
the browser window, the pointer won't change over links.

As soon as you move the pointer to someplace outside the browser window and back
the pointer starts to change over links.

How to repro:

1. Open two tabs with, for instance, bugzilla reports.
2. Switch tab. Keep pointer over tab.
3. Move pointer straight down to the Mozilla banner (link).
4. Notice that the pointer doesn't change to a hand. Move pointer over other
links on page and notice the absence of a hand.
5. Move pointer back to tab or someplace else outside browser window.
6. Move pointer back to Mozilla banner & notice that the pointer change to a hand.

I've seen this for a long time, but haven't found any reports. The only related
bug I've found is bug 161794. Doesn't occur in Mozilla (using 2003082903 for the
moment).

Comment 1

[Jasper]

Hm I'm not seeing this behaviour. Whta I do see is that the Mozilla banner link
stops some where on the left, where the image stops. When hovering over that
piece of course you don't get the micky mouse hand.

Comment 2

[Stefan [:stefanh]]

I should have written "Move pointer straight down from tab to *any* link"....

Comment 3

[cfranc]

same problem for me. i'm using os x 10.1.5. i think the earlier patch only
worked for os x 10.2 and later....

Comment 4

[Jasper]

10.2 doesn't seem to have have this problem at all.

Comment 5

[Mike Pinkerton (not reading bugmail)]

not sure what we can do here, don't have access to a 10.1 box but we need to try.

Comment 6

[Jasper]

Perhaps Bug 20022 fixed this recently, could you please update again?

Comment 7

[Stuart Morgan]

Still broken.

This appears to be very closely related to bug 234207, which has exactly the
same behavior and fix (moving out of the content area (even to the tabs) then
back in. It's simply one extra way to trigger it that only occurs on 10.1.5.

I won't dup it, as there is unique behavior, but I suspect that a patch for one
would fix both.

Comment 8

[Stuart Morgan]

taking

Comment 9

[Stuart Morgan]

Sorry for spam; forgot to keep pink as a CC.

Comment 10

[Stuart Morgan]

Attachment: Better guess at where we are in relation to a tracking rect

Assume that we are in a new tracking rect only if we were in the old tracking
rect, as indicated by whether or not we are accepting mouse events (rather than
assuming we are always in a new tracking rect).  This will always give us
correct behavior with respect to mouse tracking, since we are only interested
in the event opposite our current setting (leaving if on, entering if off). As
a bonus, this fixes the issue where we lose mouseovers after resizing the
window.

Theoritically, this could fail to trigger the explicit mouseEntered and
mouseExited cursor resets sometimes, but so could the old code. Both ways are
just guesses, but this one is a much better guess.

Comment 11

[Stuart Morgan]

Comment on attachment 147507 [details] [diff] [review]
Better guess at where we are in relation to a tracking rect

Requesting sr, since it's simple.  Pinkerton, I can't remember if you can sr
cocoa widget code; if not please reset the sr? to someone who can.

Comment 12

[Mike Pinkerton (not reading bugmail)]

this patch doesn't fix 234207. am i doing something wrong?

Comment 13

[Stuart Morgan]

> this patch doesn't fix 234207. am i doing something wrong?

No, this fixes *only* the window-resizing part of bug 234207. The rest of that
bug I still only know how to fix by removing the hackery, but that's not an
option for 10.1 (and maybe 10.2, we don't know yet).

Comment 14

[Stuart Morgan]

> No, this fixes *only* the window-resizing part of bug 234207.

I should ammend that statement: this fixes *this* bug, and it also as a side
effect fixes the window-resizing part of bug 234207.

Comment 15

[Mike Pinkerton (not reading bugmail)]

landed on trunk and branch. thanks!