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

Resizing problems of the container when calling mozRequestFullScreen() #161

Open
TRMSC opened this issue Dec 15, 2023 · 5 comments
Open

Comments

@TRMSC
Copy link

TRMSC commented Dec 15, 2023

There seems to be kinds of bugs in connection with the fullscreen mode when using firefox - tested within its version 120.0, different content types and several hosts: The H5P Container is not being resized properly when joining and after leaving the fullscreen mode or it doesn't start as well...

The Inspector shows for e.g. this example or this one the following note:
"mozRequestFullScreen() should no longer be used." by pointing this line within the h5p.js.

Starting the fullscreen mode for a second time isn't possible at all by throwing this error:
"Uncaught (in promise) TypeError: Not in fullscreen mode" in this line.

Does anyone have ideas how to fix this or am I wrong in any way?

Thanks for your help and for all of your work!

@otacke
Copy link
Contributor

otacke commented Dec 15, 2023

That's just a "deprecation" message, but not an error. Firefox is telling you that the extra handling for Firefox (using mozRequestFullScreen) when requesting to go to full screen is not required anymore. One can now use the regular requestFullscreen in Firefox as well. https://developer.mozilla.org/en-US/docs/Web/API/Fullscreen_API/Guide#prefixing At some point, Mozilla will probably remove mozRequestFullScreen completely and then there's an issue, but for now Firefox will "forward" the call.

So, that's not an explanation for an issue, and I could not detect any trouble when using Firefox 120.0 on the pages that you linked to - that's exclusive to Firefox.

The H5P container does not resize, because the ZUM page sets a fixed width on the H5P iframe (via some "fluid_iframe" hook).

@TRMSC
Copy link
Author

TRMSC commented Dec 16, 2023

Thanks for your feedback @otacke!

It's interesting that this seems not to be the problem but it doesn't seem to be on the ZUM page as well I think, because the same behavior persists trying e.g. the game map example on h5p.org.

I don't know why then this problem occurs, but maybe someone has the same behavior? Other fullscreen stuff on firefox is working well for me without these issues...

@otacke
Copy link
Contributor

otacke commented Dec 16, 2023

@TRMSC As mentioned, I cannot detect any issue with Firefox with resizing, having gone to full screen or not. I have shared a screen recording.

First, you'll see the Drag and Drop content on the ZUM page which is in fact not resizing properly, but regardless of the browser. Please note the iframe setup which has a fixed width that it received from the "fluid_iframe". I cannot detect any issues with entering and exiting the full screen mode multiple times, however.

Then you'll see the game map example on h5p.org which I resized before and after going to full screen multiple times. I am not sure what the issue is supposed to be.

I am not saying the legacy code shouldn't be removed, but it would still be nice if one could reproduce what you're experiencing.

@TRMSC
Copy link
Author

TRMSC commented Dec 20, 2023

Thank you for your thougts and words as well as for your screen recording which is very helpful for the limitation.

With these backgrounds I am also convinced that the problem is on firefox side espacially in some case related to x11 or the snap package on linux or similar. So I think for now, this will be solved automatically in form of the next browser (or system) updates. I will continue monitoring this and it would be interesting what other users will notice about this.

I'm glad that my issue was an impulse for #162 and thank you that you got this started as well as for all of your help! 😊

Even if the issue persists for me, I think we can close #161? 👍

@otacke
Copy link
Contributor

otacke commented Dec 20, 2023

@TRMSC Hmm, snap packages should not change any functionality within the Firefox libraries, it's essentially a container of dependencies. Could still be some problems with the latter though. I think the latest stable version that snap uses is 1.21.0, so you could try to update or test a flatpak version.

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

No branches or pull requests

2 participants