Created attachment 459556 [details] Screen recording of video jumping in size due to object-fit: cover When playing a video with object-fit: cover on Webkit (iOS 15.5, reproduced on Chrome & Safari) the first frame of the video gets shown with object-fit: contain (more zoomed out) and then the rest of the video plays with the proper object-fit (zoomed in, correct size). This results in a very visible jump in size of any video with the object-fit: cover CSS rule. Can be reproduced with a minimal example: https://codepen.io/mszylkowski/pen/eYVWBWL (video attached)
<rdar://problem/93606969>
*** Bug 240786 has been marked as a duplicate of this bug. ***
The bug seems to affect object-fit cover and contain the same, as seen on the front page of Reddit. (See attachment on the duplicate bug https://bugs.webkit.org/show_bug.cgi?id=240786)
Created attachment 460100 [details] screen recording from nytimes.com This bug is causing issues all over the web, from webpages like reddit to nytimes.com. Attaching a video of the issue on a nytimes article.
*** Bug 241789 has been marked as a duplicate of this bug. ***
Created attachment 461192 [details] Screen recording of issue on front page of nytimes.com
Any progress on this bug?
Another example website where the effect is visible: https://www.by-us.studio/dc-open-21 It might be that it's only visible on slower devices. I see the video starting with a small 100% width crop before it fills the screen on a iPhone SE (1st Gen).
> It might be that it's only visible on slower devices. It happens both on my iPhone 11 Pro _and_ my MacBook Pro M1 Max.
I am able to reproduce this on macOS 12.6 using Safari 16 and STP 154, hence changing title to reflect that it is not iOS only issue but also present wherever object-fit: cover is used. I reproduced it using URL in Comment 08, where Safari show zoomed-out frame before showing full frame, which is not the case in Chrome Canary 108 and Firefox Nightly 107. Thanks!
It might be something to do here: https://github.com/WebKit/WebKit/blob/3afb34f466db6634ec6b7cea95b9cf6a735b43af/Source/WebCore/rendering/RenderReplaced.cpp#L447
I am also seeing this bug on MacOS 12.6, latest Safari versions. I was able to reproduce this with both "cover" and "none", but NOT with "fill". That makes me think the use of finalRect.setSize in Ahmad Saleem's link is relevant, but I'm not sure to what extent. I also noticed that, for me, this issue only seems to affect the video the first time it is played, and does not affect subsequent playbacks, even upon page refresh.
Could it be related to this line? https://github.com/WebKit/WebKit/blob/3afb34f466db6634ec6b7cea95b9cf6a735b43af/Source/WebKit/WebProcess/GPU/media/MediaPlayerPrivateRemote.cpp#L164 It seems to set up the video layer with the elements size, and not the replaced content rect. This was changed to fix https://bugs.webkit.org/show_bug.cgi?id=226960, and this new bug appeared around the same time. Changelog: https://bugs.webkit.org/attachment.cgi?id=454771&action=diff
It seems the line has been changed in a recent PR: https://github.com/WebKit/WebKit/pull/5405/files Could this have fixed the bug?
(In reply to Johannes Odland from comment #14) > It seems the line has been changed in a recent PR: > https://github.com/WebKit/WebKit/pull/5405/files > > Could this have fixed the bug? It might or could have but someone need to confirm from Webkit ToT (Top of Tree) build with this patch to confirm whether this bug is fixed or not. Or wait till this patch is part of Safari Technology Preview 157 or 158.
(In reply to Johannes Odland from comment #14) > It seems the line has been changed in a recent PR: > https://github.com/WebKit/WebKit/pull/5405/files > > Could this have fixed the bug? The issue connected to the PR is available here: https://bugs.webkit.org/show_bug.cgi?id=246552
Issue seems to be fixed in Safari TP 158 on macOS.
(In reply to Johannes Odland from comment #17) > Issue seems to be fixed in Safari TP 158 on macOS. Good to know. I will mark it as duplicate of other bug. Please reopen, if it is still reproducible. *** This bug has been marked as a duplicate of bug 246552 ***