Closed Bug 1403085 Opened 2 years ago Closed 4 months ago

Use native fullscreen on macOS (behind full-screen-api.macos-native-full-screen pref)

Categories

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

x86_64
macOS
enhancement

Tracking

()

RESOLVED FIXED
mozilla70
Tracking Status
firefox58 --- wontfix
firefox70 --- fixed

People

(Reporter: mgol, Assigned: xidorn)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [tpi:-])

Attachments

(1 file)

Firefox seems to be the only browser on macOS that doesn't rely on native fullscreen. It used to be useful back in the Mountain Lion days (5 years ago) when multiple displays shared spaces so going fullscreen in one of them made other screens unusable. It's not a problem since Mavericks, though, and current Firefox doesn't even support any older macOS version. This shouldn't be an issue.

Using a non-standard fullscreen breaks user expectations and leads to issues like bug 1390125.
See Also: → 1390125
Component: General → Widget: Cocoa
Product: Firefox → Core
(In reply to Michał Gołębiowski-Owczarek [:mgol] from comment #0)
> Firefox seems to be the only browser on macOS that doesn't rely on native
> fullscreen.

We fully support native fullscreen. Clicking the green titlebar button will activate native fullscreen. The fullscreen mode discussed here is an additional fullscreen mode that can be initiated from JavaScript, which is believed to yield a better user experience.

> It used to be useful back in the Mountain Lion days (5 years
> ago) when multiple displays shared spaces so going fullscreen in one of them
> made other screens unusable. It's not a problem since Mavericks, though, and
> current Firefox doesn't even support any older macOS version. This shouldn't
> be an issue.

Can you clarify what you mean by this? If you have several monitors connected and you activate native fullscreen, one screen will display fullscreen content. All other screens are black and cannot be interacted with. Are you saying there is a non-default setting to change this?

> Using a non-standard fullscreen breaks user expectations and leads to issues
> like bug 1390125.

This statement, as written, is incorrect. The user expectations in our current implementation of JS fullscreen broke because of a platform bug in macOS 10.13 that affects other applications as well.

At this time, switching to native fullscreen mode to work around an Apple bug is not believed to be the right course of action.
(In reply to Stephen A Pohl [:spohl] from comment #1)
> (In reply to Michał Gołębiowski-Owczarek [:mgol] from comment #0)
> > Firefox seems to be the only browser on macOS that doesn't rely on native
> > fullscreen.
> 
> We fully support native fullscreen. Clicking the green titlebar button will
> activate native fullscreen. The fullscreen mode discussed here is an
> additional fullscreen mode that can be initiated from JavaScript, which is
> believed to yield a better user experience.

Other browsers use native API for that kind of fullscreen as well as far as I know.

> > It used to be useful back in the Mountain Lion days (5 years
> > ago) when multiple displays shared spaces so going fullscreen in one of them
> > made other screens unusable. It's not a problem since Mavericks, though, and
> > current Firefox doesn't even support any older macOS version. This shouldn't
> > be an issue.
> 
> Can you clarify what you mean by this? If you have several monitors
> connected and you activate native fullscreen, one screen will display
> fullscreen content. All other screens are black and cannot be interacted
> with. Are you saying there is a non-default setting to change this?

This is not default behavior. By default each screen gets its own set of macOS spaces; if you go to fullscreen mode on one screen, the other screen is left unchanged.

This can be changed by going to Settings -> Mission Control and unchecking "Displays have separate spaces" but by default this option is enabled.

That's how macOS behaves by default since Mavericks which is the oldest macOS version Firefox still supports.
(In reply to Michał Gołębiowski-Owczarek [:mgol] from comment #2)
> (In reply to Stephen A Pohl [:spohl] from comment #1)
> > (In reply to Michał Gołębiowski-Owczarek [:mgol] from comment #0)
> > > Firefox seems to be the only browser on macOS that doesn't rely on native
> > > fullscreen.
> > 
> > We fully support native fullscreen. Clicking the green titlebar button will
> > activate native fullscreen. The fullscreen mode discussed here is an
> > additional fullscreen mode that can be initiated from JavaScript, which is
> > believed to yield a better user experience.
> 
> Other browsers use native API for that kind of fullscreen as well as far as
> I know.

That's correct. There may be other reasons why we've implemented this additional fullscreen mode. I'm not familiar with the history here. Markus, do you know?

> > > It used to be useful back in the Mountain Lion days (5 years
> > > ago) when multiple displays shared spaces so going fullscreen in one of them
> > > made other screens unusable. It's not a problem since Mavericks, though, and
> > > current Firefox doesn't even support any older macOS version. This shouldn't
> > > be an issue.
> > 
> > Can you clarify what you mean by this? If you have several monitors
> > connected and you activate native fullscreen, one screen will display
> > fullscreen content. All other screens are black and cannot be interacted
> > with. Are you saying there is a non-default setting to change this?
> 
> This is not default behavior. By default each screen gets its own set of
> macOS spaces; if you go to fullscreen mode on one screen, the other screen
> is left unchanged.
> 
> This can be changed by going to Settings -> Mission Control and unchecking
> "Displays have separate spaces" but by default this option is enabled.
> 
> That's how macOS behaves by default since Mavericks which is the oldest
> macOS version Firefox still supports.

Thanks for clarifying.
Flags: needinfo?(mstange)
Xidorn implemented the non-native fullscreen variant, he probably knows more about the rationale.

One issue with "naive" native fullscreen is that the transition into fullscreen mode is rather sluggish. If we want to use native fullscreen mode, I think we should implement a custom fullscreen transition using the APIs at https://developer.apple.com/documentation/appkit/nswindowdelegate?language=objc#1662326 which is a bit quicker. And in the case where you're fullscreening a video, the video should be allowed to keep playing during the transition. (The regular transition only captures two still images and tweens between them.)
Flags: needinfo?(mstange) → needinfo?(xidorn+moz)
I think the rationale is more about to have a consistent behavior among platforms. And I would support always doing native fullscreen, since the non-native fullscreen has been causing confusion and issues.

It is not entirely clear to me how should we bake the current fullscreen change flow into the native fullscreen mechanism. Probably we want to start the resize reflow with the fullscreen size immediately (it is currently start asynchronously after the screen transition to black), and do the resize animation ourselves with the API you mentioned. This is probably not that hard I guess.
Flags: needinfo?(xidorn+moz)
At least fixing Bug 1382865 would be an improvement for macOS users. Thanks in advance.
Priority: -- → P3
With bug 1390125 fixed by Apple, and with our own fullscreen implementation having some advantages over native fullscreen, there is currently no urgent need to implement a fix for this.
Priority: P3 → P5
Whiteboard: [tpi:-]
(In reply to Stephen A Pohl [:spohl] from comment #7)
> With bug 1390125 fixed by Apple, and with our own fullscreen implementation
> having some advantages over native fullscreen, there is currently no urgent
> need to implement a fix for this.

What are the advantages?

I agree it's no longer urgent, though.
(In reply to Michał Gołębiowski-Owczarek [:mgol] from comment #8)
> (In reply to Stephen A Pohl [:spohl] from comment #7)
> > With bug 1390125 fixed by Apple, and with our own fullscreen implementation
> > having some advantages over native fullscreen, there is currently no urgent
> > need to implement a fix for this.
> 
> What are the advantages?
> 
> I agree it's no longer urgent, though.

One advantage is that when "Displays have separate spaces" is disabled, only one screen will go fullscreen and the other screens can still be interacted with, instead of being blacked out. Second, the transition into fullscreen mode is currently working well and would have to be revisited if we switched to always using native fullscreen (comment 4).

Lastly, if we switch to always using native fullscreen mode, we would want to untangle our two fullscreen implementations and remove all code pertaining to the JS fullscreen mode implementation. This carries a non-negligible risk of introducing bugs and regressions. And now that bug 1390125 has been fixed by Apple, we wouldn't be fixing any open bugs by switching to always using native fullscreen mode.
Blocks: 635089
Just wanted to pitch in that in my perspective it would be a really big win if bug 635089 is fixed by implementing this.

As a returning user wanting to try out the Firefox Quantum release, I was immediately thrown by the Dock behavior when I ran a full screen video on my second screen while trying to do work on my main screen.
Note that as a workaround, you can always use the native fullscreen by having the Firefox window enter full screen mode first (click the green button or "Full screen" item in the menu), then fullscreen the video you arebwatching.
Duplicate of this bug: 1418903
Duplicate of this bug: 1456079
As the status of this bug hasn't changed, I want to chime in and "give my vote" for the macOS native fullscreen for video. I've been using the new Firefox as my default browser for some time and now mostly it is great, but the current video fullscreen implementation is rather annoying. It doesn't feel "native" to the macOS environment.

I know that one can always first make the browser fullscreen, but that isn't the same thing. And having the browser fullscreen during "everyday tasks" is annoying, because people tend to jump between applications. But while watching fullscreen video the native fullscreen just is better. If it's not clear to someone - by native fullscreen I mean basically the Chrome (on macOS) implementation.

The benefits of that implementation are:

1. Easy access to Dock while on fullscreen video:
http://www.aripalo.fi/chrome-using-native-fullscreen-on-video-dock.png

2. Easy access to Menubar while on fullscreen video:
http://www.aripalo.fi/chrome-using-native-fullscreen-on-video-menubar.png

3. Easy access to Spaces while on fullscreen video:
http://www.aripalo.fi/chrome-using-native-fullscreen-on-video-spaces.png

4. Easy access back to non-fullscreen browser just by pressing ESC, instead of having to first press ESC and then to click the green button to make Firefox exit fullscreen mode.
I would also like to give my vote for this feature. I like Firefox much but so far it still behaves like an "outsider" in macOS. Hopefully this feature will be supported soon.
Duplicate of this bug: 1502737
Duplicate of this bug: 1519602

Like many of the firefox implementations, the fullscreen video doesn't feel the "native" macOS experience.
I don't think that Firefox's fullscreen implementation have any advantages to end-users (It might have an advantage on the code base but I, as a user, don't care about it).
Whenever I want fullscreen a video I move firefox window to another desktop then fullscreen the video because it hides other applications.

I'll have a look at this maybe this weekend.

Flags: needinfo?(xidorn+moz)
Assignee: nobody → xidorn+moz

(In reply to degirmencisercan from comment #20)

Like many of the firefox implementations, the fullscreen video doesn't feel the "native" macOS experience.
I don't think that Firefox's fullscreen implementation have any advantages to end-users (It might have an advantage on the code base but I, as a user, don't care about it).
Whenever I want fullscreen a video I move firefox window to another desktop then fullscreen the video because it hides other applications.

+1000.

My only two issues with Firefox (though admittedly I'm running macOS Catalina Beta 2) are that fullscreen works much better on Chromium browsers (I can access the dock and menu bar because the fullscreen is native) and that the Widevine plugin doesn't seem to work, though that may be more of a macOS Beta than Firefox bug.

I switched to Firefox because I heard Google plans to end ad-blocking soon, and I think a lot of people will be switching to Firefox if/once it actually happens. Please, please implement native fullscreen for videos, because it really adds more to the user experience than it seems. Being able to swipe between fullscreen videos and other "spaces" in macOS is indispensable to me, and in Chromium browsers I can do things like hover near the top of the screen and check my battery percentage in the menu bar. That is so useful to me, and I'm sure to many others!

I understand that a lot of work has been done to get Firefox's current fullscreen to work, but I truly do think that the Firefox experience on macOS, especially on MacBooks/Airs/Pros, would be significantly better if the team could get native macOS fullscreen to work.

Thank you!

Can someone try https://queue.taskcluster.net/v1/task/HGeVgSQuQkKaUkner88_OA/runs/0/artifacts/public/build/target.dmg with full-screen-api.native-full-screen set to true in about:config and report if this feels better?

Flags: needinfo?(xidorn+moz)

(In reply to Xidorn Quan [:xidorn] UTC+10 from comment #24)

Can someone try https://queue.taskcluster.net/v1/task/HGeVgSQuQkKaUkner88_OA/runs/0/artifacts/public/build/target.dmg with full-screen-api.native-full-screen set to true in about:config and report if this feels better?

If you have mozregression installed, you can just run:

mozregression --repo try --launch 4dab5f4a6f9c --pref "full-screen-api.native-full-screen:true"

(In reply to Xidorn Quan [:xidorn] UTC+10 from comment #24)

Can someone try https://queue.taskcluster.net/v1/task/HGeVgSQuQkKaUkner88_OA/runs/0/artifacts/public/build/target.dmg with full-screen-api.native-full-screen set to true in about:config and report if this feels better?

I went ahead and tried this just now. It certainly addresses things like leaving the Dock visible and making the menu bar easier to access, but the transition is very clunky (this was mentioned in comment 4). I like the idea of putting this behind a pref. We will need to work on the transition before we could turn this on by default.

I did a brief, very limited test just now and found that unlike Safari, the originating window disappears once the video is full-screened. This would be something to improve, because as it is, a user can't browse other tabs in the originating windows like they can in Safari.

Chromium seems to do it the way screen-api.native-full-screen now does it, though.

Using other windows with a full screened video seems to work as expected, though.

(In reply to Asif Youssuff from comment #28)

I did a brief, very limited test just now and found that unlike Safari, the originating window disappears once the video is full-screened. This would be something to improve, because as it is, a user can't browse other tabs in the originating windows like they can in Safari.

That's true. I agree that Safari's behavior here is the best, but that could add quite a bit of complexity to the implementation. I believe it's feasible, but it would be much more involved than what I'm able to do at the moment.

I'm going to file a new bug for improving the behavior, but I can't promise to get to it any time soon. What I'm trying to do here is to get some low-hanging fruit done, so that people can opt-in to a behavior they may prefer before we can come up with the perfect one.

Blocks: 1563947
Blocks: 1209831

(In reply to Xidorn Quan [:xidorn] UTC+10 from comment #29)

(In reply to Asif Youssuff from comment #28)

I did a brief, very limited test just now and found that unlike Safari, the originating window disappears once the video is full-screened. This would be something to improve, because as it is, a user can't browse other tabs in the originating windows like they can in Safari.

That's true. I agree that Safari's behavior here is the best, but that could add quite a bit of complexity to the implementation. I believe it's feasible, but it would be much more involved than what I'm able to do at the moment.

I'm going to file a new bug for improving the behavior, but I can't promise to get to it any time soon. What I'm trying to do here is to get some low-hanging fruit done, so that people can opt-in to a behavior they may prefer before we can come up with the perfect one.

What you have done is more than good enough. As far as I can see, the transition is identical to what chromium-based browsers do. I've gotten used to the rough look of the transition and don't even notice it anymore.

Thank you SO much! I'm so happy to have the menu bar and dock back. I can't thank you enough. It's truly the small things like this that make all the difference!

Dao, mind having a look at the frontend part of the patch?

Flags: needinfo?(dao+bmo)

Probably because I didn't put :dao a blocking reviewer. Remove ni? for now.

Flags: needinfo?(dao+bmo)
Pushed by mozilla@upsuper.org:
https://hg.mozilla.org/integration/autoland/rev/1e97db05c806
Add a pref to use native full screen for Fullscreen API on macOS. r=spohl,dao
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70
Summary: Use native fullscreen on macOS → Use native fullscreen on macOS (behind full-screen-api.macos-native-full-screen pref)
Duplicate of this bug: 1569844
Duplicate of this bug: 1571431
QA Whiteboard: [qa-70b-p2]
You need to log in before you can comment on or make changes to this bug.