[webkit-changes] [WebKit/WebKit] ad247f: python autoinstaller is broken with python 3.12

[Michael Catanzaro]

  Branch: refs/heads/webkitglib/2.42
  Home:   https://github.com/WebKit/WebKit
  Commit: ad247f639619f2ec019a41bfaea5904f80d9c6b2
      https://github.com/WebKit/WebKit/commit/ad247f639619f2ec019a41bfaea5904f80d9c6b2
  Author: Michael Catanzaro <mcatanzaro at redhat.com>
  Date:   2023-08-28 (Mon, 28 Aug 2023)

  Changed paths:
    M Tools/Scripts/libraries/webkitcorepy/webkitcorepy/__init__.py

  Log Message:
  -----------
  python autoinstaller is broken with python 3.12
https://bugs.webkit.org/show_bug.cgi?id=260726

Reviewed by NOBODY (OOPS!).

Currently git-webkit is broken with python 3.12 due to various problems
with dependencies that are already fixed in newer upstream versions. So,
update a few things.

Unfortunately, the newer library versions are incompatible with other
Python versions, so this means more conditional versions.

* Tools/Scripts/libraries/webkitcorepy/webkitcorepy/__init__.py:

Canonical link: https://commits.webkit.org/266719.23@webkitglib/2.42


  Commit: 13de864f3a2845135778bc646a00cbf7becb384e
      https://github.com/WebKit/WebKit/commit/13de864f3a2845135778bc646a00cbf7becb384e
  Author: Michael Catanzaro <mcatanzaro at redhat.com>
  Date:   2023-08-28 (Mon, 28 Aug 2023)

  Changed paths:
    M Source/WebCore/bindings/js/ScriptController.cpp
    M Source/WebKit/UIProcess/API/C/WKPage.cpp
    M Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp
    M Source/WebKit/UIProcess/Inspector/socket/RemoteInspectorProtocolHandler.cpp

  Log Message:
  -----------
  Cherry-pick 267352 at main (3b7c5108fac6). https://bugs.webkit.org/show_bug.cgi?id=260361

    Transient activation should be dropped after evaluating JavaScript, except when required for application compatibility
    https://bugs.webkit.org/show_bug.cgi?id=260361

    Reviewed by Carlos Garcia Campos.

    This is a follow-up to bug #258037 and bug #251276. When a user interacts with
    a web page, the page is said to receive a user gesture and this grants
    additional permissions to the web content until the "transient activation"
    period expires, which in WebKit is 5 seconds. WebKit's API functions that allow
    applications to run JavaScript allow the application to force a user gesture in
    order to execute JS with full permissions. But in this case, the transient
    activation should expire immediately because the user did not really interact
    with the page. Web content should not unexpectedly receive additional
    permissions for 5 seconds whenever the application runs some of its own
    unrelated JS.

    Bug #258037 and bug #251276 fixed this for freshly built applications on
    Cocoa platforms, but left other platforms unchanged because dropping the
    transient activation is not backwards-compatible and coulde possibly
    cause unknown breakage in applications. But the desired behavior is to
    always drop transient activation. Implement this everywhere:

    (1) In RemoteInspectorProtocolHandler.cpp, affecting JS executed by remote
    inspector. This change is surely safe.

    (2) In WebKitWebView.cpp, affecting the GTK and WPE port. This could
    possibly break GTK/WPE applications, so we won't backport it to the 2.40
    stable branch.

    (3) In WKPageRunJavaScriptInMainFrame, affecting non-Cocoa ports. This
    should be safe because the C API is not public except for Windows and
    PlayStation ports, which control the version of WebKit they ship.

    (4) And finally in ScriptController::executeScriptIgnoringException. This
    will affect all ports and could possibly break things.

    * Source/WebCore/bindings/js/ScriptController.cpp:
    (WebCore::ScriptController::executeScriptInWorldIgnoringException):
    * Source/WebKit/UIProcess/API/C/WKPage.cpp:
    (WKPageRunJavaScriptInMainFrame):
    * Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp:
    (webkitWebViewRunJavascriptWithoutForcedUserGestures):
    (webkitWebViewEvaluateJavascriptInternal):
    (webkitWebViewCallAsyncJavascriptFunctionInternal):
    (resourcesStreamReadCallback):
    * Source/WebKit/UIProcess/Inspector/socket/RemoteInspectorProtocolHandler.cpp:
    (WebKit::RemoteInspectorProtocolHandler::runScript):

    Canonical link: https://commits.webkit.org/267352@main

Canonical link: https://commits.webkit.org/266719.24@webkitglib/2.42


  Commit: 20cfdaf8fd3aa2e418a9702bf0d4621b4c50b4de
      https://github.com/WebKit/WebKit/commit/20cfdaf8fd3aa2e418a9702bf0d4621b4c50b4de
  Author: Carlos Garcia Campos <cgarcia at igalia.com>
  Date:   2023-08-28 (Mon, 28 Aug 2023)

  Changed paths:
    M Source/WebCore/platform/graphics/gbm/GBMBufferSwapchain.cpp
    M Source/WebKit/WebProcess/WebPage/gtk/AcceleratedSurfaceDMABuf.cpp

  Log Message:
  -----------
  Cherry-pick 267070 at main (75237ef8a286). https://bugs.webkit.org/show_bug.cgi?id=260431

    [GTK][WPE] Pass GBM_BO_USE_RENDERING to gbm_bo_create
    https://bugs.webkit.org/show_bug.cgi?id=260431

    Reviewed by Michael Catanzaro.

    I suspect nvidia GBM implementation defaults to GBM_BO_USE_SCANOUT when
    no flags are passed and then tries to create KMS dumb buffers. In any
    case, using GBM_BO_USE_RENDERING is correct since those buffers are
    created in the web process for rendering (as a color buffer storage).

    * Source/WebCore/platform/graphics/gbm/GBMBufferSwapchain.cpp:
    (WebCore::GBMBufferSwapchain::getBuffer):
    * Source/WebKit/WebProcess/WebPage/gtk/AcceleratedSurfaceDMABuf.cpp:
    (WebKit::AcceleratedSurfaceDMABuf::RenderTargetEGLImage::create):

    Canonical link: https://commits.webkit.org/267070@main

Canonical link: https://commits.webkit.org/266719.25@webkitglib/2.42


  Commit: 799e8ebe41a397df9d66f2bdd56d8d66e9c8a173
      https://github.com/WebKit/WebKit/commit/799e8ebe41a397df9d66f2bdd56d8d66e9c8a173
  Author: Michael Catanzaro <mcatanzaro at redhat.com>
  Date:   2023-08-28 (Mon, 28 Aug 2023)

  Changed paths:
    M Source/WebKit/UIProcess/Launcher/glib/XDGDBusProxy.cpp

  Log Message:
  -----------
  Cherry-pick 267038 at main (971943d9b665). https://bugs.webkit.org/show_bug.cgi?id=257905

    [GLib] Process launching hangs if xdg-dbus-proxy is not installed
    https://bugs.webkit.org/show_bug.cgi?id=257905

    Reviewed by Carlos Garcia Campos.

    Currently if xdg-dbus-proxy is not installed or if it fails to start for
    any reason, then after attempting to run it under bwrap, we do a
    blocking read() and hang forever waiting for it to respond to us.
    Instead, let's simultaneously do an async read while also checking to
    see if the subprocess has quit. If it fails to spawn, then we can crash
    properly rather than just hang.

    Although I have *technically* removed the synchronous I/O, we still need
    to block here, so the spirit of the FIXME that hopes to avoid blocking
    is not satisfied. Nevertheless, I don't see a realistic path to avoid
    blocking, so I'm going to remove the FIXME anyway.

    * Source/WebKit/UIProcess/Launcher/glib/XDGDBusProxy.cpp:
    (WebKit::waitUntilSyncedOrDie):
    (WebKit::XDGDBusProxy::launch):

    Canonical link: https://commits.webkit.org/267038@main

Canonical link: https://commits.webkit.org/266719.26@webkitglib/2.42


Compare: https://github.com/WebKit/WebKit/compare/1f4124f40460...799e8ebe41a3