Created attachment 549742 [details] Test file User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0 Build ID: 20110615151330 Steps to reproduce: We've got element with "cursor: pointer" and "cursor: default" on the :hover state (see attached example). There is a glitch when mouse entered an element - cursor changes his appearance for short period of time. The glitch do not appears when mouse leaves element. It could be a Gecko issue because Webkit browsers handle this correctly.
Attachment #549742 - Attachment mime type: text/plain → text/html
I agree that it's a bug, but why don't you just set cursor: default for the non-:hover state, too?
WFM: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:220.127.116.11) Gecko/20110707 Firefox/3.6.19 Reproduced: Mozilla/5.0 (X11; Linux x86_64; rv:5.0.1) Gecko/20100101 Firefox/5.0.1 Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20100101 Firefox/6.0 Mozilla/5.0 (X11; Linux x86_64; rv:7.0a2) Gecko/20110731 Firefox/7.0a2 Mozilla/5.0 (X11; Linux x86_64; rv:8.0a1) Gecko/20110801 Firefox/8.0a1 Last good nightly: 2009-12-31 First bad nightly: 2010-01-01 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6d56925adfd5&tochange=cb5a303025fe The first bad revision is: changeset: 36797:2e580c431f4e user: Boris Zbarsky <firstname.lastname@example.org> date: Thu Dec 31 14:07:57 2009 -0500 summary: Bug 528306 part 3. Hook up restyle processing to nsRefreshDriver. r=dbaron http://hg.mozilla.org/mozilla-central/rev/2e580c431f4e
Status: UNCONFIRMED → NEW
Component: General → Layout
Ever confirmed: true
OS: Windows 7 → All
Product: Firefox → Core
QA Contact: general → layout
Hardware: x86_64 → All
Version: 5 Branch → Trunk
So presumably what happens is that the cursor is updated immediately on mouseover but the hover state does not update until the next refresh timer firing. In particular, the cursor update is not flushing out style. Olli, do you know whether there's a reason the UpdateCursor call is sync under the NS_MOUSE_MOVE case in the ESM, and in particular comes before the GenrateMouseEnterExit? Could we do the cursor update off the next refresh driver refresh instead? The fact that UpdateCursor can mess with the mousemove event status is sort of confusing to me....
David might remember better the cursor and hover state handling. But I don't think there is any reason for the sync call.
This is not reproducible in windows-10 and Ubuntu 14.04 with latest Nightly. The mouse does not change appearance and no glitches. Considering this, I will mark this issue as Resolved-WORKSFORME. If anyone can still reproduce it, feel free to reopen the issue and provide more information. Thanks -- Version 49.0a1 Build ID 20160519030232 Update Channel nightly User Agent Mozilla/5.0 (X11; Linux i686; rv:49.0) Gecko/20100101 Firefox/49.0
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
Glitch still occurs on Regular version 47.0b6 and Developer Edition 48.0a2 (2015-05-20) - reproducible using attached file. OS: Win 10 UA: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0 UA DEV: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
This is reproducible with the developer version using the attached test case. Glitch happens for less than a second when mouse enters to the element. ---- Version 48.0a2 Build ID 20160606004039 Update Channel aurora User Agent Mozilla/5.0 (Windows NT 10.0; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0
Status: REOPENED → NEW
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: 2 years ago → 9 hours ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.