Listening for full screen event? Or remapping shortcut key?

Due to how we are embedding the iframe in our app, the “s” key currently used (as well as the menu item) for putting Jitsi in full screen is impacting our ability to overlay our own UI.

We aren’t modifying Jitsi in any way; we are implementing a UI overlay which works fine in browser fullscreen mode (using F11, for example, or the native document.body.requestFullscreen()), however the ‘s’ button or menu item “Fullscreen” in Jitsi seems to be using the video element to make itself full screen.

Based on issues I’ve read on your GitHub it seems like this was a work-around, rather than an intended functionality. It might even make sense if Jitsi were embedded within a web page, however I need to override this functionality to make the shortcut and the menu item respond by issuing document.body.requestFullscreen() instead.

How do I listen for this event? I can’t seem to add an event listener specifically for this.

To be clear: I can add an event listener to the “s” keydown event; I need to know how to override your event listener.

I’m having same issue, did you find any solution for this?

No, but they are using the video element and requesting the full screen on this, which is the problem.

When you do this, the result is the video element takes over the entire page and overlays everything.

The same thing could be achieved using the method I asked about; this seems like a bad implementation on Jitsi’s part. I realize they are using a video element to display the call window, but using the body element would solve a lot of issues - it makes it possible to wrap their element, for example.

I may try a work around hack of redefining the “s” key behavior after waiting for the iframe to load, then reassigning a new event listener.

It’s hacky because the original event listener is still there, but it might work.

For the record, the solution I used was using the proper full screen API (again, Jitsi incorrectly uses the video full screen which is intended for an embedded video only - it actually assumes the video element is the only thing you want to interact with which has the side-effect of eliminating any overlaid UI elements), <element>.requestFullscreen() - this returns a promise, FYI.

I added a fullscreen button overlaid on the iframe, then in my Jitsi config removed their fullscreen option from the default menu. I didn’t bother hunting down where they add the event listener, because it’s not clear which if the many potential elements have this, but it’s probably the video element. Unfortunately, to kill that event listener, you’d have to also listen for it to be rendered first, assuming you’re using the iframe API; that makes it a huge PITA.

On the plus side, basically no one assumes the “s” key is going to be a full screen button, and it’s unlikely they’d just randomly hit “s” on a video conference.

If you felt like digging through their code, which seems to be what they refer to as “documentation” you could probably find the event listener definition and redefine that variable to null; assuming it’s associated with a variable.

I haven’t tried this as my problem is solved, but alternatively you could do something like this:

let iframe = document.querySelector('iframe');
iframe.addEventListener('keydown', (event) => {
  if (event.keyCode === 115) event.stopPropagation();
}, true);

iframe.addEventListener('keypress', (event) => {
  if (event.keyCode === 115) event.stopPropagation();
}, true);

That will kill all “s” key events, probably; or you could leave out the if check and just kill all keyboard events wholesale and then rewrite them as you please.

js “s” keyCode is not 83 ?

Here’s a solution i found…

var videoElement = document.getElementById(“meet”);

          if (!document.mozFullScreen && !document.webkitFullScreen)
            if (videoElement.mozRequestFullScreen) {

            } else {

          } else {

            if (document.mozCancelFullScreen) {
            } else {