Closed Bug 2043963 Opened 3 months ago Closed 18 days ago

[macOS] When moving the mouse cursor out of the window, UI elements not hovered appear hovered

Categories

(Core :: Widget: Cocoa, defect)

Firefox 153
defect

Tracking

()

RESOLVED FIXED
157 Branch
Tracking Status
firefox-esr140 --- unaffected
firefox-esr153 --- affected
firefox153 --- wontfix
firefox155 --- wontfix
firefox156 --- wontfix
firefox157 --- fixed

People

(Reporter: sam, Assigned: spohl)

Details

Attachments

(8 files)

I've noticed this behavior on multiple systems running macOS 26, but not on systems running other versions of macOS. When the mouse cursor moves slowly off the top edge of the window, UI elements seem to get "hovered" even though the mouse never hovered over them. The element that receives the hover effect is consistent based on the position of the cursor and the position of the window.

The attached screen recording should illustrate the issue pretty well.

I'm not really sure what to provide here to help troubleshoot this--are there certain logs that would be useful to capture?

Is this a recent regression? Could you run mozregression to verify?

Severity: -- → S3
Flags: needinfo?(sam)

(In reply to Stephen A Pohl [:spohl] from comment #1)

Is this a recent regression? Could you run mozregression to verify?

I got this range from mozregression: https://hg-edge.mozilla.org/mozilla-central/pushloghtml?fromchange=7a0ce20629fc2680cec582514ec1974fac360403&tochange=c3628eec879df162c36d390392046e6e53a70aed

One item of note in the range is bug 1988774. Unfortunately I wasn't able to narrow down further, as none of the autoland builds would run.

Flags: needinfo?(sam)

Thanks for the regression range, that was really helpful.

I have not been able to reproduce the stuck hover on my own macOS 26 machine yet, even moving the cursor slowly off the top edge the way you described. So I have built a custom Nightly with some extra logging in the macOS mouse-tracking code, and I am hoping you can capture a log on a system where it does reproduce. The log should show me what the window is doing with the cursor as it leaves the top edge.

Download this universal build:

https://firefoxci.taskcluster-artifacts.net/APjtp-8iTb6rbQVE3nSr5w/0/public/build/target.tar.gz

To run this build you will need to follow these steps:

  1. Extract it by double-clicking it in Finder. This produces "Firefox Nightly.app".
  2. Clear the quarantine flag from Terminal so macOS will let it run (adjust the path if you extracted it elsewhere):

xattr -dr com.apple.quarantine ~/Downloads/Firefox\ Nightly.app

  1. Launch it by double-clicking it.

To capture a log:

  1. Open the build and load any page in one tab.
  2. In a second tab, paste this address and hit Enter: about:logging?modules=timestamp,nsCocoaWidgets:3&output=file
  3. Click "Start Logging".
  4. Switch back to the first tab and reproduce the issue: hover something so it highlights, then slowly move the cursor straight up and out the top edge of the window until an element looks stuck-hovered.
  5. Come back to the about:logging tab and click "Stop Logging".
  6. Click "Open" next to the log file path to reveal the file (it is called "log.txt" and lives in a temporary folder), and attach it here. If you also see some "log.txt.child-*.moz_log" files next to it, the main "log.txt" is the one I need, but feel free to include the others too.

If it is not too much trouble, it would also help to note roughly which element ended up looking hovered and where the window was on the screen, so I can line that up against the coordinates in the log.

Flags: needinfo?(sam)

Thanks for the test build and for taking a look, Stephen! I've performed the steps you've outlined. I'm attaching the log file as well as a screen recording that I took during the log capture.

Flags: needinfo?(sam)

That log was really helpful, thank you, and the screen recording even more so.

From the first log I can see that the macOS windowing side is doing the right thing: it correctly notices the cursor leaving the top edge and tells the rest of Firefox the mouse has left. So the stuck highlight appears to be happening a bit further along, in the shared code that is supposed to clear the hover state. I could not reproduce it on my own macOS 26 machine, so I would like one more log, this time with an extra logging module turned on so I can see whether that clearing step is being skipped.

You can use the same build I sent before, no new download needed. The only change is one extra module in the address (now includes "MouseBoundaryEvents"):

  1. Open that build and load any page in one tab.
  2. In a second tab, paste this address and hit Enter:
    about:logging?modules=timestamp,sync,nsCocoaWidgets:3,MouseBoundaryEvents:4&output=file
  3. Click "Start Logging".
  4. Switch back to the first tab and reproduce the issue: open a couple of tabs, hover one so it highlights, then slowly move the cursor up and out the top edge until a tab stays looking hovered.
  5. Come back to the about:logging tab and click "Stop Logging".
  6. Click "Open" next to the log file path and attach the "log.txt" file here (plus any "log.txt.child-*.moz_log" files if you see them).

As before, noting which tab ended up stuck and where the window was on screen would help me line it up against the log. Thanks again.

Flags: needinfo?(sam)

No problem, here is the new log and screen recording.

Flags: needinfo?(sam)

Thanks for the logs, they made this possible to track down.

I have a build with a potential fix. If you have a chance, could you confirm the stuck hover is gone when you move the cursor out the top edge the way you did before? No logging needed this time.

Download this build (Apple Silicon):

https://firefoxci.taskcluster-artifacts.net/ONCRrtfGQNmp-bqK6wukYQ/0/public/build/target.tar.gz

To run it:

  1. Extract it by double-clicking it in Finder. This produces "Firefox Nightly.app".
  2. Clear the quarantine flag from Terminal so macOS will let it run (adjust the path if you extracted it elsewhere):

xattr -dr com.apple.quarantine ~/Downloads/Firefox\ Nightly.app

  1. Launch it by double-clicking it.

Thanks again for your help.

Flags: needinfo?(sam)

Unfortunately, I am still able to reproduce the issue with this build.

Flags: needinfo?(sam)

Thanks for testing, and sorry that one did not do it.

I built one more version with more detailed logging that should let me see exactly what is going wrong. Could you capture one more log with it?

https://firefoxci.taskcluster-artifacts.net/SdusEdshRR-zUXdG7ITpcw/0/public/build/target.tar.gz

To capture the log:

  1. Open the build and load any page in one tab.
  2. In a second tab, paste this address and hit Enter:
    about:logging?modules=timestamp,sync,nsCocoaWidgets:3,MouseBoundaryEvents:4,MouseLocation:3&output=file
  3. Click "Start Logging".
  4. Switch back to the first tab and reproduce the issue: open a couple of tabs, hover one so it highlights, then slowly move the cursor up and out the top edge until an element looks stuck-hovered.
  5. Come back to the about:logging tab and click "Stop Logging".
  6. Click "Open" next to the log file path and attach the "log.txt" file here (plus any "log.txt.child-*.moz_log" files if you see them).

It would really help if you could note which element ended up stuck and, roughly, where on the screen the window was and where the cursor left the window, so I can line that up against the coordinates in the log. Thanks again.

Flags: needinfo?(sam)

Thanks Stephen, here is a fresh log and screen recording.

Flags: needinfo?(sam)

I have another build with a potential fix. Could you check whether the stuck hover is gone when you move the cursor out the top edge the way you did before? No logging needed this time.

https://firefoxci.taskcluster-artifacts.net/d1qRdqkeRUqY9AXtlvrB8Q/0/public/build/target.tar.gz

Flags: needinfo?(sam)

(In reply to Stephen A Pohl [:spohl] from comment #14)

I have another build with a potential fix. Could you check whether the stuck hover is gone when you move the cursor out the top edge the way you did before? No logging needed this time.

https://firefoxci.taskcluster-artifacts.net/d1qRdqkeRUqY9AXtlvrB8Q/0/public/build/target.tar.gz

Thanks! Great news, with this build I am unable to reproduce the issue :)

Flags: needinfo?(sam)

On macOS 26 the locationInWindow reported on mouseEntered and mouseExited NSEvents appears, in the cases we have been able to capture, not to match where the cursor actually is. The reported point was offset from the live cursor position (most often down and to the right) by a variable amount, and did not seem to line up with any position the cursor had recently occupied. We have not been able to fully determine the cause. It does not look like event-processing latency, since the affected events were handled almost immediately and the cursor appeared to be stationary at the time, so our best guess is that the coordinate is computed incorrectly for these events on this OS version, but we have not been able to corroborate that from outside AppKit.

ScreenLocationForEvent already treats mouse-move event locations as untrustworthy and uses the live [NSEvent mouseLocation] instead (bug 443178). This change does the same for mouseEntered and mouseExited, which avoids relying on the suspect coordinate regardless of where it actually comes from.

Without this, the suspect enter coordinate appears to be recorded as the last known mouse location, and a subsequently synthesized mouse move then seems to re-apply :hover to an element offset from where the pointer actually left the window. The most visible result is a UI element such as a background tab that looks hovered after the cursor has moved out the top edge of the window, which is what this bug reports.

Assignee: nobody → spohl.mozilla.bugs
Status: NEW → ASSIGNED
Pushed by spohl@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/571e8671acb4 https://hg.mozilla.org/integration/autoland/rev/064e277b1517 Use the live cursor location for macOS mouseEntered/mouseExited events. r=mac-reviewers,haik
Status: ASSIGNED → RESOLVED
Closed: 18 days ago
Resolution: --- → FIXED
Target Milestone: --- → 157 Branch
QA Whiteboard: [qa-triage-done-c158/b157]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: