Closed Bug 381003 Opened 17 years ago Closed 8 years ago

Mouse pointer (cursor) style fails to update when coming straight off a link or text edit area

Categories

(Core :: Widget: Cocoa, defect)

Product:
Core
Component:
Widget: Cocoa
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: mike, Unassigned)

References

(
URL
)

Details

(Keywords: regression) 

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.9a5pre) Gecko/20070516 Camino/2.0a1pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.9a5pre) Gecko/20070516 Camino/2.0a1pre

If a mouse cursor is hovering over a link, or any object in a webpage that changes it's style (such as a finger for links, text edit cursor for text boxes, etc), and move directly to the toolbar or tab bar, it will remain the same and not revert to the default pointer style, even outside the entire browser application.

Reproducible: Always

Steps to Reproduce:
1. Have a link directly on the top of the viewable web page content, with no area in between the link, and the toolbar or tab bar. The best way to reproduce is by scrolling a webpage until a link is cut off by the top of the web page content area.
2. Bring the mouse directly up to the toolbar or tab bar without going over anything in the page that will revert the pointer to a default style.
3. The pointer will remain unchanged until it goes back onto the web page area, or goes across the address bar.
Actual Results:  
The cursor failed to revert to a default pointer, even outside the application, until it crossed back into the web page or address bar.

Expected Results:  
Revert to default pointer style when outside of the web page viewing area.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This seems to be trunk-only, so finding out when it regressed would be helpful.
Keywords: qawanted, regression
Version: unspecified → Trunk
There's nothing at all in that range that seems reasonable to cause this, as far as I can tell :(
Severity: trivial → minor
Keywords: qawanted
I started using the Camino nightly maybe a little over a week ago, and this behavior never occurred before the May 10th nightly for sure.  I'm pretty sure it regressed sometime this week.
This proves harder to find some regression range, as the behavior is not consistent. At least on my side, it does not _always_ happen.
In previous tests (comment #2), I could reproduce the problem more often; in second series of test, the problem only occurred 2 out of 5 tries on average.
I tried both a page with a link at the top left corner of the page and a large image (larger than the window size, triggers the magnifying glass cursor) [1]. In both tests, I moved the cursor to the top-left corner of the window (back-button).
And I can't seem to reproduce the problems on builds prior to 2007041302 (but I didn't go earlier than 0402...).
While testing, I noticed that the problems happen more frequently (_not_ always) if the tab bar is hidden. And I noticed that if one moves the mouse slowly, the problems nearly doesn't happen.

[1] this is something I had noticed recently - once or twice, when sending the cursor away, fast.
I see it in 2007-04-10-22 but not 2007-04-03-21 (a tinderbuild), the next-previous build I have on hand (I also don't see it in 3-27 and 3-23 builds I have).

Based on what the bug is and my very bad range, my guess is that it's josh's changes for bug 355102.  I'll try to grab some other builds soon and confirm.

My STR were to open http://www.caminobrowser.org/homepage/, scroll the page until "various security and stability updates" was at/partially beyond the top of the content area, and mouse up from the page over it.
Keywords: qawanted
Another STR:
A large block of text close to the top of the window.
Mouse over text at top, then move cursor to the tab. 
The cursor remains the text-selection tool (I-beam).

This gave me a regression between 2007-04-10-02 and 2007-04-10-18 (tinderbox build).
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-04-10+02%3A00%3A00&maxdate=2007-04-10+18%3A00%3A00&cvsroot=%2Fcvsroot

That includes bug 355102, but also bug 370439 (new scrollbars) and  bug 372020 (camino only). 

I'm confident enough in philippe's checking here to say this is the fault of bug 355102.
Blocks: 355102
Keywords: qawanted
Target Milestone: --- → Camino2.0
Does this happen with trunk Firefox?
(In reply to comment #9)
> Does this happen with trunk Firefox?
> 
Not on my side (tested with the 0519 build and with your widgets build).

Good. Perhaps something in our embedding code is depending on our algorithm for tracking mouse enter/exit/move events, which changed in that patch. It shouldn't depend on our algorithm.
(In reply to comment #11)
> Good. Perhaps something in our embedding code is depending on our algorithm

"Our" being Camino, or Gecko?  We both have embedding code/layers; if it's in Gecko's embedding code, we'll need to get this on that radar, whereas if it's in Camino's, we can probably let this simmer for a bit.

Josh, shouldn't this live in Cocoa Widgets? Presumably the widget layer is responsible for undoing cursor changes it has made, rather than embeddors.
Josh: any update on where this should live?
My patch for bug 325558 might have fixed this. Can someone check?
Assignee: nobody → joshmoz
Component: General → Widget: Cocoa
Product: Camino → Core
QA Contact: general → cocoa
Target Milestone: Camino2.0 → ---
(In reply to comment #15)
> My patch for bug 325558 might have fixed this. Can someone check?

Indeed, there are no problems anymore with the STR in comment 7 on my side (Camino 20080412-00 and newer builds).


I can still repro comment 7 on this very page with Camino 2008042901.
I checked on this and I can still repro both comment 0 and comment 7.  

In the comment 0 case, using this bug as test and the little "mozilla" link at top right, I can only repro when the area above the link does not have a tab in it (empty tab bar, or bookmark bar); if I enter a tab, the cursor gets reset.

In the comment 7 case, the cursor remains an I-beam even over a tab.

In both cases, hitting the main toolbar often but not always resets the cursor, but I've been able to go all the way to the top of the screen several times without getting a reset.

Josh then had me look at bug 325558 (http://www.petracovich.com/petracovich_main.html) again.  It's certainly a lot harder to repro than before, but I can still repro enough to see it.  It's easiest for me to trigger exiting left somewhere between the middle and bottom bird, and often having just "changed" birds.  Dunno if there's a race condition or a dead area, or what, but it's still there in Camino.  I was unable to reproduce that even once in a similar amount of time trying in today's Minefield.  (What's more, that plug-in view doesn't even extend to the left edge of the page.)

Josh said he thinks the bug really is in Camino's embedding layer.
Aha. Moving from the content area to an _empty_ part of the tab bar fails indeed. I only had tried with a tab bar full of tabs.

I also see the reverse effect. Moving the pointer from the toolbars downwards doesn't change the cursor. Using Smokeys example in comment 18, place mouse pointer on any toolbar, and move down over the Mozilla link at the top right of this page. The cursor remains an arrow. This only seems to happen when moving over the active tab (I have this bug page open in the right most tab)
Actually, I can find the left-edge "dead zone" in petracovich easily in Minefield by slowly moving the cursor to the left; the bird cursor will disappear and the arrow cursor won't come back as long as I stay in the dead spot.  Chris say's it's 5-10px wide and the full height (or width, along the top/bottom) of the Flash.  If you move beyond the dead zone in Minefield, however, the cursor does come back.

As we move fully into the realm of the bizarre:

1. Open the About Camino window so that's it's half in and half out of the plug-in.
2. Move from right to left across the About Camino window
3. Observe the cursor disappear as soon as you cross into the half of the About Camino window that is over top of the plug-in.
4. Wonder why the plug-in is getting that event at all in a background window

Probably a separate bug, but until someone does more digging here....
Summary: Mouse pointer style fails to update when coming straight off a link or text edit area → Mouse pointer (cursor) style fails to update when coming straight off a link or text edit area
Assignee: joshmoz → nobody
Cannot reproduce in latest Release
Version 	46.0.1
Build ID 	20160502172042
User Agent 	Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:46.0) Gecko/20100101 Firefox/46.0
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.