234207 - Mouseover/:hover effects and cursor changes don't work after certain tab/window operations

Status: RESOLVED FIXED

(Camino Graveyard :: General, defect)

Description

[Ruurd Koons]

User-Agent:       
Build Identifier: 2004020608 (v0.7+)

When opening a link into a new tab, then closing that tab by using the
right-click context mouse menu, the links in the tab that becomes the topmost
does not seem to work. If Camino looses the focus, and gets the focus again, the
links work again. When the links doesn't work the last link used to open in a
new tab with is shown as actually being clicked.
When using Apple-W to close the tab, the problem is not there.

Reproducible: Always
Steps to Reproduce:
1. open for example http://www.pctechtalk.com/
2. right-click any of the links and select Open Link in New Tab from the context
menu
3. close the tab by right-clicking on the tab caption, and selecting Close Tab
from the context menu
4. hover your mouse over all the links in the original tab (they don't have the
hover effect, the mouse pointer keeps being the hand indicating a link)
5. click somewhere out of the Camino window (ie the desktop)
6. click in the Camino window (to give it focus again)
7. hover your mouse over the links to find out they work again.

Actual Results:  
links were not 'active' after closing the opened tab by using the mouse

Expected Results:  
it should have made the links 'active' again so they were clickable and
responding to mouse hovering.

Comment 1

[Mike Pinkerton (not reading bugmail)]

even though they don't show the right cursor, can you still click the links? 

Comment 2

[Ruurd Koons]

yes, clicking seems just to work. It's only that it's not clear what is a link
or not.

I found out that if I scroll the page by using the scroll wheel of my browser,
some links light up as if the mouse would hover over them.
The links that light up are at that moment exactly on the position where the
mouse was when I used the context menu on a link to open it in a new tab.
It looks to me like for Camino the mouse position is frozen at the point where I
used the context menu.

Comment 3

[Greg K.]

Confirmed using Camino/2004021008 on Mac OS X 10.2.8. Revising Summary.

The problem is also evident if you open the testcase URL in a new window using
the contextual menu. In that case, merely clicking in the content area restores
mouseover functionality.

Comment 4

[Jasper]

This behaviour is also present if you reszie a window.

1) opena page with links
2) resize the window
3) notice how the cursor doesn't change on mouse over.

Comment 5

[Stuart Morgan]

Weirder yet, following Jasper's steps:
4) Move the mouse over the scroll bar, status bar, bookmark bar, or tool bar
5) Move the mouse back into the content area
6) Notice that mouseovers work again

Comment 6

[Stuart Morgan]

For future reference, there is discussion of similar problems (and their fixes)
in bug 161794, bug 187050, and bug 204024. Some of it should be helpful in
isolating this.

Adding 'and cursor changes' to the summary, to make it easier to find.

Comment 7

[Stuart Morgan]

The resize part of the bug is caused by |assumeInside:YES| in |setFrame| of
nsChildView.mm, which causes us not to get a |mouseEntered| event when the
cursor returns to the content area (and thus not turning on mouse motion
watching). It's fixable by replacing |YES| with |[[self window]
acceptsMouseMovedEvents]|.
http://lxr.mozilla.org/mozilla/source/widget/src/cocoa/nsChildView.mm#2364

The tab context menu is trickier. It only happens when doing something that
makes the tab bar go away, and thus shifts the content and calls |setFrame|. I'm
pretty sure the problem is that we make a new frame that the mouse is *already*
inside (because of the context menu placement), but with
|acceptsMouseMovedEvents| set to |NO| since a |mouseEntered| isn't triggered
while we have the menu up. Normally we'd get one when the menu is dismissed, but
since we've already made the new frame, we don't--or so goes my theory for why
we aren't getting the event.

The correct fix seems like it requires actually checking the mouse location in
|setFrame|, and setting |assumeInside| and |setAcceptsMouseMovedEvents|
appropriately. Is there a good way to do that? If not, what would be the
downside of simply setting both to |YES| in |setFrame|, besides being ugly?

Comment 8

[Stuart Morgan]

While testing various approaches, I made the discovery that I can fix this bug
by removing *all* |setAcceptsMouseEvents| calls from nsChildView.mm, without
regressing any of the bugs I listed in comment 6, on 10.3.3.

Since the consensus of all was that this code was an ugly hack to fix what
seemed to be an Apple bug, and since Apple seems to have fixed it, maybe we
should find out what version of the OS made this code unnecessary, and wrap the
code in a version check. That way, the hack only applies when absolutely
necessary, and fallout like this goes away.

Is there any reason not to do this?

Comment 9

[Stuart Morgan]

Attachment: ignores hack code on 10.2.8+

The mouse monitoring bug that made this hack necessary is fixed in 10.2.8 at
the latest (possibly earlier).	This patch skips the code on those systems.

Tested that there are no regressions of the above bugs after removing the code
in 10.3.3/4, and that the hack is still in place for 10.1.5

Comment 10

[Stuart Morgan]

Comment on attachment 150248 [details] [diff] [review]
ignores hack code on 10.2.8+

pink, if you can NPOB this to check it in yourself, please sr instead.
Otherwise please set appropriate sr? (and 1.7 a? if you deem it worthwhile
polish for 0.8)

Comment 11

[Mike Pinkerton (not reading bugmail)]

patch landed on trunk and branch, leaving for 0.9 so smorgan can verify if this
is fixed on 10.2.0

Comment 12

[Ruurd Koons]

Using todays nightly 2004061608 (v0.8+) the problem seems to be fixed for me
(OSX 10.2.8)

Thanks a lot!

Comment 13

[Stuart Morgan]

Giving my bugs back to pink.

Comment 14

[Ruurd Koons]

Sorry for my late acting, but this bug has been solved by pinkerton a while ago.