Branch: refs/heads/webkitglib/2.38
Home: https://github.com/WebKit/WebKit
Commit: f387c2f168e6902617dd1de91f2d4bc75ac4ccb6
https://github.com/WebKit/WebKit/commit/f387c2f168e6902617dd1de91f2d4bc75ac4ccb6
Author: Charlie Wolfe <charl...@apple.com>
Date: 2023-03-05 (Sun, 05 Mar 2023)
Changed paths:
A
LayoutTests/http/tests/navigation/cross-origin-iframe-location-hash-reexecute-onload-expected.txt
A
LayoutTests/http/tests/navigation/cross-origin-iframe-location-hash-reexecute-onload.html
A
LayoutTests/http/tests/navigation/resources/change-location-hash-onload.html
M Source/WebCore/loader/FrameLoader.cpp
Log Message:
-----------
Cherry-pick 260860@main (e9dd88dee673).
https://bugs.webkit.org/show_bug.cgi?id=252931
window.onload is repeatedly re-executed when changing URL fragment during
onload
https://bugs.webkit.org/show_bug.cgi?id=252931
rdar://105158419
Reviewed by Chris Dumez.
When a cross-origin iframe changes its fragment identifier while its load
event is being processed,
we end up in a state where we will continually re-fire window.onload. We
should fix this by only
firing the load event on the frame's owner element. This still addresses
the concern the original
change fixed (259384@main), but without needing to always re-fire the
window load event.
*
LayoutTests/http/tests/navigation/cross-origin-iframe-location-hash-reexecute-onload-expected.txt:
Added.
*
LayoutTests/http/tests/navigation/cross-origin-iframe-location-hash-reexecute-onload.html:
Added.
*
LayoutTests/http/tests/navigation/resources/change-location-hash-onload.html:
Added.
* Source/WebCore/loader/FrameLoader.cpp:
(WebCore::FrameLoader::loadInSameDocument):
Canonical link: https://commits.webkit.org/260860@main
Commit: b30ff7c04c38edddf1a838b6933c926a2c466cc3
https://github.com/WebKit/WebKit/commit/b30ff7c04c38edddf1a838b6933c926a2c466cc3
Author: Žan Doberšek <zdober...@igalia.com>
Date: 2023-03-05 (Sun, 05 Mar 2023)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp
Log Message:
-----------
Cherry-pick 261072@main (5c473b4124bf).
https://bugs.webkit.org/show_bug.cgi?id=253244
[GStreamer] Establish locking when mapping gbm_bo objects for
software-decoded data upload
https://bugs.webkit.org/show_bug.cgi?id=253244
Reviewed by Philippe Normand.
When separate GStreamer pipelines are established for different video
elements,
mapping the gbm_bo objects in parallel across different threads can lead to
crashes and GPU memory corruption.
The different gbm_bo objects originate from a single gbm_device, which is
fine.
Spawning gbm_bo objects and retrieving different attributes from them isn't
showing as problematic, but libgbm thread safety guarantees still need
research.
Mapping gbm_bo objects in parallel is proving as problematic, and the
length of
the upload of software-decoded data into the mapped memory regions takes
long
enough for these problems to inhibit stability. To avoid that, a global
lock is
provided on the gbm_bo-mapping Destination class inside the
MediaPlayerPrivateGStreamer::pushDMABufToCompositor() method. This lock is
activated whenever data for a given plane is moved over from the
GStreamer-based
software decoder into the gbm_bo object.
*
Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
(WebCore::MediaPlayerPrivateGStreamer::pushDMABufToCompositor):
Canonical link: https://commits.webkit.org/261072@main
Commit: f832b533ef178df4e2055f394118ca162a59170c
https://github.com/WebKit/WebKit/commit/f832b533ef178df4e2055f394118ca162a59170c
Author: Žan Doberšek <zdober...@igalia.com>
Date: 2023-03-05 (Sun, 05 Mar 2023)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp
Log Message:
-----------
Cherry-pick 261077@main (9b1c8b87c0a4).
https://bugs.webkit.org/show_bug.cgi?id=253245
[GStreamer] Improve GBM swapchain buffer handling
https://bugs.webkit.org/show_bug.cgi?id=253245
Reviewed by Philippe Normand.
In MediaPlayerPrivateGStreamer::pushDMABufToCompositor(), when allocating
buffer objects from the GBMBufferSwapchain to upload the software-decoded
video data, do a null check on the retrieved buffer. This avoids proceeding
with
a null object that would be returned when for whatever perverse reason the
swapchain is drained of available buffers.
One such reason is when allocating, retrieving and locking buffers from the
swapchain under an inactive proxy. In that case, the buffer doesn't end up
being pushed into the composition, and it's then also never released and
made
available for reuse, effectively draining the swapchain.
This case is avoidable through earlier detection of an inactive proxy. The
proxy
lock and is-active check are unified between different codepaths and done
before
deciding which codepath is taken.
*
Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
(WebCore::MediaPlayerPrivateGStreamer::pushDMABufToCompositor):
Canonical link: https://commits.webkit.org/261077@main
Commit: 1dd62a29b52f009da1813fbe45dfbc9b879481c5
https://github.com/WebKit/WebKit/commit/1dd62a29b52f009da1813fbe45dfbc9b879481c5
Author: Brian Weinstein <bweinst...@apple.com>
Date: 2023-03-05 (Sun, 05 Mar 2023)
Changed paths:
M LayoutTests/http/tests/contentextensions/css-display-none.html
M LayoutTests/http/tests/contentextensions/css-display-none.html.json
M Source/WebCore/contentextensions/ContentExtension.cpp
M Source/WebCore/contentextensions/ContentExtensionParser.cpp
M Source/WebCore/contentextensions/ContentExtensionParser.h
M Source/WebCore/contentextensions/ContentExtensionStyleSheet.cpp
M Tools/TestWebKitAPI/Tests/WebCore/ContentExtensions.cpp
Log Message:
-----------
Cherry-pick 259068@main (355ce06ba535).
https://bugs.webkit.org/show_bug.cgi?id=250609
Safari Content Blocker doesn't support :has() selector
https://bugs.webkit.org/show_bug.cgi?id=250609
rdar://103976010
Reviewed by Antti Koivisto and Alex Christensen.
When creating the CSSParsers for content blocker parsing and compilation,
make sure to opt
into hasPseudoClassEnabled so selectors like :has work. The places this was
needed were:
- ContentExtensionParser (for parsing the rules)
- ContentExtension (for the global display none rules)
- ContentExtensionStyleSheet (for the other display none rules)
Also update the contentextensions css-display-none test to test this
functionality.
* Source/WebCore/contentextensions/ContentExtension.cpp:
(WebCore::ContentExtensions::ContentExtension::compileGlobalDisplayNoneStyleSheet):
* Source/WebCore/contentextensions/ContentExtensionParser.cpp:
(WebCore::ContentExtensions::isValidCSSSelector):
Canonical link: https://commits.webkit.org/259068@main
Commit: a334683ab68e4ea4df960843a310979a98a6c63b
https://github.com/WebKit/WebKit/commit/a334683ab68e4ea4df960843a310979a98a6c63b
Author: Brian Weinstein <bweinst...@apple.com>
Date: 2023-03-05 (Sun, 05 Mar 2023)
Changed paths:
M LayoutTests/http/tests/contentextensions/css-display-none.html
M LayoutTests/http/tests/contentextensions/css-display-none.html.json
M Source/WebCore/contentextensions/ContentExtensionParser.cpp
Log Message:
-----------
Cherry-pick 260638@main (6f913a33098b).
https://bugs.webkit.org/show_bug.cgi?id=252677
Content Blocker API ignores some CSS Selectors with uppercase letters.
https://bugs.webkit.org/show_bug.cgi?id=252677
rdar://105648971
Reviewed by Antti Koivisto.
The fix for https://bugs.webkit.org/show_bug.cgi?id=250609 caused us to use
Quirks mode when both
parsing content blocker rules and applying them.
That caused this regression, since rules like .SomeCLass stopped working in
Quirks mode.
To fix this, make us use Quirks mode when actually parsing the rules, but
standard mode when
applying them, to match how the behavior was before
https://bugs.webkit.org/show_bug.cgi?id=250609.
* LayoutTests/http/tests/contentextensions/css-display-none.html:
* LayoutTests/http/tests/contentextensions/css-display-none.html.json:
* Source/WebCore/contentextensions/ContentExtensionParser.cpp:
(WebCore::ContentExtensions::isValidCSSSelector):
(WebCore::ContentExtensions::contentExtensionCSSParserContext):
Canonical link: https://commits.webkit.org/260638@main
Commit: 53eccce198cbcef6fdc29316456356d3323db2d8
https://github.com/WebKit/WebKit/commit/53eccce198cbcef6fdc29316456356d3323db2d8
Author: Patrick Griffis <pgrif...@igalia.com>
Date: 2023-03-05 (Sun, 05 Mar 2023)
Changed paths:
M
Source/WebCore/Modules/mediastream/gstreamer/GStreamerDataChannelHandler.cpp
Log Message:
-----------
Cherry-pick 260580@main (70ed120ac0ba).
https://bugs.webkit.org/show_bug.cgi?id=252601
[GStreamer] GST_WEBRTC_DATA_CHANNEL_STATE_NEW was removed in 1.21.1
https://bugs.webkit.org/show_bug.cgi?id=252601
Reviewed by Philippe Normand.
*
Source/WebCore/Modules/mediastream/gstreamer/GStreamerDataChannelHandler.cpp:
(WebCore::GStreamerDataChannelHandler::checkState):
Canonical link: https://commits.webkit.org/260580@main
Compare: https://github.com/WebKit/WebKit/compare/f0479f9c7c45...53eccce198cb
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
