Branch: refs/heads/webkitglib/2.46
Home: https://github.com/WebKit/WebKit
Commit: 4c881791dfe8582c6e23854bced6ebcbefa84bf1
https://github.com/WebKit/WebKit/commit/4c881791dfe8582c6e23854bced6ebcbefa84bf1
Author: Alex Christensen <[email protected]>
Date: 2024-10-07 (Mon, 07 Oct 2024)
Changed paths:
M Source/WebKit/UIProcess/WebPageProxy.cpp
Log Message:
-----------
Cherry-pick 284719@main (9635c3817243).
https://bugs.webkit.org/show_bug.cgi?id=280888
REGRESSION(282394@main): Flaky ASSERTION FAILED: !users.contains(pageID) on
TestWebKitAPI.ProcessSwap.ConcurrentHistoryNavigations
https://bugs.webkit.org/show_bug.cgi?id=280888
rdar://136716513
Reviewed by Chris Dumez.
The assertion happens when registering a pageID as a VisitedLinkStore
client and the crash
happens if the pageID is already registered. Normally, when we construct a
ProvisionalPageProxy
(for a process swap), we will register the pageID as a VisitedLinkStore
client for the new
WebProcess used for the navigation. However, due to a race, the
ProvisionalPageProxy sometimes
ends up using the same WebProcess as the WebPageProxy's current WebProcess.
This doesn't make
sense since ProvisionalPageProxy is only supposed to be used in case of
process-swap.
The race is in WebPageProxy::receivedNavigationActionPolicyDecision(),
where the lambda may
sometimes run after the frame has been detached from the frame tree (the
frame has been replaced).
To address the issue, we now early return in the lambda if the frame has
been detached so that
we don't attempt to do a process swap in this case.
This case is hit by the API test WKNavigation.HTTPSOnlyWithHTTPRedirect
which rapidly redirects
back and forth until the maximum number of redirects is hit. The early
return is registering
one fewer callback now, which is fine. The exact number of callbacks isn't
what that test was
testing, but rather that didFailNavigation happens after it is hit.
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::receivedNavigationActionPolicyDecision):
Canonical link: https://commits.webkit.org/284719@main
Canonical link: https://commits.webkit.org/282416.195@webkitglib/2.46
Commit: a9013872315792c1e94554f7776268e636be5f5d
https://github.com/WebKit/WebKit/commit/a9013872315792c1e94554f7776268e636be5f5d
Author: Basuke Suzuki <[email protected]>
Date: 2024-10-07 (Mon, 07 Oct 2024)
Changed paths:
M Source/WebCore/html/HTMLMediaElement.cpp
Log Message:
-----------
Cherry-pick 284711@main (5f8c88f5cf2b).
https://bugs.webkit.org/show_bug.cgi?id=280903
REGRESSION (279761@main): Returning to inline playback from fullscreen
shows only the play/pause button instead of the full controls
https://bugs.webkit.org/show_bug.cgi?id=280903
rdar://134924988
Reviewed by Andy Estes.
Full control should be displayed when switching back from fullscreen mode,
but play/pause button is displayed.
Steps to reproduce:
1. Open https://developer.apple.com/videos/play/wwdc2023/10279/ in Safari
on macOS
2. Start video playback
3. Enter fullscreen
4. Exit fullscreen
At this point you’ll notice that the only media control available is the
play/pause button instead of the full media controls.
The issue is introduced with the following commit:
https://commits.webkit.org/279761@main
The logic added to HTMLMediaElement::shouldForceControlsDisplay() is for
tvOS and no reason to apply it to other platform.
Wrapping the logic with PLATFORM(APPLETV) should fix the issue.
* Source/WebCore/html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::shouldForceControlsDisplay const):
Canonical link: https://commits.webkit.org/284711@main
Canonical link: https://commits.webkit.org/282416.196@webkitglib/2.46
Compare: https://github.com/WebKit/WebKit/compare/6f211be22cef...a90138723157
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
