[webkit-changes] [WebKit/WebKit] 4c8817: Cherry-pick 284719 at main (9635c3817243). https://bu...

[Basuke Suzuki]

  Branch: refs/heads/webkitglib/2.46
  Home:   https://github.com/WebKit/WebKit
  Commit: 4c881791dfe8582c6e23854bced6ebcbefa84bf1
      https://github.com/WebKit/WebKit/commit/4c881791dfe8582c6e23854bced6ebcbefa84bf1
  Author: Alex Christensen <achristensen at apple.com>
  Date:   2024-10-07 (Mon, 07 Oct 2024)

  Changed paths:
    M Source/WebKit/UIProcess/WebPageProxy.cpp

  Log Message:
  -----------
  Cherry-pick 284719 at main (9635c3817243). https://bugs.webkit.org/show_bug.cgi?id=280888

    REGRESSION(282394 at 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 <basuke.suzuki at sony.com>
  Date:   2024-10-07 (Mon, 07 Oct 2024)

  Changed paths:
    M Source/WebCore/html/HTMLMediaElement.cpp

  Log Message:
  -----------
  Cherry-pick 284711 at main (5f8c88f5cf2b). https://bugs.webkit.org/show_bug.cgi?id=280903

    REGRESSION (279761 at 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