1390125 - javascript fullscreen api for Firefox 52.3.0 in Mac 10.13 beta 5 does not make the window go fullscreen completely

Status: RESOLVED WORKSFORME

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

Description

[Adit Shetty]

Attachment: screen capture.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36

Steps to reproduce:

a) Open the url (https://davidwalsh.name/demo/fullscreen.php) in Firefox ESR 52.3.0 in Mac 10.13 beta 5
b) Click on Launch Fullscreen



Actual results:

The firefox window does not completely go fullscreen , The screen only extends up to the dock and the dock is visible


Expected results:

The firefox window should completely go fullscreen

Comment 1

[Lawrence Mandel [:lmandel] (use needinfo)]

[Tracking Requested - why for this release]: Flagged by Apple as important for the education and testing/assessment market. Suggested to file a Radar ticket if this is determined to be an issue for Apple as this does not repro on shipping version of macOS.

Comment 2

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Tracked for ESR52.4, too early to tell whether this warrants an ESR dot release. GChang, FYI

Comment 3

[Marcia Knous [:marcia]]

This looks to be a dupe of the bug Markus filed, Bug 1382696

Comment 5

[Marcia Knous [:marcia]]

Bug 1382696 was filed in Widget|Cocoa - can someone clarify whether it belongs there or in Shell Integration?

Also I can confirm on my 10.13 machine running Beta 6 that this does work in Chrome stable.

Comment 6

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Folks from Apple (who pinged lmandel) confirmed that this is an issue with 56, 57 as well.

Comment 7

[Lawrence Mandel [:lmandel] (use needinfo)]

Attachment: Issue in mainline Firefox

From Apple: It reproduces a slightly different issue on mainline. The area where the dock is supposed to be hidden, we see the offscreen region behind the dock. macOS 10.13 (17A344) and Firefox 54.0.1

Comment 9

[Lawrence Mandel [:lmandel] (use needinfo)]

Robert - You're listed as the triage owner. Can we prioritize this so that it can be addressed before the release for MacOS 10.13?

Comment 10

[Robert Strong (they/them - no direct email)]

This bug was triaged incorrectly and misfiled. Screen sizing is most likely a widget issue.

Comment 11

[Marcia Knous [:marcia]]

Stephen: Can you help find an owner for this? Thanks.

Comment 12

[Liz Henry (:lizzard) (relman/hg->git project)]

We aren't sure when MacOS release will happen, but it seems likely during the 56 release timeframe. 
Tracking for 56. If we land a fix let's rapidly test and uplift to beta.

Comment 13

[Stephen A Pohl [:spohl]]

(In reply to Marcia Knous [:marcia - use ni] from comment #3)
> This looks to be a dupe of the bug Markus filed, Bug 1382696

Markus, were you already looking into this?

Comment 14

[Markus Stange [:mstange]]

I haven't looked into this yet, and I currently don't have a 10.13 install around.

Comment 15

[Liz Henry (:lizzard) (relman/hg->git project)]

Markus and Stephen, can you either work on this between you or help us find someone who can work on it now? We have only beta 12 later this week and the RC next week before the release.  Since we know this will break in 56 it would be best to fix it now so we can avoid doing it in a dot release.

Comment 16

[Joe Hildebrand [:jhildebrand] (UTC-6)]

Works as intended on 57nightly, OSX 10.12.  Does it happen on both 10.10 and 10.13?  Can someone that can reproduce this try setting your Dock prefs to "Automatically Show and Hide Dock", and see if it has an effect?

Comment 17

[Stephen A Pohl [:spohl]]

Looking into it.

Comment 19

[Joe Hildebrand [:jhildebrand] (UTC-6)]

[Tracking Requested - why for this release]:

Comment 20

[Jim Mathies [:jimm]]

That wontfix 57 setting would have kept this out of our triage lists. :) FYI.

Comment 21

[Jim Mathies [:jimm]]

[Tracking Requested - why for this release]:
57 blocker

bug was updated incorrectly, we consider this a 57 blocker.

Comment 22

[Marcia Knous [:marcia]]

(In reply to Joe Hildebrand  [:hildjj] (UTC-6) from comment #16)
> Works as intended on 57nightly, OSX 10.12.  Does it happen on both 10.10 and
> 10.13?  Can someone that can reproduce this try setting your Dock prefs to
> "Automatically Show and Hide Dock", and see if it has an effect?

I just tested on the latest Beta 9 on 10.13 using:

* latest Nightly - 20170912100139
* latest Beta - 20170911193316
* Firefox 55.0.3

If I change to "Automatically Show and Hide Dock" the browser does show full screen. So it seems the issue only happens when that pref is unchecked.

Comment 23

[Sylvestre Ledru [:Sylvestre]]

Might be also a blocker for 56 as we know when the new Mac OS X release is: September 25th

Comment 24

[Stephen A Pohl [:spohl]]

Attachment: Reduced test case

This appears to be a bug in macOS 10.13. I have filed a radar bug (https://bugreport.apple.com/web/?problemID=34410037). Here is what was posted in the radar bug:

Title
macOS 10.13 reports incorrect [[NSWindow screen] visibleFrame].origin.y and height when dock is hidden

Product
macOS + SDK AppKit

Classification
Bug

Bug Type
UI/Usability

Reproducibility
Always

Description
Summary:
On macOS 10.13 Beta (17A360a), when the dock and menu is hidden via [NSApp setPresentationOptions:NSApplicationPresentationHideDock | NSApplicationPresentationHideMenuBar], [[NSWindow screen] visibleFrame].origin.y is not adjusted to account for the fact that the Dock was hidden. This does not occur on 10.12 and below. Specifically, if the Dock has a height of 80, [[NSWindow screen] visibleFrame].origin.y remains at 80 when the Dock is hidden. It used to be set to 0 on 10.12 and below. This also impacts the visibleFrame's height, as it will be 80 smaller than expected. This causes fullscreen issues in Firefox[1] because the OS reports an incorrect "... rectangle defining the portion of the screen in which it is currently safe to draw your application content."[2], resulting in fullscreen mode to only extend down to where the Dock would usually appear, exposing the Desktop. This is believed to be a bug in 10.13 because the Apple Developer Documentation neither mentions changes to [NSApp setPresentationOptions:][3] nor [[NSWindow screen] visibleFrame][4].

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1390125
[2] https://developer.apple.com/documentation/appkit/nsscreen/1388369-visibleframe?language=objc
[3] https://developer.apple.com/documentation/appkit/nsapplication?changes=latest_major&language=objc
[4] https://developer.apple.com/documentation/appkit/nsscreen?changes=latest_major&language=objc

There are two options to reproduce the issue:

Option 1:
Steps to Reproduce:
(From https://bugzilla.mozilla.org/show_bug.cgi?id=1390125#c0)
a) Open the url (https://davidwalsh.name/demo/fullscreen.php) in Firefox ESR 52.3.0 in Mac 10.13 beta 5
b) Click on Launch Fullscreen

Expected Results:
The firefox window should completely go fullscreen.

Actual Results:
The firefox window does not completely go fullscreen on macOS 10.13. The screen only extends up to the dock and the dock area is visible.

Version/Build:
macOS 10.13

Configuration:
Any version of Firefox.

Option 2:
Steps to Reproduce:
1. Compile and run the attached reduced test case.
2. Click the button, observe the console output.

Expected Results:
When the Dock is hidden, the visibleFrame's origin is {0, 0} and the visibleFrame's height is equal to the maximum screen height.

Actual Results:
On macOS 10.13 with a Dock of height 80, when the Dock is hidden, the visibleFrame's origin is {0, 80} and the visibleFrame's height is 80 less than the expected maximum screen height.

Version/Build:
macOS 10.13

Configuration:
Any.

Comment 25

[Stephen A Pohl [:spohl]]

The issue described in comment 24 is experienced at [1] in our code base. Since macOS 10.13 reports an incorrect "rectangle defining the portion of the screen in which it is currently safe to draw your application content"[2], we do not attempt to draw where the Dock is usually visible, resulting in Firefox not going fullscreen completely as was reported in this bug.

[1] https://dxr.mozilla.org/mozilla-central/rev/f9a5e9ed62103c84e4cde915f4d08f1ce71be83e/widget/cocoa/nsCocoaWindow.mm#243-244
[2] https://developer.apple.com/documentation/appkit/nsscreen/1388369-visibleframe?language=objc

Comment 26

[Liz Henry (:lizzard) (relman/hg->git project)]

I don't think we should block 56 on this issue; it will be broken in 55 as well until Apple is able to fix the issue on their side. 

It doesn't sound like there is an easy or safe workaround, but I'll leave that to spohl and maybe mstange to figure out.  If we do come up with a workaround, we can still take an uplift to mozilla-release up till the middle of next week.

Comment 27

[charlie.siegel]

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #26)
> I don't think we should block 56 on this issue; it will be broken in 55 as
> well until Apple is able to fix the issue on their side. 
> 
> It doesn't sound like there is an easy or safe workaround, but I'll leave
> that to spohl and maybe mstange to figure out.  If we do come up with a
> workaround, we can still take an uplift to mozilla-release up till the
> middle of next week.

I opened https://bugzilla.mozilla.org/show_bug.cgi?id=1397102

The main thing I have to say to this is, this issue doesn't existing in Chrome, Brave, and Safari.  How are they handling this scenario differently so that they're not affected?

It looks like 56 is scheduled for a few days after the release of High Sierra, so I guess either way this issue will still be present on High Sierra launch.  But on the other hand, going until Apple fixes this in 10.13.1 or mid November for 57 is going to be a long time where people are wondering why Firefox doesn't work with Youtube in fullscreen but Chrome does...

Comment 28

[Julien Cristau [:jcristau]]

This is not going to block esr52.4 so not tracking for that version specifically.

Comment 29

[Stephen A Pohl [:spohl]]

Quick update from the Apple radar bug: My radar bug was marked as duplicate of radar bug 33928542. It appears that Apple has already been aware of this bug.

Comment 30

[Stephen A Pohl [:spohl]]

(In reply to charlie.siegel from comment #27)
> The main thing I have to say to this is, this issue doesn't existing in
> Chrome, Brave, and Safari.  How are they handling this scenario differently
> so that they're not affected?

Doing a quick check with Safari, it appears that they're using native fullscreen mode here. Firefox doesn't use native fullscreen mode in this case to allow for interaction with other internal & external screens. You can play a video fullscreen on your internal screen while browsing the web on an external screen, for example.

Comment 31

[Sylvestre Ledru [:Sylvestre]]

Stephen, is there a way to workaround that in our product?

Comment 32

[Stephen A Pohl [:spohl]]

There are two options. I don't like either one of them and it would not address the fact that all previous versions of Firefox are affected by this. A fix from Apple would address it across the board.

1. Ignore the values returned by [[NSWindow screen] visibleFrame].origin.y and [[NSWindow screen] visibleFrame].height and adjust it such that origin.y is always 0 and height is adjusted to cover the entire screen. This is bad because it goes directly against what Apple says is the "... rectangle defining the portion of the screen in which it is currently safe to draw your application content."[1] It is hard to predict what could happen if we started drawing in a portion of the screen that is not considered safe to draw in. At best, it just works. At worst, we could open the door to crashes and other bad behavior.
2. Switch to native fullscreen mode. At a minimum, we would lose the ability to interact with content/applications on other screens.

Markus, do you have any thoughts?

[1] https://developer.apple.com/documentation/appkit/nsscreen/1388369-visibleframe?language=objc

Comment 33

[Sylvestre Ledru [:Sylvestre]]

We release next week, so, if we can find a mitigation strategy, we should act fast.

1) seems risky 
2) seems too much work, isn't it?

Comment 34

[Liz Henry (:lizzard) (relman/hg->git project)]

I don't think this should block 56. The workaround currently seems to be in comment 22.  
- Make sure to check the option, "Automatically Show and Hide Dock" in the OS. 
- Then the browser does show full screen. 

I'm not sure what the default is in MacOS - show and hide dock, or not. But this is a fairly simple workaround for users. We can release note it for 56 and put up a sumo page

Comment 35

[charlie.siegel]

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #34)
> I don't think this should block 56. The workaround currently seems to be in
> comment 22.  
> - Make sure to check the option, "Automatically Show and Hide Dock" in the
> OS. 
> - Then the browser does show full screen. 
> 
> I'm not sure what the default is in MacOS - show and hide dock, or not. But
> this is a fairly simple workaround for users. We can release note it for 56
> and put up a sumo page

The default is not to hide the dock. 

This won’t be a popular workaround. Mac users who know where this setting is are very particular about how they have their dock setup.

Comment 36

[charlie.siegel]

Actually a much cleaner workaround with no impact on the overall system configuration is to do the following:

1. Make Firefox fullscreen by pressing the green fullscreen dot in the top left corner.
2. Make the video fullscreen.

The issue doesn't occur under these circumstances.

Comment 37

[Michał Gołębiowski-Owczarek [:mgol]]

(In reply to Stephen A Pohl [:spohl] from comment #30)
> (In reply to charlie.siegel from comment #27)
> > The main thing I have to say to this is, this issue doesn't existing in
> > Chrome, Brave, and Safari.  How are they handling this scenario differently
> > so that they're not affected?
> 
> Doing a quick check with Safari, it appears that they're using native
> fullscreen mode here. Firefox doesn't use native fullscreen mode in this
> case to allow for interaction with other internal & external screens. You
> can play a video fullscreen on your internal screen while browsing the web
> on an external screen, for example.

That's possible natively in macOS since Mavericks and current Firefox doesn't even support any older macOS version. This shouldn't be an issue; I'm using fullscreen mode in Chrome without these kind of problems.

Comment 38

[Michał Gołębiowski-Owczarek [:mgol]]

(In reply to Michał Gołębiowski-Owczarek [:mgol] from comment #37)
> (In reply to Stephen A Pohl [:spohl] from comment #30)
> > Doing a quick check with Safari, it appears that they're using native
> > fullscreen mode here. Firefox doesn't use native fullscreen mode in this
> > case to allow for interaction with other internal & external screens. You
> > can play a video fullscreen on your internal screen while browsing the web
> > on an external screen, for example.
> 
> That's possible natively in macOS since Mavericks and current Firefox
> doesn't even support any older macOS version. This shouldn't be an issue;
> I'm using fullscreen mode in Chrome without these kind of problems.

I've extracted the request to use the native API to bug 1403085.

Comment 45

[Sylvestre Ledru [:Sylvestre]]

Release Note Request (optional, but appreciated)
[Why is this notable]: Important bug on mac
[Affects Firefox for Android]: no
[Suggested wording]: Due to a bug in Mac OS X High Sierra, the fullscreen mode has some issues.
[Links (documentation, blog post, etc)]:

Comment 46

[Sylvestre Ledru [:Sylvestre]]

We should probably add that to the 55 & 56 release notes as an known issue, wdyt?

Comment 47

[Andrew Moff]

FYI Apple seed First macOS High Sierra 10.13.1 Beta to Developers yesterday, anyone had a chance to test?

Comment 48

[Marcia Knous [:marcia]]

(In reply to Andrew Moff from comment #47)
> FYI Apple seed First macOS High Sierra 10.13.1 Beta to Developers yesterday,
> anyone had a chance to test?

Yes, the issue is still present with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:58.0) Gecko/20100101 Firefox/58.0 (as well as Beta 57) using latest Mac Seed 10.13.1.

Comment 49

[Liz Henry (:lizzard) (relman/hg->git project)]

(In reply to charlie.siegel from comment #36)
> Actually a much cleaner workaround with no impact on the overall system
> configuration is to do the following:
> 
> 1. Make Firefox fullscreen by pressing the green fullscreen dot in the top
> left corner.
> 2. Make the video fullscreen.
> 
> The issue doesn't occur under these circumstances.

Thanks charlie. We can write a release note and link to a support page with this workaround!

Comment 50

[Joni Chan]

I created a draft here: https://docs.google.com/a/mozilla.com/document/d/15TaofDw-OWvKqBC9YVJq4rqayo3qrJjRSvMjLdvXE7c/edit?usp=sharing

Can someone check it to make sure it's right before we publish it?

Comment 52

[Stephen A Pohl [:spohl]]

(In reply to Joni Savage ("need info" me) from comment #50)
> I created a draft here:
> https://docs.google.com/a/mozilla.com/document/d/15TaofDw-
> OWvKqBC9YVJq4rqayo3qrJjRSvMjLdvXE7c/edit?usp=sharing
> 
> Can someone check it to make sure it's right before we publish it?

Thanks for putting this together! A few comments:

1. We need to drop/replace the following sentence:

"This issue will be fixed when Mac OSX 10.13 is released."

macOS 10.13 has already been released and the issue is not fixed. The fix will come in one of two forms: either Apple fixes it in macOS itself or we implement a workaround in Firefox. We're not sure which way this will go yet. For now, please either drop the sentence or change it to something along the lines of: "The issue will be fixed in a future update to macOS or Firefox."

2. Please change references to Apple's operating system to "macOS xx.xx", xx.xx being replaced by the version in question such as 10.13, or "macOS High Sierra". This is the official way that Apple refers to its operating system now.

3. We should not refer to specific Firefox versions, as all versions of Firefox are affected by this macOS bug (including ESR).

Comment 53

[Stephen A Pohl [:spohl]]

I just installed the 10.13.1 Beta (17B25c) and the problem persists.

Comment 54

[Marcia Knous [:marcia]]

Since we cannot see the radar bug that Stephen's bug was duped to, I assume we should reach out to our Apple contacts again and try to get a status update?

Comment 55

[Andrew Moff]

Are we able to use the same implementation as VLC which also isn't suffering the same problem as Firefox? I note that while using VLC in fullscreen, you are still able to interact with windows on another screen.

Regardless at this point we should assume assume that apple may never resolve this issue so we should begin working on a work around for High Sierra users. Visible bugs like these which arent affecting other browsers have a strong chance of turning people away from Firefox.

Comment 56

[charlie.siegel]

(In reply to Andrew Moff from comment #55)

> Regardless at this point we should assume assume that apple may never
> resolve this issue so we should begin working on a work around for High
> Sierra users. Visible bugs like these which arent affecting other browsers
> have a strong chance of turning people away from Firefox.

+1 (from an end users perspective)

Comment 57

[Stephen A Pohl [:spohl]]

See comment 52.

Comment 60

[Marlin]

When Chrome and Safari use the fullscreen API, Mission Control shows the javascript full screen in a separate window (in a separate space from the desktop) from the main browser.  Doing this appears to "bypass" the bug.

You can test this by opening different browsers to https://davidwalsh.name/demo/fullscreen.php > launch fullscreen > press "F3" for mission control to compare.

Given the nature of this bug, it is easily noticeable by the end user - it should be categorized as a "showstopper" and fixed before the general release of 57.

Comment 62

[Marcia Knous [:marcia]]

I can confirm that in the second beta of 10.13.1, https://davidwalsh.name/demo/fullscreen.php now shows as full screen for me using both the latest 57 beta and nightly 58.

Comment 63

[charlie.siegel]

(In reply to Marcia Knous [:marcia - use ni] from comment #62)
> I can confirm that in the second beta of 10.13.1,
> https://davidwalsh.name/demo/fullscreen.php now shows as full screen for me
> using both the latest 57 beta and nightly 58.

Good to hear.  

I was just messing around with Vivaldi, which is basically Chromium and it full screens properly.  I've asked this before, but does anyone know what Chromium is doing differently?  It is not native MacOS full screen functionality (I don't have a second monitor to test whether or not it takes over all monitors though).

Comment 64

[Michał Gołębiowski-Owczarek [:mgol]]

(In reply to charlie.siegel from comment #63)
> I've asked this before, but does anyone know what
> Chromium is doing differently?  It is not native MacOS full screen
> functionality (I don't have a second monitor to test whether or not it takes
> over all monitors though).

What made you think it's not using native full screen? I've just checked and it looks native to me.

For the rest of your comment, see my Comment 37.

Comment 65

[meuxx]

I can also confirm it's working in macOS 10.13.1 beta 2 (17B35a)

Comment 66

[charlie.siegel]

(In reply to Michał Gołębiowski-Owczarek [:mgol] from comment #64)
> (In reply to charlie.siegel from comment #63)
> > I've asked this before, but does anyone know what
> > Chromium is doing differently?  It is not native MacOS full screen
> > functionality (I don't have a second monitor to test whether or not it takes
> > over all monitors though).
> 
> What made you think it's not using native full screen? I've just checked and
> it looks native to me.
> 
> For the rest of your comment, see my Comment 37.

Normally with macOS native full screen mode you get the stoplight buttons in the upper left corner when you mouse up to the top of the screeen. This isn't there with chromium based browsers in full screen. It looks like they're doing something different.

Comment 67

[Michał Gołębiowski-Owczarek [:mgol]]

(In reply to charlie.siegel from comment #66)
> Normally with macOS native full screen mode you get the stoplight buttons in
> the upper left corner when you mouse up to the top of the screeen. This
> isn't there with chromium based browsers in full screen. It looks like
> they're doing something different.

I haven't seen the code so I can't be 100% certain what they use but the fullscreen view does get a separate macOS space and if you move the mouse to the top, the menu bar appears; all that's missing are window controls. The macOS Fullscreen API allows to hide the controls, see:
https://developer.apple.com/library/content/documentation/General/Conceptual/MOSXAppProgrammingGuide/FullScreenApp/FullScreenApp.html:
> A window delegate may also specify that the window toolbar be removed from the window in full-screen mode and be shown automatically with the menu bar

It looks quite native to me.

Comment 68

[Stephen A Pohl [:spohl]]

This is fixed by Apple in macOS 10.13.1 Beta 2. Leaving this open until macOS 10.13.1 officially ships.

Comment 77

[Scott Macpherson]

This *appears* to be resolved by the public release of 10.13.1. Can anyone else confirm?

Comment 78

[Tobias (:Tobbi) Markus]

(In reply to Scott Macpherson from comment #77)
> This *appears* to be resolved by the public release of 10.13.1. Can anyone
> else confirm?

I just updated to 10.13.1 and the bug is still present there with Nightly 58.0a1 (2017-10-30) (64-Bit)

Comment 79

[Tobias (:Tobbi) Markus]

I must apologize: For some reason, my mac restarted and I thought it had updated. 

Anyway, I updated to 10.13.1 for real now and I can confirm that the bug is gone.

Nightly 58.0a1 (2017-10-30) (64-Bit)

Comment 80

[goalieca]

This is resolved for me as well. Running Nightly 58.0a1 (2017-10-30) (64-bit)

Comment 81

[charlie.siegel]

This is resolved for me.  I'm running the latest Beta.

Comment 82

[Stephen A Pohl [:spohl]]

Confirmed fixed by Apple in macOS 10.13.1.

Comment 83

[Kohei Yoshino]

(WORKSFORME is the correct resolution as nothing has been fixed in Firefox.)

Comment 90

[Liz Henry (:lizzard) (relman/hg->git project)]

Cleaning up release note issues - This was noted for Firefox 56 release but without the link to the SUMO page. I can't tweak the flag to be anything pre-57 though. 

Joni, if you have that link handy, I might just go add it for posterity.

Comment 91

[Joni Chan]

Liz, we never published it on SUMO so there's no link. I have the Google draft though if we ever need to make a SUMO page out of it.