Cherry-pick 32394 - #77277

4ff7db2

Cherry-pick 323945@main (c6ce07550c64). https://bugs.webkit.org/show_bug.cgi?id=286127

    [GTK] Serialize the composed tree when writing the PRIMARY selection
    https://bugs.webkit.org/show_bug.cgi?id=286127

    Reviewed by Carlos Garcia Campos.

    WebEditorClient::updateGlobalSelection() serialized the selection with the
    default SerializeComposedTree::No, unlike every other selection serializer in
    the tree, including the GLib copy path in Editor::writeSelectionToPasteboard().
    In non-composed mode the traversal cannot reach an end point inside a shadow
    tree, so a selection that crosses a shadow boundary tripped an assertion in
    StyledMarkupAccumulator::traverseNodesForSerialization() and produced truncated
    markup in Release. GTK hit it on every selection change because the PRIMARY
    selection is rewritten each time; no other port serializes there.

    Pass SerializeComposedTree::Yes and IgnoreUserSelectNone::Yes, matching the
    copy path, so the PRIMARY selection carries the same markup as Ctrl+C.

    * LayoutTests/platform/glib/TestExpectations:
    * LayoutTests/platform/gtk/TestExpectations: Unskip the six selection
    shadow-dom tests and the editing test, which pass on GTK Release with
    assertions.
    * Source/WebKit/WebProcess/WebCoreSupport/gtk/WebEditorClientGtk.cpp:
    (WebKit::WebEditorClient::updateGlobalSelection):

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

952633b

Cherry-pick 323946@main (d1523b31f82c). https://bugs.webkit.org/show_bug.cgi?id=327722

    [soup] Non-redirect 3xx responses with a Location header assert in SubresourceLoader::didReceiveResponse()
    https://bugs.webkit.org/show_bug.cgi?id=327722

    Reviewed by Carlos Garcia Campos.

    SubresourceLoader::didReceiveResponse() asserts that a response reaching it
    is not a redirect the network layer should have followed. It phrased that as
    "any 3xx other than 304 with a Location header", which also rejects 300, 305
    and 306: those are final responses whatever headers they carry, and the soup
    backend rightly delivers them. Rewrite the assertion in terms of
    ResourceResponse::isRedirection(), which covers the five redirect statuses
    the fetch specification defines.

    NetworkDataTaskSoup::shouldStartHTTPRedirection() had the complementary bug:
    it followed every 3xx response with a Location header except 300, 304, 305
    and 306, so unassigned codes such as 309 or 350 were redirected where fetch
    treats them as final responses. Use isRedirection() there too.

    Together these make imported/w3c/web-platform-tests/xhr/send-redirect.htm
    pass on GTK and WPE, so unskip it. The curl backend carries the same
    exclusion list and is left for its owners.

    * LayoutTests/platform/glib/TestExpectations:
    * Source/WebCore/loader/SubresourceLoader.cpp:
    (WebCore::SubresourceLoader::didReceiveResponse):
    * Source/WebKit/NetworkProcess/soup/NetworkDataTaskSoup.cpp:
    (WebKit::shouldStartHTTPRedirection):

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

4ff7db2