Closed Bug 1390125 Opened 2 years ago Closed 2 years ago

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

Categories

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

52 Branch
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
relnote-firefox --- 57+

People

(Reporter: shettyaditsathish, Assigned: spohl)

References

Details

(Keywords: regression)

Attachments

(3 files)

Attached image 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
Component: Untriaged → Shell Integration
[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.
Tracked for ESR52.4, too early to tell whether this warrants an ESR dot release. GChang, FYI
Flags: needinfo?(gchang)
This looks to be a dupe of the bug Markus filed, Bug 1382696
Duplicate of this bug: 1382696
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Folks from Apple (who pinged lmandel) confirmed that this is an issue with 56, 57 as well.
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
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?
Flags: needinfo?(robert.strong.bugs)
This bug was triaged incorrectly and misfiled. Screen sizing is most likely a widget issue.
Component: Shell Integration → Widget: Cocoa
Flags: needinfo?(robert.strong.bugs)
Product: Firefox → Core
Stephen: Can you help find an owner for this? Thanks.
Flags: needinfo?(spohl.mozilla.bugs)
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.
(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?
Flags: needinfo?(spohl.mozilla.bugs) → needinfo?(mstange)
I haven't looked into this yet, and I currently don't have a 10.13 install around.
Flags: needinfo?(mstange)
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.
Flags: needinfo?(spohl.mozilla.bugs)
Flags: needinfo?(mstange)
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?
Looking into it.
Flags: needinfo?(spohl.mozilla.bugs)
Assignee: nobody → spohl.mozilla.bugs
Priority: -- → P1
Flags: needinfo?(mstange)
Flags: needinfo?(gchang)
Duplicate of this bug: 1397102
[Tracking Requested - why for this release]:
That wontfix 57 setting would have kept this out of our triage lists. :) FYI.
[Tracking Requested - why for this release]:
57 blocker

bug was updated incorrectly, we consider this a 57 blocker.
Keywords: feature
(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.
Might be also a blocker for 56 as we know when the new Mac OS X release is: September 25th
Attached file 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.
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
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.
(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...
This is not going to block esr52.4 so not tracking for that version specifically.
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.
(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.
Stephen, is there a way to workaround that in our product?
Flags: needinfo?(spohl.mozilla.bugs)
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
Flags: needinfo?(spohl.mozilla.bugs) → needinfo?(mstange)
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?
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
(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.
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.
(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.
Keywords: regression
(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.
Flags: needinfo?(mstange)
Duplicate of this bug: 1403045
Duplicate of this bug: 1403335
Duplicate of this bug: 1403470
Duplicate of this bug: 1403634
Duplicate of this bug: 1403764
Duplicate of this bug: 1403701
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)]:
relnote-firefox: --- → ?
We should probably add that to the 55 & 56 release notes as an known issue, wdyt?
Flags: needinfo?(lhenry)
FYI Apple seed First macOS High Sierra 10.13.1 Beta to Developers yesterday, anyone had a chance to test?
(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.
(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!
Flags: needinfo?(lhenry)
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?
Duplicate of this bug: 1403673
(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).
I just installed the 10.13.1 Beta (17B25c) and the problem persists.
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?
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.
See comment 52.
Flags: needinfo?(jsavage)
Duplicate of this bug: 1406518
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.
Duplicate of this bug: 1403165
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.
(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).
(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.
I can also confirm it's working in macOS 10.13.1 beta 2 (17B35a)
(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.
(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.
This is fixed by Apple in macOS 10.13.1 Beta 2. Leaving this open until macOS 10.13.1 officially ships.
Blocks: highsierra
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → NEW
Duplicate of this bug: 1407935
Duplicate of this bug: 1412308
This *appears* to be resolved by the public release of 10.13.1. Can anyone else confirm?
(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)
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)
This is resolved for me as well. Running Nightly 58.0a1 (2017-10-30) (64-bit)
This is resolved for me.  I'm running the latest Beta.
Confirmed fixed by Apple in macOS 10.13.1.
Status: NEW → RESOLVED
Closed: 2 years ago2 years ago
Flags: needinfo?(jsavage)
Resolution: --- → FIXED
(WORKSFORME is the correct resolution as nothing has been fixed in Firefox.)
Resolution: FIXED → WORKSFORME
Duplicate of this bug: 1413516
Duplicate of this bug: 1412956
Duplicate of this bug: 1416539
Duplicate of this bug: 1417801
Duplicate of this bug: 1420605
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.
Flags: needinfo?(jsavage)
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.
Flags: needinfo?(jsavage)
You need to log in before you can comment on or make changes to this bug.