1631217 - Extensions in the overflow menu become invisible in a multi-monitor configuration

Status: NEW

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

Description

[u661402]

Attachment: Screen Recording.mp4

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

Steps to reproduce:

I only have a MacBook Pro running MacOS 10.15.4. The bug is reproducible with my setup, but I don't know whether this bug exists/is reproducible on other platforms.

1. Connect an additional display to the computer, and arrange the other display as extended desktop instead of mirroring.
2. Open Firefox in the primary display. This bug does not exist if Firefox is dragged onto the secondary display/extended desktop.
3. Open overflow menu, click on any extensions.

Actual results:

Extensions' UI is invisible.

Expected results:

Extensions' UI should be visible.

Comment 1

[Luca Greco [:rpl] [:luca] [:lgreco]]

needinfo-ing my self to add a comment with some additional STR steps to verify if this is only an issue with extensions panels.

Comment 2

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (non,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Comment 3

[Luca Greco [:rpl] [:luca] [:lgreco]]

Hi Miruna,
would you mind to verify if you can reproduce this?
(it has been reported for OSX, we are unable to reproduce and we don't know if it is reproducible in other platforms, would be good to verify that as well).

Comment 4

[Alex Cornestean]

Hello Luca,

I’ve attempted to reproduce the issue on the latest Nightly (78.0a1/20200521093657), Beta (77.0b9/20200521224544), Release (76.0.1/20200507114007) and Release 75.0 (75.0/20200403170909) under Windows 10 Pro 64-bit and Ubuntu 16.04 LTS, however without success. I do not have a macOS workstation with a dual monitor setup available to test there as well.

Beside the reported STR, I’ve also tried launching the browser on the secondary monitor, with and without a dark theme and/or dark mode enabled. Still could not reproduce the issue.

I’ve tested the issue using Dark Reader and uBlock Origin and the panels are always visible when accessing the add-on from the overflow menu.

Comment 5

[Luca Greco [:rpl] [:luca] [:lgreco]]

I've been finally able to give this a try and I verified that can be reproduced consistently on MacOS "Catalina" 10.15.5 (tested on uBlock Origin and the Multi Account Containers browserAction popups opened from the overflow menu).
Given that Alex wasn't able to reproduce it on windows and ubuntu, this looks like a MacOS specific issue.

I did also run mozregression a couple of times, the result is basically that the issue starts to be reproducible when we did set by default "extensions.webextensions.remote" to true on macOS (which happened between 2018-03-07, last good build, and 2018-03-08, the first build where the issue starts to happen with the default settings).

As an additional confirmation that the issue can only be triggered when the extensions run in the extensions process ("extensions.webextensions.remote" set to true), I did another mozregression on more recent Firefox versions (> 60) by also setting explicitly "extensions.webextensions.remote" to false, and the issue isn't reproducible when the extensions are running in the main process.

This needs more investigation, to get more details about the actual underlying issue.

Comment 6

[Rob Wu [:robwu]]

(Marking as confirmed based on comment 5)

Comment 7

[Luca Greco [:rpl] [:luca] [:lgreco]]

Hi Haik,
I was wondering if behind this issue (which seems to be only happening on OSX Catalina) there may be some issue similar to Bug 1592416.
could you take a look to it? (the STR is in comment 0, I tested it by installing uBlock origin and then pinning it into the overflow menu)

Comment 8

[Haik Aftandilian [:haik]]

(In reply to Luca Greco [:rpl] [:luca] [:lgreco] from comment #7)

Hi Haik,
I was wondering if behind this issue (which seems to be only happening on OSX Catalina) there may be some issue similar to Bug 1592416.
could you take a look to it? (the STR is in comment 0, I tested it by installing uBlock origin and then pinning it into the overflow menu)

Hi, Luca. Yes, that sounds plausible. We recently fixed 1592416, but we know there are some outstanding issues with multi-monitor and/or multi-workspace setups. We have bug 1644109 filed and I'll look into this soon. I'll take this bug for now.

Quick question: are you able to reproduce this problem with the fix for 1592416? For example, in Nightly 79? I just tried testing this on 79 and also Release 77, but no success so far.

Comment 9

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: Screen Recording 2020-06-11 at 20.18.52.mov

(In reply to Haik Aftandilian [:haik] from comment #8)

...
Quick question: are you able to reproduce this problem with the fix for 1592416? For example, in Nightly 79? I just tried testing this on 79 and also Release 77, but no success so far.

Yes, I just tried again and I'm still able to reproduce it on Nightly 79, but only when the browserAction is pinned in the overflow menu and I have a second monitor attached to the macbook and configured to extend the desktop instead of mirroring it.

The attached mov file shows the popup opening as expected when non pinned in the overflow menu, and then once pinned into the overflow menu it isn't shown anymore (but the overflow menu ">>" button seems to be in the state it would be while the popup in open).

Another detail that I did notice while I was looking for a regression range is that this does only happen when the extensions runs in the extension child process (when the browser element where the popup content is loaded is remote=true).

Thanks a lot for taking a look into this! Let me know if there is anything else I can do to help you investigate this issue.

Comment 10

[n8chz]

No dual monitor setup here, just using Firefox 78.0.2 on Ubuntu 20.04, have a healthy number of add-ons installed, many of which have BrowserActions. Those whose BrowserActions are supposed to open a panel do not do so. These include Archive URL, NoScript, Page Saver WE, Persistent Highlighter (which I wrote) and Search All Tabs.

For a few weeks before panels disappeared, the panel for NoScript was appearing for a very short period of time (maybe a tenth of a second) and promptly disappearing, and before that it was hit-or-miss, as if there were a hitbox that was a very small fraction of the toolbar button, and was being moved to different parts of it between uses, so it took on average about 10 tries (button clicks) to get the panel visible and stable. At that time I assumed it was something wrong with No Script and hadn't thought to try the other panel-using add-ons. I don't often use the ones other than NoScript.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

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