204024 - Cursor does not properly update on some sites

Status: RESOLVED FIXED

(Camino Graveyard :: General, defect)

Description

[Nathan Hamblen]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4b) Gecko/20030421 Chimera/0.7+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4b) Gecko/20030421 Chimera/0.7+

(There are other circumstances that will cause the cursor to stop updating, but
this is the only one I'm sure of.) The patch for 161794 was a little too
ambitious in turning off cursor updates when the cursor leaves the window,
because there are times (like opening a link in the background) that cocoa says
the cursor has left the window when it hasn't really.

Reproducible: Always

Steps to Reproduce:
1. Adjust prefs so that Camino loads a window in the background when command
clicking.
2. Command click a link.

Actual Results:  
The cursor no longer updates for the content view.

Expected Results:  
The cursor should continue to update (hand, ibeam, etc) as it passes over the
content.

Comment 1

[Nathan Hamblen]

Attachment: patches nsChildView.cpp to stop turning off mouse move monitoring

This graceless patch removes the call to stop monitoring the mouse when exiting
a view, which fixes this bug. However, to avoid losing cursor monitoring after
using the bookmarks or any other menu, we have to turn off the monitoring then
turn it back on when the mouse enters the view. Yuck.

Comment 2

[Greg K.]

So Camino builds after 0421 should exhibit this bug? (Bug 161794, comment 17.)
It seems to WorkForMe using Camino/2003-04-25-05.

Comment 3

[Nathan Hamblen]

You're right. Sorry about that, the test case was solid on a personal build of
Camino I was using, but apparently that build was flawed. People on the list
WERE complaining about the cursor not being right lately, though. Please wait a
few days before closing the bug while I solicit them for test cases, and also
see if I can come up with one of my own that is repeatable on a real build.

Comment 4

[Nathan Hamblen]

Ok, I think the problem is with sites using Flash or other plugins. Try
http://www.allmusic.com/ . Move the mouse around the page, being sure to pass
over the banner ad at some point. I expect you should see the problem in
2003-04-25-05; I am definitely getting it in 2003-05-01-05.

The patch fixes it. Knowing what's causing the problem now, I may be able to
cook up a better one.

Comment 5

[Nathan Hamblen]

Attachment: appropriately turns off gecko cursor monitoring

By checking if the current view has a parent ChildView, I was able fix the
problem with plugins that have their own view.

Comment 6

[Derek Schrock]

Comment #2, I don't have a testcase for this but it does happen to me.

Comment 7

[Simon Fraser [no longer active]]

Won't nsChildViews in iframes and framesets have parents that are also nsChildViews?

Comment 8

[Nathan Hamblen]

I think so, which is all the more reason this patch is necessary! ;) When
leaving an IFRAME or FRAMESET we should not be turning off cursor monitoring,
just like when leaving a plugin.

Comment 9

[Simon Fraser [no longer active]]

I think calling [[self window] setAcceptsMouseMovedEvents: NO]; is a bad thing
to do anywhere in this code. You have no idea what other views in the window
might want to get mouse events, since gecko may be embedded in some other app
over which you have no control.

Also, the calls to [flagsChanged] in mouseEntered and mouseExited propagate up
to the super class, which also seems wrong in this context.

Comment 10

[Nathan Hamblen]

Calling [setAcceptsMouseMovedEvents: NO] at some point, followed by a
[setAcceptsMouseMovedEvents: YES] was the only way I could find to fix bug
161794. For some bad reason, Cocoa decides to stop forwarding mouse moved events
to a window as soon as a click occurs anywhere outside its bounds (like the menu
bar). My guess is Cocoa intends for us only to turn monitoring on when it is
needed, i.e. when the mouse is in the bounds of a particular view, and turn it
off when it leaves. If another Camino view decides it needs mouse monitoring, it
should turn it on and off itself. (mouseDragged is a different story of course,
it doesn't get enabled or disabled.)

But if you don't agree with that reasoning, there is always attachement 122248.
It just jiggles the switch on mouse monitoring every time the mouse enters the view.

As for the flagsChanged method calling its super, that may be off. After all,
the flags didn't really change. I can't see it doing any harm, but...

Comment 11

[Nathan Hamblen]

Or even attachment 122182 [details] [diff] [review] , the deprecated one on this bug. ;) I'm not sure
where that other number even came from.

Comment 12

[Mike Pinkerton (not reading bugmail)]

except the mousemove flag is global for a window, not on a per-view level. you'd
have to keep a stack of remembered values as you went deeper into subviews. that
just seems wrong.

i have another app that most definately has this flag set for windows and i
wouldn't want any embedded geckos mucking with it.

Comment 13

[Nathan Hamblen]

Does your other app suffer from bug 161794? Cocoa seems to mess with that flag,
whether you ask it to or not.

Comment 14

[Simon Fraser [no longer active]]

Maybe we should just fire off a timer, and sniff the mouse position from that,
rather than using mouse moved events. Or we could use tracking rects
<http://developer.apple.com/techpubs/macosx/Cocoa/TasksAndConcepts/ProgrammingTopics/BasicEventHandling/Tasks/HandlingMouseTracking.html>
perhaps with the traditional 1x1 pixel rect under the mouse hack.

Regarding [setAcceptsMouseMovedEvents], see
<http://cocoa.mamasam.com/COCOADEV/2002/03/2/28963.php> and
<http://cocoadevcentral.com/pipermail/cocoa-pro/2002-August/000043.html>.

Comment 15

[Mike Pinkerton (not reading bugmail)]

is this bug related to 159478?

Comment 16

[Nathan Hamblen]

The bug 159478 description encompasses a lot, but after the first few comments
it starts to talk specifically about problems when the mouse leaves the browser
content, and there is even a patch submitted for that situation. There is
another bug out there to which I've submitted a patch that IS a dup of 159478.
I'm not sure what the number is though, and I'm not on my real computer where I
could look it up. Anyway one of those patches should go in. As for THIS bug, it
didn't occur until my patch for bug 161794 hit the tree, so it couldn't be
related to anything before that point.

Comment 17

[Mike Pinkerton (not reading bugmail)]

i have the patch for 187050 applied and it fixes this bug as well. should it?

Comment 18

[Mike Pinkerton (not reading bugmail)]

checked in fix for 187050, and it appears to fix this one too.

Comment 19

[Nathan Hamblen]

I wouldn't have expected bug 187050 's patch to fix this. The best testcase for
this bug is a page with flash plugins. After the mouse goes over one your cursor
stops updating. But if it does fix it, all the better.

Comment 20

[Mike Pinkerton (not reading bugmail)]

oops, you're right. news.com.com is a good test-site for this.

Comment 21

[Nathan Hamblen]

Attachment: Fix that leaves setAcceptsMouseMovedEvents in the ON position always

This removes the code that was turning off setAcceptsMouseMovedEvents when the
mouse exits a view, replacing it with a quick OFF/ON toggle when the mouse
enters the view.

Comment 22

[Nathan Hamblen]

Attachment: Fix that calls setAcceptsMouseMovedEvents:NO when the mouse leaves a top level gecko view

This replaces the code that was incorrectly turning off
setAcceptsMouseMovedEvents when leaving any gecko view, including plugins like
flash.

Comment 23

[Nathan Hamblen]

I had to update these patches because of the neighboring checkin. Both patches
independantly fix the bug in different ways. From the previous comments here, I
think you guys prefer patch 124854.

Comment 24

[Mike Pinkerton (not reading bugmail)]

what i would prefer is to be able to get it right such that the
acceptsMouseMoved state when the cursor leaves gecko is the same as when it
entered gecko. apps have the ultimate choice (for perf reasons) and we shouldn't
muck with it when the mouse isn't in our area. neither patch looks like it will
do that (it looks like we'll always leave it set, or always turn it off when
leaving gecko)

what i would like to better understand is how and why this regressed. why don't
we have this bug with 0.7 branch builds? 

Comment 25

[Pitts Jarvis]

I have noticed a case where the cursor tracking fails only when the cursor
enters the browser window from the right side (over the scroll bar). In this
case the arrow cursor never changes over certain links on the page.

Here is a specific example:

Go to http://maccentral.macworld.com/ and focus your attention on the daily NEWS
STORY LINKS.

Move the cursor outside the browser window. Move the cursor into the browser
window from the right side (over the scroll bar). Continue to move the cursor
over the links to the news stories; the hand cursor never appears.

Move the cursor outside the browser window. Move the cursor into the browser
window from the bottom. You can now observe the cursor changing between arrow
and hand while moving over the news story links.

You can observe proper behavior when moving the cursor into the browser window
from left, top, or bottom.

You get buggy behavior only when entering the browser window from the right
(over the scroll bar).

Comment 26

[Jasper]

Wow, I can repro this using Camino 2003061104 on Maccentral.

When doing repeating the give steps in comment #25 on the spymac.com page the
behaviour initialy is the same, but after a while the proper behaviour is taking
over. The Maccentral page is the only one that seems to hold the inproper
behaviour. It seems as if the scrollbar is stealing focus when moving over it. 

The reason why so many people seem to have the mouse focus problem is ofcourse
because most people have their mouse on the right side of the window.

Comment 27

[Jasper]

Just found another way to reproduce:

1) go to http://www.spymac.com
2) move your mouse around (links/buttons) do not move over the add (right top)
3) notice that all works well
4) move your mouse over the add (right top)
5) again move your mouse around (links/buttons)
6) notice that the mouse doesn't respond to link/buttons anny more
7) move your mouse outside and inside of the window (even the right side)
9) notice that all works well again

Another strange behaviour.

1) go to the same page as above
2) move your mouse over the "gallery, webmail and chat" on the left side
3) move your mouse out of the window on the left side
4) notice that the (micky mouse) hand cursor is still there out side of the
application, while it should be the default cursor. Right?

Comment 28

[Nathan Hamblen]

I think all of these problems involve flash animations. Either of the sumbitted
patches should fix it.

Comment 29

[Nathan Hamblen]

Comment on attachment 124855 [details] [diff] [review]
Fix that calls setAcceptsMouseMovedEvents:NO when the mouse leaves a top level gecko view

Mike, this patch is my favorite, but if you like the other one better please
check it in instead.

Comment 30

[Mike Pinkerton (not reading bugmail)]

i'll try to look at this tonight, i'd like to get this resolved. thanks!!!

Comment 31

[Mike Pinkerton (not reading bugmail)]

i must be thick. i don't understand why we need to have the check to only
disable mouseMove events if the parent isn't one of our views. the way it is
now, we always turn it off and that seems to cause us problems, but shouldn't it
get turned back on when you, say leave a plugin and re-enter the parent web
view? doesn't the encompasing gecko view get a mouseEnter? if not, why not? is
something else broken?

/me feels stupid. maybe i just need beer.

Comment 32

[Nathan Hamblen]

You're more curious than I am, Mike. Once I realized that the monitoring was
getting turned off by plugin views, I realized that cocoa was sending a
mouseexited to the plugin child view but no mouseentered to the enclosing view,
and left it at that. My best shot at a logical explanation is that the mouse
never really leaves the parent view when it enters the child view, so the
notifications are not being sent in either direction.

Comment 33

[Mike Pinkerton (not reading bugmail)]

"My best shot at a logical explanation is that the mouse
never really leaves the parent view when it enters the child view, so the
notifications are not being sent in either direction."

Nathatn, can you hack up a little test app to verify this assumption? If true,
then we need to go with this patch. If not, then well, we need to figure out why.

Sorry to be such a stickler, i just really want to get this right.

Comment 34

[Nathan Hamblen]

Attachment: Test app for mouse entered/exit messages in child views.

Here you go, Mike.

Now that I'm uploading this, I'm realizing what the real explanation is. The
mouseEntered and mouseExit messages are not claiming that the mouse entered or
exited the *view*. They are only concerned with the tracking rectangle that has
been added to the view in the setFrame method. In that method, the tracking
rectangle is always set to the bounds of the parent view, regardless of any
child view.

Comment 35

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 124855 [details] [diff] [review]
Fix that calls setAcceptsMouseMovedEvents:NO when the mouse leaves a top level gecko view

after much thought, i believe this to be the most reasonable solution.

r=pink

simon, can you sr?

Comment 36

[Mike Pinkerton (not reading bugmail)]

landed. yay!