-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Resizing a fullscreen element doesn't always resize children to the correct size #15611
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
EWS run on previous version of this PR (hash a3fc609)
|
a3fc609
to
9ee1cd1
Compare
EWS run on previous version of this PR (hash 9ee1cd1)
|
9ee1cd1
to
64c7e94
Compare
EWS run on previous version of this PR (hash 64c7e94)
|
64c7e94
to
47cbbb4
Compare
EWS run on previous version of this PR (hash 47cbbb4)
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: "VideoFullscreen" is used more commonly used than "FullscreenVideo", so maybe inFullscreenElementOrVideoFullscreen
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good, I'll change that.
47cbbb4
to
632a6a3
Compare
EWS run on current version of this PR (hash 632a6a3)
|
EWS run on previous version of this PR (hash 632a6a3)
|
Source/WebCore/dom/Document.cpp
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems odd that stye resolves needs to know anything about fullscreen. Why doesn't window resize have the same issue? I think we should debug further.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can also fix this by calling scheduleFullStyleRebuild
in a few places but it is a slightly larger change. Do you think that would be reasonable? I can try that instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fwiw, full style rebuilds were originally there because we had the UA styles matching the :-webkit-full-screen-ancestor
pseudo class requiring all the ancestors of the fullscreen element to have their styles recomputed.
It is in theory no longer required with the new fullscreen API (for which I did remove full style rebuilds in some places but not all). The remaining ones avoid dirty renderer assertions when pushing to top layer (which we should arguably fix and then remove the full style rebuilds).
Adding more full style rebuilds isn't really the answer here. Fine grained PseudoClassChangeInvalidation should do its job here.
632a6a3
to
55b4e24
Compare
EWS run on previous version of this PR (hash 55b4e24)
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes in RenderVideo.h/cpp are to fix the same issue 265672@main fixed but for video playing in a fullscreen element.
They can be broken out into a separate patch if preferred, the issues are independent.
55b4e24
to
e6712a1
Compare
EWS run on previous version of this PR (hash e6712a1)
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might not be sufficient. Layout is generally but not always occurring after a full style rebuild.
Maybe I want layoutContext().layout();
instead?
e6712a1
to
099af89
Compare
EWS run on previous version of this PR (hash 099af89)
|
099af89
to
3904a6b
Compare
EWS run on previous version of this PR (hash 3904a6b)
|
3904a6b
to
3e94b6d
Compare
EWS run on current version of this PR (hash 3e94b6d)
|
@hortont424 @smfr I added a test covering this behavior, please let me know if you have any further feedback or would like any changes to be made. I also cloned this issue to track if skipping the intersection is the correct thing to do in all cases when the window is resized. We were effectively already doing something similar when the window was resized smaller, since the content view bounds were still the larger size, so I don't think this change introduces an issue which was not previously present. |
This is a good point and makes me content enough that I'll r+ |
…orrect size https://bugs.webkit.org/show_bug.cgi?id=258847 <radar://110880116> Reviewed by Tim Horton. During a window resize, [_contentView bounds] will not be up to date during the precommit handler so it is incorrect to intersect it with the web view's bounds. Additionally it makes fullscreen resizing look much smoother. * Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm: (-[WKWebView _updateVisibleContentRects]): Skip intersection if we just resized the WKWebView. * Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: * Tools/TestWebKitAPI/Tests/ios/WKWebViewResize.mm: Added. (-[NSObject swizzled_didUpdateVisibleRect:unobscuredRect:contentInsets:unobscuredRectInScrollViewCoordinates:obscuredInsets:unobscuredSafeAreaInsets:inputViewBounds:scale:minimumScale:viewStability:enclosedInScrollableAncestorView:sendEvenIfUnchanged:]): (setupWKContentViewSwizzle): (operator==): Required for EXPECT_EQ on CGRect. (webViewHasExpectedBounds): (TEST): Add API test which ensures a content view with no other insets will have an unobscuredRect which matches the enclosing WKWebView's bounds after setFrame: is called. Tests both resizing the web view larger and smaller. Canonical link: https://commits.webkit.org/266257@main
3e94b6d
to
d7f28b8
Compare
Committed 266257@main (d7f28b8): https://commits.webkit.org/266257@main Reviewed commits have been landed. Closing PR #15611 and removing active labels. |
d7f28b8
3e94b6d