301408 - Update cursor on page load/reflow

Status: NEW

(Core :: Web Painting, defect)

Description

[Simon Fraser [no longer active]]

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 :)

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 2

[Simon Fraser [no longer active]]

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.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 4

[Simon Fraser [no longer active]]

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

Comment 5

[Simon Fraser [no longer active]]

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

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 7

[Simon Fraser [no longer active]]

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.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Yeah, that particular problem wouldn't explain it.

PresShell::DidDoReflow should call SynthesizeMouseMove.

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.)

Comment 10

[Boris Zbarsky [:bzbarsky]]

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.

Comment 11

[Simon Fraser [no longer active]]

(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?

Comment 12

[Simon Fraser [no longer active]]

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

er, to _not_ rely...

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch (checked in to trunk, 2005-07-21 09:22 -0700)

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.

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 17

[Simon Fraser [no longer active]]

(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?

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 19

[Simon Fraser [no longer active]]

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.

Comment 20

[Ryan VanderMeulen [:RyanVM]]

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