1742877 - Sharing bar cannot be minimized when Firefox is built with the macOS 11 SDK

Status: RESOLVED FIXED

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

Description

[btham]

Steps to reproduce:

I am filing this on behalf of someone else, who has an M1 iMac running macOS Big Sur 11.6 and Firefox 94.0.1. They report that the issue happens 100% of the time, but on my own personal Macbooks, I don't have this issue, so it may only affect some Mac models.

1. On Firefox, open https://webrtc.github.io/samples/src/content/getusermedia/getdisplaymedia/.
2. Start sharing content.
3. Try to minimize the float bar that appears.

Actual results:

Float bar cannot be minimized.

Expected results:

Float bar is minimized.

Comment 1

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

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

Comment 2

[Emma Zühlcke [:emz]]

Can't reproduce on Ubuntu 21.10 and my Catalina macOS VM.
Could you elaborate on "Float bar cannot be minimized"? Does nothing happen when the minimize button is pressed? A screen recording could also help to diagnose this issue.
This doesn't seem directly SitePermissions related so I'm moving it to Widget.

Comment 3

[Stephen A Pohl [:spohl]]

I'm not currently able to reproduce this either. Could you provide a screen recording of the issue?

Comment 4

[Emma Zühlcke [:emz]]

:timhuang was able to reproduce this on macOS. I can now also reproduce in my macOS VM on Nightly. Seems to be a recent regression, since I can't reproduce on release.
The minimize button of the WebRTC screen sharing indicator window reacts to clicks but doesn't minimize the window.

Comment 5

[Emma Zühlcke [:emz]]

Mike, could this be related to your patch for Bug 1732572?

Comment 6

[Mike Conley (:mconley) (:⚙️)]

I just did a mozregression:

53:47.48 INFO: Narrowed integration regression window from [78b7f5ef, 572b175e] (4 builds) to [ca239a52, 572b175e] (2 builds) (~1 steps left)
53:47.48 INFO: No more integration revisions, bisection finished.
53:47.48 INFO: Last good revision: ca239a52bff698c5349389675c1af7a83553b523
53:47.48 INFO: First bad revision: 572b175efb0960eb15cc814d9c8f8f65afecae52
53:47.48 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ca239a52bff698c5349389675c1af7a83553b523&tochange=572b175efb0960eb15cc814d9c8f8f65afecae52

so this looks to have been introduced by the switch to the new macOS SDK.

Comment 7

[Markus Stange [:mstange]]

Interesting! This explains why M1 Macs have always had this issue, but Intel Macs only as of a few days ago.

What's supposed to happen when the minimize button is clicked? Is the window supposed to minimize into the Dock?

Comment 8

[Markus Stange [:mstange]]

(In reply to Markus Stange [:mstange] from comment #7)

Is the window supposed to minimize into the Dock?

Looks like it.

The AppKit 10.13 release notes contain this:

The NSWindowStyleMaskMiniaturizable style mask bit is properly respected for applications that link on 10.13 or higher. Previously, it would only include showing or hiding the miniaturize button, but the window would potentially still be miniaturizable via menu items or double clicking on the titlebar.

So it sound like we're not specifying NSWindowStyleMaskMiniaturizable for this window, but should be.

Comment 9

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

Set release status flags based on info from the regressing bug 1696504

Comment 10

[Stephen A Pohl [:spohl]]

Looking into this.

Comment 11

[Stephen A Pohl [:spohl]]

Attachment: Bug 1742877: Add the proper window mask to popup windows on macOS that can be miniaturized, such as the screen share indicator. r=mstange

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2554962111fd
Add the proper window mask to popup windows on macOS that can be miniaturized, such as the screen share indicator. r=mstange

Comment 13

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/2554962111fd

Comment 14

[Morgan Reschenberg [:morgan]]

Any tips on how to reproduce this?
I'm testing on and intel mac with macOS 12.1 and SDK=11.0. After reverting this patch I can't repro the original bug where the dialog doesn't minimise :( trying to debug the regression, since it's pretty impactful for VO users

Comment 15

[Stephen A Pohl [:spohl]]

(In reply to Morgan Reschenberg [:morgan] from comment #14)

Any tips on how to reproduce this?
I'm testing on and intel mac with macOS 12.1 and SDK=11.0. After reverting this patch I can't repro the original bug where the dialog doesn't minimise :( trying to debug the regression, since it's pretty impactful for VO users

Are you confident that you built with the macOS 11 SDK? I just confirmed on Intel macOS 12.3 that I'm able to reproduce the original bug here if Firefox is built with any macOS SDK newer than 10.12. Only macOS 10.12 didn't reproduce the issue reported here. More specifically, I was able to reproduce the issue with Firefox built with the macOS 10.13, 10.14, 10.15, 11.0 and 12.3 SDK.

Comment 16

[Morgan Reschenberg [:morgan]]

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

(In reply to Morgan Reschenberg [:morgan] from comment #14)

Any tips on how to reproduce this?
I'm testing on and intel mac with macOS 12.1 and SDK=11.0. After reverting this patch I can't repro the original bug where the dialog doesn't minimise :( trying to debug the regression, since it's pretty impactful for VO users

Are you confident that you built with the macOS 11 SDK? I just confirmed on Intel macOS 12.3 that I'm able to reproduce the original bug here if Firefox is built with any macOS SDK newer than 10.12. Only macOS 10.12 didn't reproduce the issue reported here. More specifically, I was able to reproduce the issue with Firefox built with the macOS 10.13, 10.14, 10.15, 11.0 and 12.3 SDK.

Yep. I was building with 10.14 before and couldn't reproduce -- just upgraded yesterday to 11.0. For reference, this is my mozconfig:

ac_add_options --enable-debug --enable-optimize --enable-debug-symbols
ac_add_options --enable-application=browser
mk_add_options AUTOCLOBBER=1

ac_add_options --with-macos-sdk=$HOME/SDK-archive/MacOSX11.0.sdk/
ac_add_options --with-ccache=sccache

I can try with another SDK, though, I have 10.13 locally. I'll also update to 12.2.

Comment 17

[btham]

We are still seeing this issue in Firefox 98.0.1, even though this bug has been marked as resolved. Has the issue really been fixed?

Comment 18

[Stephen A Pohl [:spohl]]

(In reply to btham from comment #17)

We are still seeing this issue in Firefox 98.0.1, even though this bug has been marked as resolved. Has the issue really been fixed?

Could you please confirm that you are able to reproduce using the steps from comment 0? Or do you have different steps to reproduce?

Comment 19

[btham]

Yes, it can be reproduced with the same steps. If it helps, the machine that that we are using to reproduce this issue is an 8GB M1 iMac (24-inch, 2021) running macOS Monterey 12.1.

Comment 20

[Stephen A Pohl [:spohl]]

Attachment: Bug 1742877: Add the proper window mask to borderless windows on macOS that are expected to be miniaturizable, such as the screen share indicator. r=mstange

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9454a96dd01a
Add the proper window mask to borderless windows on macOS that are expected to be miniaturizable, such as the screen share indicator. r=mstange

Comment 22

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/9454a96dd01a

Comment 23

[Stephen A Pohl [:spohl]]

Would you be able to confirm that this is now fixed for you as well (as of tomorrow's nightly build, April 6th)?

Comment 24

[btham]

Apologies for the delayed response. I've asked the person who is having this issue to try to reproduce it on Firefox Nightly and will have a response soon.

Comment 25

[btham]

We've tested on Nightly version 101.0a1 and the issue no longer occurs. Thanks for your help!

Comment 26

[Stephen A Pohl [:spohl]]

(In reply to btham from comment #25)

We've tested on Nightly version 101.0a1 and the issue no longer occurs. Thanks for your help!

Glad to hear it. Thanks for verifying!