[webkit-changes] [WebKit/WebKit] 7575ad: Cherry-pick 274011 at main (f2599adbe881). https://bu...

[Adrian Perez]

  Branch: refs/heads/webkitglib/2.42
  Home:   https://github.com/WebKit/WebKit
  Commit: 7575ad359167e085c3cdd40dcae1053af57d0583
      https://github.com/WebKit/WebKit/commit/7575ad359167e085c3cdd40dcae1053af57d0583
  Author: Olivier Blin <olivier.blin at softathome.com>
  Date:   2024-02-03 (Sat, 03 Feb 2024)

  Changed paths:
    M Source/WebKit/UIProcess/soup/WebProcessPoolSoup.cpp

  Log Message:
  -----------
  Cherry-pick 274011 at main (f2599adbe881). https://bugs.webkit.org/show_bug.cgi?id=268479

    REGRESSION (234750 at main): [GTK][WPE] preferred language not passed to NetworkProcess if set in WebContext before creating WebView
    https://bugs.webkit.org/show_bug.cgi?id=268479

    Reviewed by Adrian Perez de Castro.

    In GLib ports, since 234750 at main, the user preferred language is not
    properly passed to the NetworkProcess if it is set in WebContext
    before creating the WebView.
    This causes a wrong Accept-Language header in HTTP requests sent with libsoup.

    The webkit_web_context_set_preferred_languages() API can be called
    before passing the WebContext at WebView creation.
    Since 234750 at main, this function calls the setOverrideLanguages()
    WebProcessPool API instead of the overrideUserPreferredLanguages() WTF API.

    So WebProcessPool::platformInitializeNetworkProcess() could not get the
    real preferred language from the userPreferredLanguages() WTF API.

    Instead, the NetworkProcess creation should use the overrideLanguages()
    WebProcessPool API, like already done for the WebProcess creation
    parameters (see also 226031 at main).
    Keep userPreferredLanguages() as a fallback to get the default
    language from platformLanguage() in WTF::LanguageUnix.

    * Source/WebKit/UIProcess/soup/WebProcessPoolSoup.cpp:
    (WebKit::WebProcessPool::platformInitializeNetworkProcess):

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


  Commit: 75cfcdec027c30644b72fd980189044f386e9504
      https://github.com/WebKit/WebKit/commit/75cfcdec027c30644b72fd980189044f386e9504
  Author: Georges Basile Stavracas Neto <feaneron at igalia.com>
  Date:   2024-02-03 (Sat, 03 Feb 2024)

  Changed paths:
    M Source/WebCore/platform/gamepad/manette/ManetteGamepad.cpp
    M Source/WebCore/platform/gamepad/manette/ManetteGamepad.h

  Log Message:
  -----------
  Cherry-pick 274022 at main (37a85d6c3252). https://bugs.webkit.org/show_bug.cgi?id=268653

    [GTK][WPE] Detect gamepad button 16
    https://bugs.webkit.org/show_bug.cgi?id=268653

    Reviewed by Michael Catanzaro.

    The Gamepad spec lists 17 buttons, starting at zero. The button number
    16 is defined as "Center button in center cluster" [1], e.g. the PS
    button in a DualShock 4 or 5, or similar ones in other controllers.

    The libmanette gamepad backend only lists up to button number 15, which
    was what was under the spec when the backend was introduced.

    Add the button 16 to the listing as well. Listing is all that is needed
    since the rest of the code already detects and maps this button as
    expected

    [1] https://www.w3.org/TR/gamepad/#dfn-standard-gamepad

    * Source/WebCore/platform/gamepad/manette/ManetteGamepad.cpp:
    (WebCore::toStandardGamepadButton):
    * Source/WebCore/platform/gamepad/manette/ManetteGamepad.h:

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


  Commit: 1bed1f4d2e254778c906147f094c1a4359b089d2
      https://github.com/WebKit/WebKit/commit/1bed1f4d2e254778c906147f094c1a4359b089d2
  Author: Georges Basile Stavracas Neto <feaneron at igalia.com>
  Date:   2024-02-03 (Sat, 03 Feb 2024)

  Changed paths:
    M Source/WebKit/UIProcess/Gamepad/gtk/UIGamepadProviderGtk.cpp

  Log Message:
  -----------
  Cherry-pick 273882 at main (7ca356b2f1bf). https://bugs.webkit.org/show_bug.cgi?id=258264

    [GTK] Check window focus with gtk_window_is_active()
    https://bugs.webkit.org/show_bug.cgi?id=258264

    Reviewed by Michael Catanzaro.

    In GTK3, gtk_widget_has_focus() called on a GtkWindow has the semantics
    of "does this window receive input". This semantic is not preserved in
    GTK4; instead, gtk_window_is_active() is what yields the same results.

    By using gtk_widget_has_focus() in UIGamepadProviderGtk, it always
    returned false, and prevented gamepad detection from properly working.
    Switch that to gtk_window_is_active().

    * Source/WebKit/UIProcess/Gamepad/gtk/UIGamepadProviderGtk.cpp:
    (WebKit::UIGamepadProvider::platformWebPageProxyForGamepadInput):

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


Compare: https://github.com/WebKit/WebKit/compare/1d37ed0cf1ac...1bed1f4d2e25