If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Update cursor on page load/reflow

NEW
Unassigned

Status

()

Core
Layout: View Rendering
12 years ago
8 years ago

People

(Reporter: Simon Fraser, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
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?
(Reporter)

Comment 2

12 years ago
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.
(Reporter)

Comment 4

12 years ago
Are you thinking of bug 195045? Bug 293510 might also be related.
(Reporter)

Comment 5

12 years ago
Mac only then I guess. Maybe we're not handling those synthetic mouse moves or
something.
OS: All → MacOS X
Hardware: All → Macintosh
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.
(Reporter)

Comment 7

12 years ago
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.
(Reporter)

Comment 11

12 years ago
(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?
(Reporter)

Updated

12 years ago
OS: MacOS X → All
Hardware: Macintosh → All
(Reporter)

Comment 12

12 years ago
(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. :-)
Created attachment 189949 [details] [diff] [review]
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.
Attachment #189949 - Flags: superreview?(roc)
Attachment #189949 - Flags: review?(roc)
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
Attachment #189949 - Flags: superreview?(roc)
Attachment #189949 - Flags: superreview+
Attachment #189949 - Flags: review?(roc)
Attachment #189949 - Flags: review+
Attachment #189949 - Flags: approval1.8b4?
(Reporter)

Comment 17

12 years ago
(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.

Updated

12 years ago
Attachment #189949 - Flags: approval1.8b4? → approval1.8b4+
Attachment #189949 - Attachment description: patch → patch (checked in to trunk, 2005-07-21 09:22 -0700)
(Reporter)

Comment 19

10 years ago
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.
QA Contact: ian → layout.view-rendering
Assignee: roc → nobody
You need to log in before you can comment on or make changes to this bug.