Fullscreen Detection broken

[netAction]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Affects: HTML5 export.

Both fullscreen detection and fullscreen switch methods are broken when the user leaves fullscreen on Chrome/Windows via Esc key or on Chrome/Android via < button or on Safari/IOs via swipe down.

After executing the Activate fullscreen action, GDevelop thinks it is in fullscreen. Even if it is not, because fullscreen has been left manually. Then running Activate fullscreen again might crash. And worse, the condition The game is in fullscreen says true but it is not.

The Javascript code if (document.fullscreenElement != null) returns the correct value on all three browsers, no matter if the fullscreen has been closed via Activate fullscreen action or via the intended browser way.

Minimal project for reproduction:

Steps to reproduce

1. Create a button and bind Activate fullscreen on click.
2. Leave Fullscreen in the way your browser suggests.
3. Check The game is in fullscreen or use the Activate fullscreen action again. Both don't work correctly.
4. Check if (document.fullscreenElement != null). It does work.

GDevelop platform

Desktop

GDevelop version

5.3.195

Platform info

IDE: GDevelop via Microsoft Store on Windows 11

Browser: Chrome/Windows, Chrome/Android, Safari/IOs

Additional context

No response

[ClementPasteau]

Hi @netAction does this happen when you publish on gd.games too?
If so, can you share a link so we can see the problem in action?
Thanks

[netAction]

Yes the bug is reproducable in gd.games. https://gd.games/netaction/fullscreen-bug

[ClementPasteau]

Thanks, that's very helpful and detailed, we're probably missing an event not being listened properly or using a wrong logic

[ClementPasteau]

This is the function being used in the runtime to set the full screen (it's quite old), saving the variable in the state.

GDevelop/GDJS/Runtime/pixi-renderers/runtimegame-pixi-renderer.ts

Lines 390 to 446 in 5c66623

	setFullScreen(enable): void {
	if (this._forceFullscreen) {
	return;
	}
	if (this._isFullscreen !== enable) {
	this._isFullscreen = !!enable;
	const remote = this.getElectronRemote();
	if (remote) {
	// Use Electron BrowserWindow API
	const browserWindow = remote.getCurrentWindow();
	if (browserWindow) {
	browserWindow.setFullScreen(this._isFullscreen);
	}
	} else {
	// Use HTML5 Fullscreen API
	//TODO: Do this on a user gesture, otherwise most browsers won't activate fullscreen
	if (this._isFullscreen) {
	// @ts-ignore
	if (document.documentElement.requestFullscreen) {
	// @ts-ignore
	document.documentElement.requestFullscreen();
	} else {
	// @ts-ignore
	if (document.documentElement.mozRequestFullScreen) {
	// @ts-ignore
	document.documentElement.mozRequestFullScreen();
	} else {
	// @ts-ignore
	if (document.documentElement.webkitRequestFullScreen) {
	// @ts-ignore
	document.documentElement.webkitRequestFullScreen();
	}
	}
	}
	} else {
	// @ts-ignore
	if (document.exitFullscreen) {
	// @ts-ignore
	document.exitFullscreen();
	} else {
	// @ts-ignore
	if (document.mozCancelFullScreen) {
	// @ts-ignore
	document.mozCancelFullScreen();
	} else {
	// @ts-ignore
	if (document.webkitCancelFullScreen) {
	// @ts-ignore
	document.webkitCancelFullScreen();
	}
	}
	}
	}
	}
	this._resizeCanvas();
	}
	}

There are indeed no listeners on wether the full screen has been left.
We could try adding a listener on https://developer.mozilla.org/en-US/docs/Web/API/Element/fullscreenchange_event in this method to see if it catches it or not

[necaTecnico]

@ClementPasteau @netAction Hi, I am a university student and would like to solve the #2162 bug for a university project. This bug mentioned seems to be the same as the one here (#6477). I have been looking at the code and trying to do all the suggestions mentioned in the other issue as well as this one. but nothing really worked. Anyone got any recommendations or help please? I didn't really understand the proposed solution as well as this workaround, as I didn't get where in the code to place these snippets.

[ClementPasteau]

Hi @necaTecnico thanks for willing to contribute.
Can you open a PR of what you tried to implement?
This will help having a base for discussing this.

As mentioned in the issues, the file runtimegame-pixi-renderer needs to be adapted to create event listeners when mounted, that change the boolean _isFullscreen depending on wether fullscreen is entered or left

[necaTecnico]

@ClementPasteau Ok, but let me just check with my professor if we can open PRs before being reviewed by him first. Thanks a lot for the quick reach out. I will get back to you.

But just one question, this issue looks the same to me as this one (#2162) right? Because I actually chose this linked bug here to solve first, but then I found this one too which looks to be the same problem.

[necaTecnico]

Hi @ClementPasteau, here is what I have changed in this file so far, following your recommendations and other in this issue and in #2162, however it is still not working.... also I cannot see logs when I do them. Any recommendations on what I have done, and also, is there any specific way required to compile the code after changing it that I need to do before npm start?

PS: Sorry I can't open a PR before having the solution for the bug because of the project's evaluation my teacher has set. So here is the file converted to txt.

runtimegame-pixi-renderer.txt

[ClementPasteau]

Hi @necaTecnico, I want to help, though it's really not efficient like this.
Github branches and PRs are made for this kind of back and forth discussions, so we can give you feedback and iterate. This is how it works in the open source world :)
Unless you have a PR opened, I will not be able to help you. (Try convincing your teacher!)

[necaTecnico]

Hey @ClementPasteau, I have opened a pull request related to this issue. It's currently awaiting review and approval. Please take a look when possible, so we can discuss further. Thank you!

[necaTecnico]

Hi @ClementPasteau, just looping back here following our earlier exchange where you suggested opening a PR for proper discussion.

I've since opened PR #7538 with a proposed fix and some testing groundwork. While the solution doesn't fully resolve the issue across all browsers, I wanted to share it as a concrete basis for discussion and iteration.

Would appreciate your thoughts whenever you get a chance — especially to understand if I'm on the right track or if you'd approach this differently.

Thanks again!
@necaTecnico