1737953 - Fullscreen is letterboxed on all four sides on new Macbook Pro with camera notch

Status: RESOLVED FIXED

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

Description

[April King [:April]]

On the new 14" MBP (with the notch), when going full screen on videos - either on YouTube or just general HTML5 videos - there is a border on the horizontal sides. This means that the videos don't take up as much space as they would normally be able to otherwise.

This issue doesn't seem to be present in Chromium-based browsers running on macOS Monterey. Unfortunately, this seems to be impossible to screenshot, although I could probably take a camera photo if that would be helpful.

Comment 1

[C.M.Chang[:chunmin]]

Thanks for the report! It would be great to have a photo!
Unfortunately, I don't have a 14 MBP to verify this issue. Does the video play well in this case, despite having a border on the horizontal sides?

Comment 2

[pireads]

Hi!

I was able to reproduce this on my 14" Macbook Pro with Firefox 94.0.1 whenever I switched the app from an external display back to my main display. I recorded a video of it here.

At first, it behaves normally, but you can see the letterboxing at 17s after moving Firefox back.

This is my first time posting anything on here, so I hope the video uploaded correctly and was a useful format for you.

Let me know if you need anything else to help track this down, and thank you for the work you do!

Comment 3

[C.M.Chang[:chunmin]]

By the video provided in #comment 2, it looks like this is more a graphic issue rather than playback since it can be reproduced without playing video

Comment 4

[pireads]

I seem to have fixed the problem on my machine by taking the following steps:

1. Open Finder
2. Navigate to Applications
3. Right click Firefox
4. Click Get Info
5. Deselect Scale to fit below built-in camera
6. Restart Firefox

I wonder if it would be possible to have this setting turned off by default?

Comment 5

[Jonathan Kew [:jfkthame]]

More of a Widget::Cocoa issue than Graphics; moving to that component.

It looks like this can be controlled by an Info.plist setting: https://developer.apple.com/documentation/bundleresources/information_property_list/nsprefersdisplaysafeareacompatibilitymode?language=objc

I don't have access to a suitable machine to confirm how this behaves, and whether there are issues that would make forcing it to NO problematic at the moment.... e.g. in fullscreen mode, would we end up with a tab in the middle getting "lost" behind the camera?

Comment 6

[Stephen A Pohl [:spohl] (OOO until 9/11)]

Setting n-i for myself to verify this as soon as my system arrives.

Comment 7

[Stephen A Pohl [:spohl] (OOO until 9/11)]

(In reply to Jonathan Kew (:jfkthame) from comment #5)

More of a Widget::Cocoa issue than Graphics; moving to that component.

It looks like this can be controlled by an Info.plist setting: https://developer.apple.com/documentation/bundleresources/information_property_list/nsprefersdisplaysafeareacompatibilitymode?language=objc

I don't have access to a suitable machine to confirm how this behaves, and whether there are issues that would make forcing it to NO problematic at the moment.... e.g. in fullscreen mode, would we end up with a tab in the middle getting "lost" behind the camera?

I was able to confirm that we run exactly into this problem. To make matters worse, the tab bar seem to disappear towards the top of the screen by default, making tabs barely visible. By hovering the mouse towards the top of the screen to display the macOS menu bar, the menu bar displays over the browser window, obscuring even more of the window. The browser no longer slides down like it should.

This will require some work before we can set the NSPrefersDisplaySafeAreaCompatibilityMode Info.plist flag to NO by default. Specifically, Apple's documentation says the following:

"On Macs that include a camera housing in the bezel, the auxiliaryTopLeftArea and auxiliaryTopRightArea properties of NSScreen contain the regions to the left and right of the camera housing. Use those properties and the visibleFrame property to determine where to display your content."

Comment 8

[Andrew Moff]

Noticing this too on my new macbook with FF 105.0.1.

To clarify, fullsceen mode is fine for normal browsing; FF correctly leaves a gap so tabs can all appear below notch. Only when you are watching a video and enter fullscreen do you enter letterbox mode.

Comment 10

[Karl Tomlinson (:karlt)]

Looks like the code is asking the fullscreen window to fill the entire height, but in fact it gets shrunk to fit a lesser height.
Is the height available for fullscreen obtainable?

Comment 12

[Stephen A Pohl [:spohl] (OOO until 9/11)]

From bug 1881941 comment 3:

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

I'm not quite sure why this behavior was different on Firefox 122. Could you take a look at bug 1737953 and see if this is the same issue that you reported here?

I guess it is the same issue. I've always had 'full-screen-api.transition-duration.enter' and 'full-screen-api.transition-duration.leave' set to '0 0' on all devices so I mustve not noticed the letterboxing issue since I got my MBP 14 in the summer of 2022.
If I reset the two full-screen settings back to the default that FF ships with (200 200) then I get letterboxing on all the versions I have tried (122.0.1, 123, 124.0b5) but with the transition set to '0 0', on FF 122.0.1 the fullscreen video playback uses the correct screen dimensions. Only on FF 123 and higher does the letterboxing appear with the transition set to '0 0'.

I should note, the behaviour when the transition is set to '0 0' is different to when Scale to fit below built-in camera has been deselected. Scale to fit below built-in camera causes text (such as youtube titles) or vertical videos to be clipped by the notch whilst with the transition is set to '0 0', text remains within the safe space and no content exceeds the boundary between apps and the mac menu bar.
Something about the transition being set to '0 0' must be bypassing the letterboxing effect which inadvertently leads to the correct behaviour on 122.0.1 and earlier?

I've reverted back to 122.0.1 and the issue has gone away as you can see from the pictures I uploaded with my original report.

I'm keen to have this fixed as one of the main reasons I switched to FF on macOS was because it didn't use the native full screen mode when viewing videos so happy to try and help as much as I can.

Thanks.

Comment 14

[Stephen A Pohl [:spohl] (OOO until 9/11)]

I have a try build with a potential fix for this. If you have a chance, could you unpack it and let me know whether you are still seeing the issue?

https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/W04zUObKT1KBHdJu1DhstA/artifacts/public/build/target.tar.gz

The archive contains a separate Firefox Nightly, so it will not affect your regular Firefox. After extracting it, if macOS blocks it on first launch, you can clear the quarantine attribute on the extracted app:

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

Comment 15

[pireads]

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

I have a try build with a potential fix for this. If you have a chance, could you unpack it and let me know whether you are still seeing the issue?

https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/W04zUObKT1KBHdJu1DhstA/artifacts/public/build/target.tar.gz

The archive contains a separate Firefox Nightly, so it will not affect your regular Firefox. After extracting it, if macOS blocks it on first launch, you can clear the quarantine attribute on the extracted app:

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

Looks like that worked for my repro!
I noticed that the checkbox in Get Info isn't present at all in the build attached, and the letterboxing on the side of the screen is gone when following the steps I described in comment #2. Both are still present in 152.0.4, so nothing in the past four years has fixed this before your build.
Thank you!

Comment 16

[Stephen A Pohl [:spohl] (OOO until 9/11)]

Thank you for verifying this, that is really helpful. Based on your confirmation I simplified the fix down to just the essential change and removed some extra code that I believe to not be needed. Could you confirm that this updated try build still resolves the letterboxing for you, following the same steps from comment #2?

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

As before, the archive contains a separate Firefox Nightly, so it will not affect your regular Firefox. After extracting it, if macOS blocks it on first launch, you can clear the quarantine attribute on the extracted app:

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

Comment 17

[pireads]

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

Thank you for verifying this, that is really helpful. Based on your confirmation I simplified the fix down to just the essential change and removed some extra code that I believe to not be needed. Could you confirm that this updated try build still resolves the letterboxing for you, following the same steps from comment #2?

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

As before, the archive contains a separate Firefox Nightly, so it will not affect your regular Firefox. After extracting it, if macOS blocks it on first launch, you can clear the quarantine attribute on the extracted app:

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

Yep, this one worked as well!

Comment 18

[Stephen A Pohl [:spohl] (OOO until 9/11)]

Attachment: Bug 1737953: Fill notched screens in native fullscreen by opting out of display safe area compatibility mode on macOS. r?#mac-reviewers!

On built-in displays with a camera housing (the "notch"), Firefox was running in the display safe area compatibility mode because it never set NSPrefersDisplaySafeAreaCompatibilityMode to NO. In native fullscreen that gave the content a frame that did not match the usable region, which showed up as letterboxing, most visibly for aspect-ratio-preserving fullscreen video, which ended up with borders on all sides.

Setting NSPrefersDisplaySafeAreaCompatibilityMode to NO opts out of that mode so the content fills the full area below the notch. The menu bar strip at the very top stays drawn black by the system while the menu bar is hidden, which matches other native-fullscreen apps such as Safari; macOS does not let a standard-fullscreen app draw into that strip.

On displays without a notch this change is inert.

Comment 19

[Stephen A Pohl [:spohl] (OOO until 9/11)]

Helena, could you help verify this across macOS versions before we rely on it landing?

For context: on MacBooks with a camera housing ("notch"), fullscreen video was letterboxed on the sides because Firefox ran in the display safe area compatibility mode. The fix is a one-line Info.plist change that opts out of that mode ("NSPrefersDisplaySafeAreaCompatibilityMode" set to NO), which lets fullscreen content fill the area below the notch.

Back in 2021 (comment #7) setting this flag to NO was not landable. At that time the tab bar was drawn up into the notch strip and got lost behind the camera, the revealed menu bar overlaid the window, and the toolbar did not slide down. Apple's guidance then was to lay content out around the notch using "auxiliaryTopLeftArea" and "auxiliaryTopRightArea".

On current macOS this no longer seems to happen: in native fullscreen the system keeps app content below the notch and draws the top strip black itself (the same as Safari), so the tabs are not lost behind the camera and no extra layout work is needed. What I have not been able to pin down is exactly when Apple changed this behavior, so I would like to make sure we do not regress on any macOS version we still support.

The try build:

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

If macOS blocks it on first launch, clear the quarantine attribute:

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

On a notched Mac, could you check:

1. Browser fullscreen (green button, tabs visible): every tab is reachable and none are hidden or clipped behind the notch.
2. Moving the mouse to the top reveals the macOS menu bar and the toolbar slides down as expected, rather than the menu bar overlaying and obscuring the window.
3. Fullscreen video fills the screen with no letterboxing on the sides.
4. Please note the macOS version for each result, and flag any version where tabs end up lost behind the notch, the menu bar obscures the window, or the toolbar does not slide down.

One thing to expect so it is not mistaken for a regression: a black strip at the very top where the menu bar sits is normal in fullscreen (Safari shows the same). The thing to watch for is tabs being lost behind the notch or the window being obscured, not that strip.

Thank you!

Comment 20

[Helena Ballent [:hballent]]

I tested this on macOS 26.4.1 on a 16 inch MacBook Pro (Nov 2024). This is currently the only macOS version I have available for testing on a mac with a notch.

When the browser is in full screen, the tabs are visible but the close/minimize button only visible when the mouse is hovering at the top in its own separate bar. Every tab is reachable and none are hidden or clipped behind the notch (all of them sit below the black strip at the top).

When hovering at the top (non video), the menu bar appears in the black strip and the toolbar slides down obscuring the content window (screenshot below). Here I am not sure if you were referring to the content window or the browser window. Since the menu appears in the black strip, none of the browser window gets obscured. I prefer from a UI perspective how Safari solves this, having the close/full screen buttons come in from the side, pushing the tabs to the right so none of the content window gets covered up.

In full screen video, I could not see any letterboxing on the sides and the video fills the screen. When hovering at the top, the close/minimize button appears.

Comment 21

[Helena Ballent [:hballent]]

Attachment: Full screen (non video), mouse hover at top.

Full screen (non video), mouse hover at top. Menu visible in black bar. Tabs, close/minimize strip, and toolbar all reachable. Content window partially obscured by browser bars.

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/9467ca68d97b
https://hg.mozilla.org/integration/autoland/rev/432eaa043d1f
Fill notched screens in native fullscreen by opting out of display safe area compatibility mode on macOS. r=mac-reviewers,bradwerth

Comment 24

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/432eaa043d1f

Comment 25

[Ryan VanderMeulen [:RyanVM]]

Did you want to nominate this for the Fx155 relnotes? If so, set the relnote-firefox flag to "?"
https://wiki.mozilla.org/Release_Management/Release_Notes_Nomination

Possible wording:

Fixed full screen content being letterboxed on MacBooks with a camera notch, most visibly when watching full screen video.

Comment 26

[Stephen A Pohl [:spohl] (OOO until 9/11)]

Release Note Request (optional, but appreciated)
[Why is this notable]: This addresses a long-standing issue with MacBooks with camera notch.
[Affects Firefox for Android]: no
[Suggested wording]: Fixed full screen content being letterboxed on MacBooks with a camera notch, most visibly when watching full screen video.
[Links (documentation, blog post, etc)]: n/a

Comment 27

[Ryan VanderMeulen [:RyanVM]]

Added to the Fx155 relnotes.