Full screen problems

[dreamlayers]

Full screen mode can be initiated externally from the shell via Module.requestFullScreen(), bypassing SDL, or via SDL functions.

Externally initiated full screen mode is close to working properly:

• If drawing to a surface (not using a renderer), and not pre-loading any files, then Browser.init() is not called. This causes the display to not be scaled up when entering full screen mode, with TypeError: canvas.requestPointerLock is not a function exception in the console. That exception happens because that variable was supposed to be set via Browser.init(). (Edit: Created "Fullscreen" button fails in Firefox when not using WebGL and not preloading files #15 for this particular issue)
• It is impossible to enter full screen mode in Firefox 35 now since 9d4beb2. More info at the #7 pull request. (Edit: Should be fixed now, since merging Fix full screen mode in Firefox, which was broken by 9d4beb2 #13)

SDL-initiated full screen mode has more serious issues:

• SDL_WINDOW_FULLSCREEN_DESKTOP causes resize events to 300x150 followed by the requested size if it differs from 300x150. That's the CSS size that Emscripten_VideoInit() reports as the desktop display mode. Shouldn't it be reporting the true desktop resolution?
• DOSBox uses SDL_GetDisplayBounds(), which also reports 300x150 from the reported desktop mode via SDL_AddBasicVideoDisplay().
• Emscripten_SetWindowFullscreen() unsets the full screen flags, which causes the SDL_UpdateFullscreenMode() call at the end of SDL_CreateWindow() to leave full screen mode.
• The HTML5 library method used by SDL is incompatible with the browser library method used by the shell. Using both causes problems. Using the browser library method first and then using the HTML5 library method destroys the web page, leaving just the canvas. (Edit: Reported at: After using the Fullscreen button, HTML5 library full screen functions fail emscripten-core/emscripten#3283)
• The Em-DOSBox display sometimes disappears during the first switch to or from full screen mode. This is fixed by later switches and doesn't repeat.

[Daft-Freak]

This should fix the first two SDL fullscreen issues: https://github.com/emscripten-ports/SDL2/compare/desktop_resolution

[Daft-Freak]

Fullscreening in CreateWindow doesn't work as it isn't called from an event handler. The unsetting of the flags prevents SDL from thinking it's fullscreen when it isn't.

[dreamlayers]

Yes, https://github.com/emscripten-ports/SDL2/compare/desktop_resolution fixes the first two SDL fullscreen issues.

DOSBox assumes that fullscreen status only changes when it explicitly changes that. I don't know if DOSBox is wrong in assuming that or if SDL video drivers aren't supposed to change full screen status by themselves. SDL temporarily falsely assuming it is in full screen before an event truly allows full screen seems better than the application falsely assuming it is in full screen indefinitely.

[Daft-Freak]

I've updated that branch to only clear the flags if fullscreen isn't possible. I also seem to be hitting the issue you mentioned in #7 in the SDL fullscreen case.

[juj]

There are multiple issues being reported here, @dreamlayers, if you can help build up failing tests for these (or post separate bugs with STR steps) and separate these to ones that are clear bugs that we should fix, and the ones that need more discussion e.g. due to not accounting a specific use case, that would be helpful for picking up fixes.

[AlexanderKotliar]

The test should use SDL and be iterative (set emscripten_set_main_loop), sdl2_gl_frames_swap.c from Emscripten tests shows this problem: when Fullscreen buttom is pressed there is a black screen. As I can see, Emscripten_HandleFullscreenChange was significantly changed compared to worked version.

[Daft-Freak]

This a very old issue, most of the points listed are fixed. You're probably having another issue. (Though if you're using the generated fullscreen button, that's expected to be a bit broken.)

[AlexanderKotliar]

Yes, I mean generated fullscreen button from standart html output.

[Daft-Freak]

The problem is that the fullscreen button uses the old Browser.requestFullscreen API and SDL uses the newer emscripten_request_fullscreen_strategy API. As mentioned in this issue, using the first API breaks the second. (emscripten-core/emscripten#3283)

Also, now that we use emscripten_set_canvas_element_size instead of emscripten_set_canvas_size, the old Browser.setCanvasSize never gets called which results in Browser.requestFullscreensetting the canvas size to 0.

[kripken]

I wasn't aware of that inconsistency. Can we make the button use the new API, or is there a problem with that?

[Daft-Freak]

Hmm, doing that was mentioned in emscripten-core/emscripten#3283. The fact that SDL2 uses the resize callback from emscripten_request_fullscreen_strategy may be a problem.

[kripken]

Thanks @Daft-Freak, I'll comment there.

[eduardodoria]

I have described a similar situation emscripten-core/emscripten#8590

[tuket]

By default SDL2 captures all input so the browser doesn't handle pressing F11 to enter fullscreen mode.
Calling emscripten_request_fullscreen from the SDL the event loop doesn't work because

This function can be called anywhere, but for web security reasons its associated request can only be raised inside the event handler for a user-generated event (for example a key, mouse or touch press/release).

So when digging the SDL2 code I found that when an event gets pushed to the queue, the watcher callbacks get called. That is useful for the following workaround:

SDL_AddEventWatch([](void*, SDL_Event* event) -> int{
    if((event->type == SDL_KEYDOWN || event->type == SDL_KEYUP) && event->key.keysym.sym == SDLK_F11) {
        emscripten_request_fullscreen(0, 0);
        printf("F11 watch\n");
    }
    return 1;
}, 0);

However, I don't understand why it doesn't work if I pass the id of the canvas as the first parameter (documentation). I have to pass null.

// none of these two seem to work
emscripten_request_fullscreen("canvas", 0);
emscripten_request_fullscreen("#canvas", 0);

Even though it works both in Firefox and Chrome, I get an error in the console:

[jrynkiew]

I remember having a similar problem, and I think the reason is that the behaviour of emscripten has changed, specifically how it handles identifying the canvas object. I remember playing around with -s DISABLE_DEPRECATED_FIND_EVENT_TARGET_BEHAVIOR=0 compilation flag. I think that helped, but then I gave up on that method too.