This might be an iOS or device specific bug, as it does not reproduce on Safari for macOS and the iPhone doesn't support full screen for div elements, where the iPad does. Would be interesting to see if the same replicates in stock video.js playback at https://videojs.com

It is only reproducing on iPadOS while it does not reproduce on Chrome 134 on Android Tablet S9 FE.

@bvibber do you have a newer iPad lying around ? My iPad only supports the old codecs, and looking at the screenshot, I suspect this is a newer device using VP9.

Most likely cause is still a Safari implementation bug of course as this works everywhere else. My guess is that the device's hardware render layer is not resizing properly, when the div enters fullscreen mode.

Confirmed I'm seeing the same failure to fully expand on my iPad Pro 11inch 2nd generation (which does grok WebM/VP9) running iPadOS 18.4, and it's definitely using the native player inside video.js (I can see the picture-in-picture works for instance). Not quite sure what's going on there but I can probably try to debug it when I have a chance. I'll pack the iPad with me on my work trip next week and see what I can do. :D

(Could be a CSS wonkyness on our end, could be a browser bug with fullscreen. We'll see!)

From WebKit side - happy to pass it to Media team (if it is something needs to be fixed on WebKit end). If you can isolate test case, please file it on bugs.webkit.org. :-)

I can reproduce it in the iPad simulator which'll simplify debugging. :) (In simulator it plays the MJPEG super-low-res .mov but it behaves the same as it's a native player) Nothing obvious in styles that should be interfering so far as I know, but could still be something i didn't catch.

The requestFullscreen call happens inside video.js, I'll have to dive a little closer and see what it's actually calling it and confirm if anything weird's going on.

Occasionally it comes out at an intermediate size, also. Had it happen a couple of times on a standalone page with just video.js and none of our own CSS or HTML, other times it loads fine. Could be timing-related with the resizing maybe? Will poke it again later...

quickie screenshot of the partially isolated test showing the sizing failure; the <video> element thinks it's big but the actual layer is quite small in the rectangle:

I suspect this may be a css/internal sizing issue after all, will try to create a standalone test case later this week.

@bvibber - Thanks for your help. Once again, if you have standalone test, let me know. I will escalate it internally to Media or Layout team to get this fixed.

You are happy to reach out for other Safari / WebKit issues and CC myself. Happy to look into them as well.

@bvibber - Any update?

No, no update on our end. Seems to be something related to Video.js and/or our styles but I don't know what. Have you had any luck on your end?

(It sounds like perhaps you were saying that you *would* escalate *if* we provided a minimal test case, in which case perhaps you haven't escalated it and we've been both waiting on each other. :) )

Hi Team, this is something still happening on iPadOS 26 - if. you can provide minimal test case - I am happy to tackle it internally with WebKit Media team to get some traction on it. Thanks!

Thanks, I'll make another stab at reducing the test case!

In T390256#10970406, @SafariBrowserTest wrote:

Hi Team, this is something still happening on iPadOS 26 - if. you can provide minimal test case - I am happy to tackle it internally with WebKit Media team to get some traction on it. Thanks!

After some poking I think I've narrowed it down to being a problem with having a non-video element (the VideoJS UI div) call requestFullscreen when there's a non-default <meta viewport> set. If I remove that I see a correctly-laid out full screen view, but the page is narrower than we want it on the iPad.

Repo with self-contained .html file repro'ing bug:
https://github.com/bvibber/ipad-video-fullscreen-bug

Let me know if you need anything more from our end!

To document, this is triggered by, our iPad hack in our ready script where we do.

function fixViewportForTabletDevices() {
    const $viewport = $('meta[name=viewport]');
    const content = $viewport.attr('content');
    const scale = window.outerWidth / window.innerWidth;
    if (window.innerWidth >= 640 && window.innerWidth < 1120 && content && !content.includes('initial-scale')) {
        $viewport.attr('content', 'width=1120,initial-scale=' + scale);
    }
}

Not sure if Apple ever followed up on this

@TheDJ Do you remember which issues triggered this fixViewportForTabletDevices()? I could double check on the side of WebKit.

In T390256#11648947, @WebcompatApple wrote:

@TheDJ Do you remember which issues triggered this fixViewportForTabletDevices()? I could double check on the side of WebKit.

The reason for that code, was that we wanted a different width than device width (so that iPad would get the desktop layout of our skin). But that triggered some weird problem with font scaling when set via the viewport tag on initial page delivery, so instead we did it with JavaScript. There is a history about this in T311795

note that this is tracked at Apple by radar 146928696

I'm still trying to figure out what is the best path.

<meta name="viewport" content="width=1120">
setting an explicit viewport width completely messes with the layout when the viewport is resized to a value that doesn’t match.
Setting this tag’s content= to ”” (i.e., empty) with the web inspector completely fixes the bug.

Would it be possible to either not set the viewport or to change the value on resize.