[webkit-changes] [WebKit/WebKit] 530aeb: Cherry-pick 274137 at main (51e2f83568c5). <bug>

Wed Feb 7 03:10:51 PST 2024

  Branch: refs/heads/webkitglib/2.42
  Home:   https://github.com/WebKit/WebKit
  Commit: 530aebcff409d721f8af115bbe97ef27f237976c
      https://github.com/WebKit/WebKit/commit/530aebcff409d721f8af115bbe97ef27f237976c
  Author: Patrick Griffis <pgriffis at igalia.com>
  Date:   2024-02-07 (Wed, 07 Feb 2024)

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

  Log Message:
  -----------
  Cherry-pick 274137 at main (51e2f83568c5). <bug>

    Unreviewed, [GLib] Fix incorrect format string

    %lu is incorrect on some platforms. PRIu64 is defined for this.

    * Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp:
    (WebKit::bubblewrapSpawn):

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


  Commit: 1ddd227e1a05a0962c9a35f18b1c905fc46cc6f7
      https://github.com/WebKit/WebKit/commit/1ddd227e1a05a0962c9a35f18b1c905fc46cc6f7
  Author: Philippe Normand <philn at igalia.com>
  Date:   2024-02-07 (Wed, 07 Feb 2024)

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

  Log Message:
  -----------
  Cherry-pick 274144 at main (cafc9b17f1fa). https://bugs.webkit.org/show_bug.cgi?id=268759

    [GStreamer] BubblewrapLauncher sandbox lacks directory for the gstreamer user registry cache directory
    https://bugs.webkit.org/show_bug.cgi?id=268759

    Reviewed by Michael Catanzaro.

    Grant read-write access in the default GStreamer registry path within the WebProcess sandbox. This
    is safe because the GStreamer registry file format is binary and the file is not executable. The
    internal GStreamer code responsible for loading this file is able to handle parsing errors.

    For additional context, the registry file stores informations about the plugins available on the
    system, so that the plugin scanner doesn't need to rescan plugins every time GStreamer is
    initialized.

    * Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp:
    (WebKit::bindGStreamerData):

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


  Commit: 3d84c943bcb6e1f6c4dcc46ed52449ba3892a134
      https://github.com/WebKit/WebKit/commit/3d84c943bcb6e1f6c4dcc46ed52449ba3892a134
  Author: Michael Catanzaro <mcatanzaro at redhat.com>
  Date:   2024-02-07 (Wed, 07 Feb 2024)

  Changed paths:
    M Source/WebKit/UIProcess/API/gtk/PageClientImpl.cpp
    M Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp
    M Source/WebKit/UIProcess/API/gtk/WebKitWebViewBasePrivate.h

  Log Message:
  -----------
  Cherry-pick 273922 at main (fd1f0b783bb7). https://bugs.webkit.org/show_bug.cgi?id=261348

    [GTK] Remove key event reinjection
    https://bugs.webkit.org/show_bug.cgi?id=261348

    Reviewed by Carlos Garcia Campos.

    Event processing in GTK is synchronous, but in WebKit it is asynchronous
    because we don't want to block the UI process waiting for the web
    process to decide whether a DOM event has been handled (e.g. by using
    Event.stopPropagation). Currently we use a complicated scheme to
    synthesize and reinject new key and wheel events to continue event
    processing when the event is not handled by the web content, which the
    GTK developers do not approve of, and which is causing serious problems
    where Epiphany has to choose between processing events in an infinite
    loop vs. handling events too soon and blocking the web view from
    receiving them. Neither option is great.

    https://gitlab.gnome.org/GNOME/epiphany/-/issues/1915
    https://gitlab.gnome.org/GNOME/epiphany/-/issues/2173

    The solution is to just never reinject events, and instead always handle
    them. We do not need event reinjection anymore if we activate
    application accelerators manually. See the long comment embedded in this
    commit for full details of why this is necessary.

    This patch removes the key event reinjection. Wheel event reinjection is
    not yet removed because this would break when WebKit is used within
    scrolled windows.

     * Source/WebKit/UIProcess/API/gtk/PageClientImpl.cpp:
     (WebKit::PageClientImpl::doneWithKeyEvent):
     * Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp:
     (shouldForwardKeyEvent):
     (webkitWebViewBaseProcessAcceleratorsForKeyPressEvent):
     (webkitWebViewBaseKeyPressed):
     (handleScroll):
     (webkitWebViewBasePropagateKeyEvent):
     * Source/WebKit/UIProcess/API/gtk/WebKitWebViewBasePrivate.h:

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


  Commit: 27a392eea1663db49c1b03d369b220d2c0cfea4b
      https://github.com/WebKit/WebKit/commit/27a392eea1663db49c1b03d369b220d2c0cfea4b
  Author: Georges Basile Stavracas Neto <feaneron at igalia.com>
  Date:   2024-02-07 (Wed, 07 Feb 2024)

  Changed paths:
    M Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp
    M Source/WebKit/UIProcess/API/gtk/WebKitWebViewBasePrivate.h
    M Source/WebKit/UIProcess/gtk/KeyBindingTranslator.cpp
    M Source/WebKit/UIProcess/gtk/WebPageProxyGtk.cpp
    M Source/WebKit/WebProcess/WebPage/glib/WebPageGLib.cpp

  Log Message:
  -----------
  Cherry-pick 274201 at main (da96990ed73d). https://bugs.webkit.org/show_bug.cgi?id=227528

    [GTK] Implement GTK4 accessibility
    https://bugs.webkit.org/show_bug.cgi?id=227528

    Reviewed by Carlos Garcia Campos.

    WebKit maintains a complete AT-SPI accessible tree within the web
    process, under a separate D-Bus name. This conflicts with GTK4's
    expectations of having instances of GtkAccessible objects in process
    that can be built in an internal tree.

    GTK4 recently introduced support for bridging out-of-process AT-SPI
    accessible trees using a new GtkAtSpiSocket object that implements
    GtkAccessible [1]. The availability of this object is guarded by the
    GTK_ACCESSIBILITY_ATSPI ifdef.

    Use this new socket object from GTK to bridge the web page accessible
    tree, and the UI process' one. Mark the textview widget as hidden from
    the accessible tree.

    Create the GtkAtSpiSocket accessible when the web page reports to be
    ready. Inject the socket accessible as the first GtkAccessible child
    of WebKitWebViewBase.

    [1] https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6827

    * Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp:
    (webkitWebViewBaseAccessibleGetFirstAccessibleChild):
    (webkitWebViewBaseAccessibleInterfaceInit):
    (webkitWebViewBaseSetPlugID):
    * Source/WebKit/UIProcess/API/gtk/WebKitWebViewBasePrivate.h:
    * Source/WebKit/UIProcess/gtk/KeyBindingTranslator.cpp:
    (WebKit::KeyBindingTranslator::KeyBindingTranslator):
    * Source/WebKit/UIProcess/gtk/WebPageProxyGtk.cpp:
    (WebKit::WebPageProxy::bindAccessibilityTree):
    * Source/WebKit/WebProcess/WebPage/glib/WebPageGLib.cpp:
    (WebKit::WebPage::platformInitialize):

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


Compare: https://github.com/WebKit/WebKit/compare/3d5373575695...27a392eea166