Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document fullscreening vs. modal dialog #227

Open
xiaochengh opened this issue Jul 13, 2023 · 6 comments
Open

Document fullscreening vs. modal dialog #227

xiaochengh opened this issue Jul 13, 2023 · 6 comments

Comments

@xiaochengh
Copy link

(Originally filed as a Chrome bug)

What should happen if we:

  1. Show a modal dialog
  2. Run document.documentElement.requestFullscreen() (by e.g. clicking a button in the dialog)

Live test case: https://fullscreen-demo.viggers.net/

If I read the spec correctly, this should bring the documentElement into the top layer, which is then rendered over the modal dialog. And since the rest of the page is currently inert, the page is unusable until we exit fullscreen.

This is the current behavior observed in Chrome, which doesn't seem to be a desirable behavior however. It means we can't fullscreen the page when a modal dialog is open.

Firefox simply fullscreens the page while keeping the modal dialog at the front.


Proposal: Can we make it a special case when running requestFullscreen() on documentElement, so that it simply fullscreens the page without interacting with the top layer? I suppose its main purpose is to fullscreen the entire document, and we don't want anything that's already top-layer to be covered.

Also as a side note, if we call document.body.requestFullscreen(), all browsers move the document body to the top layer and cover the modal dialog. So this really is just a special case with documentElement, and we don't need to worry about any other DOM ancestor of the dialog.

@annevk
Copy link
Member

annevk commented Jul 23, 2023

Why isn't it desirable for the root element, but acceptable for other ancestors, such as the body element? I think I'd rather not add a special case and if people want an API for fullscreening a document we'd add a dedicated one.

cc @nt1m @emilio

@nt1m
Copy link
Member

nt1m commented Jul 23, 2023

Safari's behavior matches Chrome per spec fwiw. Only Firefox special cases the root.

I don't feel super strongly either way.

A special case would only work for the root fwiw, since anything else in the document pushed in the top layer can potentially be overlaid by other things in the document. That is not the case for the root however, since it contains all the elements in the page.

@zadeviggers
Copy link

The Chrome team say they're waiting on consensus in this thread before they proceed.

As a web application developer using the dialog element and the fullscreen API together in production, it would be nice to have consistent behavior across browsers sooner rather than later, which means the standard needs to be clear.

I feel like the current Firefox behavior, special-casing documentElement makes more sense from a web developer point of view, but that's just my opinion - I don't mind either way as long it's consistent across browsers.

Cheers,
Zade

@xiaochengh
Copy link
Author

Not a strong opinion, but I'm leaning not to add a new API if its only use case is to fullscreen the full page while something is already in the top layer.

@foolip
Copy link
Member

foolip commented Nov 30, 2023

How is the special case implemented in Firefox? Is it to skip step 4 of https://fullscreen.spec.whatwg.org/#fullscreen-an-element?

@emilio
Copy link

emilio commented Nov 30, 2023

I think the special-case is just here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

6 participants