We should update the cursor at least when a page is finished loading, and perhaps more frequently, so that if the cusor happens to be over a link when the page is done loading, it's correctly updated to the hand cursor. This is most noticeably broken on image gallery type pages, like the example in the URL. I'm sure there is an ancient bug on this, but I can't find it. Bug 83858 is related. With this and bug 78510 fixed, we might actually get to Netscape 4.x parity :)

I thought I fixed this months ago (update every reflow). Are you using a 1.7-branch build or something?

I see the bug in trunk builds, Camino and Deer Park, on the SFGate example (mouse is over the Next link in the top right of the window that pops up). Jiggle the mouse and the cursor updates to the hand cursor.

The fix was in bug 20022. But there might be some bugs in Mac GFX that prevent it from working quite right on the Mac, for example, bug 209565 comment 3.

Are you thinking of bug 195045? Bug 293510 might also be related.

Mac only then I guess. Maybe we're not handling those synthetic mouse moves or something.

Actually, though, the other place for potential platform differences is that some platforms may fire an NS_MOUSE_MOVE in addition to an NS_MOUSE_ENTER when the mouse enters the window and some may not. It's probably a good idea to make the GFX backends consistent in this regard. I think there are many places in content/events that assume this will be done, although I've also added code in the view manager that wouldn't be needed if it weren't done (although I don't actually ever remember testing that it's needed). It's probably worth looking at the order of events in this case across the different platforms.

Hrm. Some debugging shows that docShell is doing some cursor setting (to the spinning and standard states). If I use the keyboard to focus and activate the link, then nsViewManager::ProcessSynthMouseMoveEvent() is never called. If I click the link with the mouse, nsViewManager::ProcessSynthMouseMoveEvent() is called early in the page load, but docShell resets the cursor to the arrow when the page load is done later, so I'm not sure what it is that could make this Mac-only. Note that I'm not moving the mouse at all during the entire process, so I'm not sure if any NS_MOUSE_ENTER/NS_MOUSE_EXIT should be generated.

Yeah, that particular problem wouldn't explain it. PresShell::DidDoReflow should call SynthesizeMouseMove.

For this one, a more likely difference would be whether the platform widget code sends NS_MOUSE_ENTER when a widget is created with, sized to, or moved to a position under the mouse pointer. (Also NS_MOUSE_EXIT is nice in the reverse cases, probably except for destroy.)

So... on that testcase I see this bug with both Linux GTK1 seamonkey and Linux GTK2 Firefox. So this may in fact be an XP bug.

(In reply to comment #9) > For this one, a more likely difference would be whether the platform widget code > sends NS_MOUSE_ENTER when a widget is created with, sized to, or moved to a > position under the mouse pointer. This seems like a heavy burden to place on the widget impl (is this a Windows thing?). Wouldn't it be better to rely on this, and just make sure we send a synthtic mouse move at the right time?

(In reply to comment #11) > Wouldn't it be better to rely on this er, to _not_ rely...

Seems like the first step is to stop trusting my memory of what bugs I fixed six months ago. :-)

This fixes the testcase for me on Linux/GTK2. We're setting the mouse location correctly in the view manager, just not telling anyone else about it.

Note that it looks like Mac doesn't send NS_MOUSE_ENTER the way Windows and GTK2 do. If we want to stop relying on that we'd need to (1) link the view manager tree between content and chrome and (2) propagate the mouse location up and down the view manager tree.

I want to do (1) early in 1.9 so that we can move to one widget for all Gecko content in a given top-level window

(In reply to comment #15) > Note that it looks like Mac doesn't send NS_MOUSE_ENTER the way Windows and GTK2 > do. So we should send NS_MOUSE_ENTER any time a widget is created and the mouse is over it, or it is resized and the mouse is in the new bounds?

It's worth debugging what Windows and GTK2 do a little more before ploughing ahead.

Still seeing this (Camino 1.5). Example: <http://www.engadget.com/gallery/microsofts-tgs-2007-booth-tour/410079/> Click on the "Next photo" link above the image, don't move mouse, wait for new page to load. Cursor is a pointer even though it's over a link.

This is still an issue on the trunk on a fresh checkout on WinXP.