Closed
Bug 161794
Opened 23 years ago
Closed 22 years ago
Mouse pointer does not change to hand over links unless you click the page
Categories
(Camino Graveyard :: General, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: steve, Assigned: bryner)
Details
Attachments
(1 file)
Mouse pointer does not change to hand over links unless you click the page first
then seems to be ok. It does this on most pages you load.
WorksForMe using Chimera/2002080605. With focus anywhere, such as on the URL bar
or in the content pane, the mouse cursor changes to a hand when over a link.
Stephen, what build ID are you reporting this bug against?
Severity: normal → trivial
Summary: Mouse Pointer → Mouse pointer does not change to hand over links unless you click the page
All the builds I have used do exactly the same I have to click the page first
before I can get the hand over for links. The build I am using at the moment is
2002080905. I am using mac OSX 10.1.5
Comment 3•23 years ago
|
||
This bug only appears when loading a web site from the Go or Bookmarks menu into
an already open window. It is also most noticeable on small/fast loading web
sites (http://www.google.com/, for instance).
If your Search Page points to google, select Go / Search Page. When the page
loads, notice that despite moving the mouse over text or links, the cursor
remains an arrow. This remains the case until the mouse is clicked anywhere in
the window, or a period of about 20 seconds passes. Once either has occurred,
the mouse will respond to links and text as expected.
Conversely, when loading a page by following a link or clicking on a Toolbar
Bookmark, the cursor will immediately respond to the various page elements.
Updated•23 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 4•23 years ago
|
||
Chimera 0.4 milestone release, Mac OS X 10.1.5
I can confirm that most of what Ben Lukens reported is correct, except I have
never seen Chimera spontaneously recover from this situation (ie, w/o tapping on
the window content area.)
The following situations will cause the cursor not to respond when mousing over
a link, nor will css hover effects work, *even if* these were working prior:
1. when selecting links either from Bookmarks, Toolbar Bookmarks, or Go menu.
2. after effecting a menu dropdown on any of the menubar items or clicking
anywhere in the menubar region.
Comment 5•23 years ago
|
||
Re: when selecting links either from Bookmarks, Toolbar Bookmarks, or Go menu.
To avoid confusion, I was actually referring to links selected from within
Toolbar bookmark folders. Toolbar bookmarks which are direct urls will not
affect cursor function.
btw, my comments on links also applies to text: the pointer does not change to
an I-beam over text.
As all have said this bug only appears from saved url`s from the bookmarks if
you type from address bar all seems to be ok!
Educated guess: when making a selection / double click in the sidebar,
the tableview becomes first responder. When the bookmark then is
loaded in the main window, the user expects the browser view to become
first responder, but that doesn't happen.
Comment 10•23 years ago
|
||
I see this in mozilla too. Go to any site that loads quickly. Put the mouse over
a link, and note the hand cursor. Reload the page with Command-R, and note that,
even though your mouse is still over a link, the cursor is an arrow, not the
hand cursor. We're relying on mouse move events to set the cursor, but we need
to set it for various other events (reflow) too.
Comment 11•22 years ago
|
||
Cocoa stops sending mouse moved messages to a window if you click anywhere
outside the window, like the menu bar or the Camino icon in the doc, even
though that window is still key and firstResponder. I can't find any
documentation for that, but it is definitely happening and it is the cause of
this bug. My solution was to turn off mouse move watching when the mouse leaves
the gecko view and to turn it back on when it reenters. This fixes the problem
(even if you're in a menu when you reenter the view), and cuts down on the
costly mouse move watching when it's not necessary.
Comment 12•22 years ago
|
||
Nathan, if your patch is ready for review be sure to set the appropriate flags
on it.
Comment 13•22 years ago
|
||
Comment on attachment 120536 [details] [diff] [review]
Enables mouse move watching when the mouse enters the gecko view
Heh... just making sure it wasn't my patch's fault that my build has all kinds
of keyboard scrolling problems. Looks like it's really bug #201944 at work.
Attachment #120536 -
Flags: review?(bryner)
Assignee | ||
Comment 14•22 years ago
|
||
Comment on attachment 120536 [details] [diff] [review]
Enables mouse move watching when the mouse enters the gecko view
Looks good. r=bryner.
Attachment #120536 -
Flags: review?(bryner) → review+
Comment 15•22 years ago
|
||
Nathan, is your patch applicable to Mozilla? (See comment 10.)
Comment 16•22 years ago
|
||
I think the bug that Simon describes in comment 10 is a little different than this one, and isn't addressed by the patch. The exact behavior described by this bug does not occur in Mozilla, as far as I know. What Simon was talking about happens in just about every web browser. If the mouse is not moving but you do something with the keyboard to alter the contents of the page (like reloading), the mouse pointer may not be correct for the element that is now under it. As soon as the mouse moves a pixel, its cursor updates to whatever is correct. One could file a bug agaist mozilla for this behavior (maybe there is one), but I think it's so minor that people just accept it as normal.
Assignee | ||
Comment 17•22 years ago
|
||
Checked in, thanks for the patch.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•