Open Bug 1856615 Opened 2 years ago Updated 3 months ago

hover / mouseover flicker on macOS Sonoma when using external display only

Categories

(Core :: Widget: Cocoa, defect, P3)

Product:
Core
Component:
Widget: Cocoa
Version:
Firefox 118
Type:
defect

Tracking

()

People

(Reporter: parente, Unassigned)

Details

Attachments

(1 obsolete file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/118.0

Steps to reproduce:

  1. Open firefox window on external display attached via USB-C to MacBook Pro.
  2. Visit amazon.com in Firefox.
  3. Hover various popup menus in the navigation bar at the top of the page.

(I have a 8 MB screencap showing the issue but Bugzilla returns 500 errors when I try to attach it.)

Actual results:

Menu bar item rectangle highlight appears but flickers. Popup menus flicker open and closed.

Expected results:

Popup menus should appear without flickering.

(When performing the same test on the same device but with the Firefox window located on the built-in Macbook display, this issue does NOT occur.)

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Cocoa' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Widget: Cocoa
Product: Firefox → Core

See also bug 1854862.

The severity field is not set for this bug.
:spohl, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(spohl.mozilla.bugs)
Severity: -- → S3
Flags: needinfo?(spohl.mozilla.bugs)
Priority: -- → P3

Confirming this bug is still present in Firefox 140.0.2.

The flickering reliably reproduces on my setup, which consists of two external monitors connected to a MacBook Pro (in clamshell mode). I typically use around ten macOS spaces, with six to twelve Firefox windows and a cumulative tab count between twenty and one hundred.

I've observed that the issue manifests more quickly with a higher number of open windows and tabs. A quick hide-and-restore of the application (cmd+h followed by cmd+tab) temporarily resolves the flickering.

Bug 1957302 appears to be related. Discussions on Reddit about Firefox hover flickering on macOS dating back several years indicate this is a persistent problem.

I have captured the following with all extensions disabled:

As a new Firefox user, this is a highly irritating bug, though my only one so far. Given the time it takes for the bug to appear after a restart, performing a bisection would be difficult. I'm happy to provide further assistance in any other way I can.

Flags: needinfo?(spohl.mozilla.bugs)

Albeit time consuming, bisection would indeed be the most effective way of making progress here. I have yet to reproduce this issue myself. At a minimum it would be good to know if a "very old" build (the oldest build that mozregression will run) is also reproducing this bug or not.

Flags: needinfo?(spohl.mozilla.bugs)

Thank you for your response! Okay, I will give it a try.

So far I learned that the issue were present in 129.0 20240628161338, exactly as described, and that the earliest version that actually runs on my MBP is 70.0 20190826190904 (and also that the 70.0 is barely useable for modern web. i.e. you can't actually log into google with it)
I guess it will take quite a lot of time.

It took a while (mostly because I spent 3 days testing a version before considering it 'good'), but the bisect is over and ended with

13052:45.62 INFO: Running mozilla-central build for 2023-06-09
13053:34.40 INFO: application_buildid: 20230609214634
13053:34.40 INFO: application_changeset: 501ade4b55d97797e4cf4416ddf1aa5aca207b9e
13053:34.40 INFO: application_name: Firefox
13053:34.40 INFO: application_repository: https://hg.mozilla.org/mozilla-central
13053:34.40 INFO: application_version: 116.0a1
Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', 'back' or 'exit' and press Enter): bad
13057:33.04 INFO: Narrowed nightly regression window from [2023-06-08, 2023-06-10] (2 days) to [2023-06-08, 2023-06-09] (1 days) (~0 steps left)
13057:33.05 INFO: Got as far as we can go bisecting nightlies...
13057:33.05 INFO: Last good revision: 256876c3862b6c4c8c51676f10d5ca440f86c0a8 (2023-06-08)
13057:33.05 INFO: First bad revision: 501ade4b55d97797e4cf4416ddf1aa5aca207b9e (2023-06-09)
13057:33.05 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=256876c3862b6c4c8c51676f10d5ca440f86c0a8&tochange=501ade4b55d97797e4cf4416ddf1aa5aca207b9e

13057:33.05 INFO: Switching bisection method to taskcluster
13057:33.05 INFO: Getting mozilla-central builds between 256876c3862b6c4c8c51676f10d5ca440f86c0a8 and 501ade4b55d97797e4cf4416ddf1aa5aca207b9e
...
13057:49.49 INFO: There are no build artifacts for these changesets (they are probably too old).

The obvious suspect from the changelist is 27e0676b9 fixing "Bug 1837007. Multiple nsCocoaWindows can interfere with each others' native fullscreen requests.", but I don't use full screen mode at all.

By the end, I had a fairly simple way to reproduce it (well, not exactly simple, but still minutes instead of hours):

  • start app (with mozbissect), resize it with Raycast "Left Half" command
  • sign in to the first gmail account
  • open tab, sign in to the second gmail account
  • open window, "Right Half", sign in to github
  • open window, open google calendar, mission control (four-fingers swipe up), move window to a second screen
  • open window, mission control, move window to another space on the same screen, "Left Half", open a google sheet.
    By the end of this sequence, at least one of these windows exhibits the problem.

Albeit time consuming, bisection would indeed be the most effective way of making progress here.

Is there anything else I can do to help move this forward?

Flags: needinfo?(spohl.mozilla.bugs)

Thank you for the sleuthing! I have been trying to revert this one patch to see if that was indeed the culprit. Once completed, I will point you to a build to test with. There is nothing else needed at this time.

Flags: needinfo?(spohl.mozilla.bugs)
Attachment #9500409 - Attachment description: WIP: Bug 1856615: Disable nsCocoaWindow local run tloops. → WIP: Bug 1856615: Disable nsCocoaWindow local run loops.

Thank you for your patience, Alexey! Here is a link to a build that reverts the changes from bug 1837007:

https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/PFphEEJaQiGK2hULGB8JQA/runs/0/artifacts/public/build/target.dmg

In order to run this build, you will have to double-click it a first time. macOS will refuse to open it at first. You can then override this with the following steps:

  1. On your Mac, choose Apple menu > System Settings, then click Privacy & Security in the sidebar. (You may need to scroll down.)
  2. Go to Security, then click Open.
  3. Click Open Anyway. (This button is available for about an hour after you try to open the app.)
  4. Enter your login password, then click OK.

Please let us know if you are able to reproduce the bug in this build or not. Thank you!

Flags: needinfo?(parente)

Got it reproduced almost immediately, see the screencast. Again, can be temporarily fixed with the hide and restore.

Flags: needinfo?(parente)

First of all, I want to sincerely apologize for sending you down the wrong path.
After double-checking the two builds mentioned earlier, I realized that both of them actually exhibit the issue. That made me suspect I might not have conducted the bisect properly, so I decided to redo it from scratch.

In my defense, I only discovered a reliable way to reproduce the problem a few steps into the process, which might have affected the accuracy of the earlier results.

As it turns out, I was able to reproduce the issue even with the very first build, 70.0a1 20190826190904, that managed to launch on my mbp, see the screencast.

I’m not sure what to do next.

No need to apologize and thank you for double-checking! This just means that we will have to take a deeper look at what might be going on here.

Flags: needinfo?(parente)
Assignee: nobody → spohl.mozilla.bugs
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #9500409 - Attachment is obsolete: true
Assignee: spohl.mozilla.bugs → nobody
Status: ASSIGNED → NEW

Hi, I’d like to add an update. I have switched from an Intel MacBook Pro to an Apple Silicon MacBook Pro and re-tested this issue on a fresh macOS installation. The setup is the same: MacBook in clamshell mode, two external non-Apple monitors.

The problem still reproduces. On the M4, however, the focus flicker occurs so rapidly that it looks more like shimmering.

Is there anything I can do to help bring this to the attention of someone familiar with the underlying internals?

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: