[webkit-changes] [WebKit/WebKit] 99f26e: Cherry-pick c94b3642944f. https://bugs.webkit.org/...
Carlos Garcia Campos
noreply at github.com
Mon Apr 24 12:36:01 PDT 2023
Branch: refs/heads/webkitglib/2.40
Home: https://github.com/WebKit/WebKit
Commit: 99f26e292111d33c05eb2266564f6e519d7554d5
https://github.com/WebKit/WebKit/commit/99f26e292111d33c05eb2266564f6e519d7554d5
Author: Philippe Normand <philn at igalia.com>
Date: 2023-04-20 (Thu, 20 Apr 2023)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/ImageDecoderGStreamer.cpp
M Source/WebCore/platform/graphics/gstreamer/ImageDecoderGStreamer.h
M Source/WebCore/platform/gstreamer/GStreamerElementHarness.cpp
M Source/WebCore/platform/gstreamer/GStreamerElementHarness.h
Log Message:
-----------
Cherry-pick c94b3642944f. https://bugs.webkit.org/show_bug.cgi?id=254622
[GStreamer] Critical warnings when browsing cnn.com
https://bugs.webkit.org/show_bug.cgi?id=254622
Reviewed by Xabier Rodriguez-Calvar.
Parsing and decoding errors are propagated from the GStreamer element harness to the ImageDecoder.
The cnn.com debug logs indicated the openh264dec was failing to negotiate caps with upstream.
This patch also includes a couple changes in the GStreamerElementHarness, mainly automatic start-up
of chained harnesses in order to avoid potentially racy behaviors in sticky events handling.
* Source/WebCore/platform/graphics/gstreamer/ImageDecoderGStreamer.cpp:
(WebCore::ImageDecoderGStreamer::ImageDecoderGStreamer):
(WebCore::ImageDecoderGStreamer::encodedDataStatus const):
(WebCore::ImageDecoderGStreamer::pushEncodedData):
* Source/WebCore/platform/graphics/gstreamer/ImageDecoderGStreamer.h:
* Source/WebCore/platform/gstreamer/GStreamerElementHarness.cpp:
(WebCore::GStreamerElementHarness::pushStickyEvents):
(WebCore::GStreamerElementHarness::Stream::Stream):
* Source/WebCore/platform/gstreamer/GStreamerElementHarness.h:
(WebCore::GStreamerElementHarness::isStarted const):
Canonical link: https://commits.webkit.org/263134@main
Commit: 340ecb641f5f403b55422becdf19a8b8028b41ec
https://github.com/WebKit/WebKit/commit/340ecb641f5f403b55422becdf19a8b8028b41ec
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-04-21 (Fri, 21 Apr 2023)
Changed paths:
A LayoutTests/fast/events/message-event-data-isolated-world-expected.txt
A LayoutTests/fast/events/message-event-data-isolated-world.html
M Source/WebCore/dom/MessageEvent.cpp
Log Message:
-----------
Cherry-pick 263155 at main (ca6ca7d1895d). https://bugs.webkit.org/show_bug.cgi?id=254777
REGRESSION (Safari 16.4): PostMessage with transfer object is broken between contexts
https://bugs.webkit.org/show_bug.cgi?id=254777
rdar://107538083
Reviewed by Geoffrey Garen.
Before 256896 at main, we would construct MessageEvents and give them a
SerializedScriptValue to store internally. Then, the deserialization of this
SerializedScriptValue would happen lazily when the JS accesses
MessageEvent.data. We would then cache the result of the deserialization
inside MessageEvent::m_cachedData to avoid repeated deserializations.
Also note that we would make sure that the cachedData's world matches the
current world before using it. We would deserialize again if the worlds
don't match.
After 256896 at main, we now deserialize the SerializedScriptValue eagerly, so
that we know whether to fire a `message` event or a `messageerror` one.
This deserialization would happen in the main JS world and we would pass
the resulting JSValue to the MessageEvent to store instead of the
SerializedScriptValue. This would work fine for main worlds and regressed
isolated worlds since JSMessageEvent::data() would not have a
SerializedScriptValue to re-deserialize for isolated worlds.
To address the issue, we now construct MessageEvents with a
SerializedScriptValue, like we did before 256896 at main. For performance reasons
we also store the deserialized JSValue in MessageEvent::cachedData so that
later calls to JSMessageEvent::data() don't end up deserializing the
SerializedScriptValue again if called from the main world. However, if the
call for JSMessageEvent::data() comes from an isolated world, the
implementation will properly deserialize the SerializedScriptValue again,
like it did before 256896 at main.
This was tested manually on strava.com.
Test: fast/events/message-event-data-isolated-world.html
* Source/WebCore/dom/MessageEvent.cpp:
(WebCore::MessageEvent::create):
Canonical link: https://commits.webkit.org/263155@main
Commit: 1d3ef65bb4f84b1cc8cb8bca3fdb325e411f23eb
https://github.com/WebKit/WebKit/commit/1d3ef65bb4f84b1cc8cb8bca3fdb325e411f23eb
Author: Said Abou-Hallawa <said at apple.com>
Date: 2023-04-21 (Fri, 21 Apr 2023)
Changed paths:
M Source/WebCore/html/HTMLImageElement.cpp
M Source/WebCore/platform/graphics/BitmapImage.cpp
M Source/WebCore/platform/graphics/BitmapImage.h
M Source/WebCore/platform/graphics/DecodingOptions.h
M Source/WebCore/platform/graphics/GraphicsContext.h
M Source/WebCore/platform/graphics/ImageFrame.cpp
M Source/WebCore/platform/graphics/ImageSource.cpp
M Source/WebCore/platform/graphics/ImageSource.h
M Source/WebCore/platform/graphics/NativeImage.cpp
M Source/WebCore/platform/graphics/NativeImage.h
M Source/WebCore/platform/graphics/cg/ImageDecoderCG.cpp
M Source/WebCore/rendering/RenderBoxModelObject.cpp
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Source/WebKit/WebProcess/GPU/graphics/RemoteDisplayListRecorderProxy.cpp
M Source/WebKit/WebProcess/GPU/graphics/RemoteDisplayListRecorderProxy.h
M Source/WebKit/WebProcess/GPU/graphics/RemoteResourceCacheProxy.cpp
Log Message:
-----------
Cherry-pick 261700 at main (00ca303e3374). https://bugs.webkit.org/show_bug.cgi?id=253655
[GPU Process] Have one copy of NativeImage when it is shared between WebProcess and GPUProcess
https://bugs.webkit.org/show_bug.cgi?id=253655
rdar://106505650
Reviewed by Simon Fraser.
Since WebProcess has to share the local PlatformImage with GPUProcess through
ShareableBitmap, we can get rid of the local PlatformImage and have both processes
use the ShareableBitmap.
For GPUProcess, we can ensure we decode the PlatformImage for sizeForDrawing
instead of decoding it for the full size.
Also this patch simplifies DecodingOptions and make have explicit DecodingMode
and sizeForDrawing. This will make DecodingOptions::isCompatibleWith() simpler
and can be used for synchronous and asynchronous decoding mode.
* Source/WebCore/html/HTMLImageElement.cpp:
(WebCore::HTMLImageElement::decoding const):
* Source/WebCore/platform/graphics/BitmapImage.cpp:
(WebCore::BitmapImage::frameImageAtIndexCacheIfNeeded):
(WebCore::BitmapImage::draw):
(WebCore::BitmapImage::internalStartAnimation):
(WebCore::BitmapImage::decode):
(WebCore::BitmapImage::imageFrameAvailableAtIndex):
* Source/WebCore/platform/graphics/BitmapImage.h:
* Source/WebCore/platform/graphics/DecodingOptions.h:
(WebCore::DecodingOptions::DecodingOptions):
(WebCore::DecodingOptions::decodingMode const):
(WebCore::DecodingOptions::isAuto const):
(WebCore::DecodingOptions::isSynchronous const):
(WebCore::DecodingOptions::isAsynchronous const):
(WebCore::DecodingOptions::sizeForDrawing const):
(WebCore::DecodingOptions::hasFullSize const):
(WebCore::DecodingOptions::hasSizeForDrawing const):
(WebCore::DecodingOptions::isCompatibleWith const):
(WebCore::DecodingOptions::operator== const): Deleted.
(WebCore::DecodingOptions::isAsynchronousCompatibleWith const): Deleted.
(WebCore::DecodingOptions::maxDimension): Deleted.
(WebCore::DecodingOptions::has const): Deleted.
(WebCore::DecodingOptions::hasDecodingMode const): Deleted.
(WebCore::DecodingOptions::hasSize const): Deleted.
* Source/WebCore/platform/graphics/GraphicsContext.h:
(WebCore::GraphicsContext::preferredImageDecodingMode const):
* Source/WebCore/platform/graphics/ImageFrame.cpp:
(WebCore::ImageFrame::hasFullSizeNativeImage const):
(WebCore::ImageFrame::hasDecodedNativeImageCompatibleWithOptions const):
* Source/WebCore/platform/graphics/ImageSource.cpp:
(WebCore::ImageSource::requestFrameAsyncDecodingAtIndex):
(WebCore::ImageSource::frameAtIndexCacheIfNeeded):
(WebCore::ImageSource::frameIsBeingDecodedAndIsCompatibleWithOptionsAtIndex):
(WebCore::ImageSource::frameImageAtIndexCacheIfNeeded):
* Source/WebCore/platform/graphics/ImageSource.h:
* Source/WebCore/platform/graphics/NativeImage.cpp:
(WebCore::NativeImage::NativeImage):
(WebCore::NativeImage::setPlatformImage):
* Source/WebCore/platform/graphics/NativeImage.h:
* Source/WebCore/platform/graphics/cg/ImageDecoderCG.cpp:
(WebCore::createImageSourceThumbnailOptions):
(WebCore::appendImageSourceOption):
(WebCore::imageSourceThumbnailOptions):
(WebCore::ImageDecoderCG::createFrameImageAtIndex):
(WebCore::createImageSourceAsyncOptions): Deleted.
(WebCore::imageSourceAsyncOptions): Deleted.
* Source/WebCore/rendering/RenderBoxModelObject.cpp:
(WebCore::RenderBoxModelObject::decodingModeForImageDraw const):
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
* Source/WebKit/WebProcess/GPU/graphics/RemoteDisplayListRecorderProxy.cpp:
(WebKit::RemoteDisplayListRecorderProxy::preferredImageDecodingMode const):
* Source/WebKit/WebProcess/GPU/graphics/RemoteDisplayListRecorderProxy.h:
* Source/WebKit/WebProcess/GPU/graphics/RemoteResourceCacheProxy.cpp:
(WebKit::RemoteResourceCacheProxy::recordNativeImageUse):
Canonical link: https://commits.webkit.org/261700@main
Commit: 751a464c5177312422d37eb0d349282bd3f2676a
https://github.com/WebKit/WebKit/commit/751a464c5177312422d37eb0d349282bd3f2676a
Author: Said Abou-Hallawa <said at apple.com>
Date: 2023-04-21 (Fri, 21 Apr 2023)
Changed paths:
A LayoutTests/http/tests/images/render-partial-image-load-expected.html
A LayoutTests/http/tests/images/render-partial-image-load.html
M Source/WebCore/platform/graphics/ImageFrame.cpp
M Source/WebCore/platform/graphics/ImageSource.cpp
M Source/WebCore/platform/graphics/ImageSource.h
Log Message:
-----------
Cherry-pick 263085 at main (b56577295e3d). https://bugs.webkit.org/show_bug.cgi?id=249645
Images are not drawn even after they are completely loaded from a slow server
https://bugs.webkit.org/show_bug.cgi?id=249645
rdar://103560731
Reviewed by Simon Fraser.
While loading a BitmapImage (i.e. allDataReceived is false), a partially decoded
NativeImage is created and cached in ImageFrame with DecodingStatus::Partial.
After loading the image is completed, ImageSource::cacheMetadataAtIndex() gets
called with the default DecodingStatus which is DecodingStatus::Invalid. This
forces recalculating a new DecodingStatus which will be DecodingStatus::Complete.
So the ImageFrame will have partially decoded NativeImage and DecodingStatus::
Complete. The next draw ImageFrame::hasDecodedNativeImageCompatibleWithOptions()
will return true and a stale NativeImage is drawn, which usually draws nothing
except for JPEG images.
It turns out we were setting ImageFrame::m_decodingStatus incorrectly always when
decoding an image asynchronously on GTK and WPE ports. We get the decodingStatus
of the frame when requesting it to be asynchronously decoded. This is calculated
by calling frameIsCompleteAtIndex(). ScalableImageDecoder::frameIsCompleteAtIndex()
returns false always if we have not decoded the frame yet.
The fix is to let ImageSource::cachePlatformImageAtIndex() be the only place to
set the ImageFrame::m_decodingStatus since it is the only setter for the
ImageFrame::nativeImage and we are sure at this point frameIsCompleteAtIndex()
will return the correct value for all ports.
* LayoutTests/http/tests/images/render-partial-image-load-expected.html: Added.
* LayoutTests/http/tests/images/render-partial-image-load.html: Added.
* Source/WebCore/platform/graphics/ImageFrame.cpp:
(WebCore::ImageFrame::hasDecodedNativeImageCompatibleWithOptions const):
* Source/WebCore/platform/graphics/ImageSource.cpp:
(WebCore::ImageSource::cacheMetadataAtIndex):
(WebCore::ImageSource::cachePlatformImageAtIndex):
(WebCore::ImageSource::cachePlatformImageAtIndexAsync):
(WebCore::ImageSource::startAsyncDecodingQueue):
(WebCore::ImageSource::requestFrameAsyncDecodingAtIndex):
(WebCore::ImageSource::frameAtIndexCacheIfNeeded):
* Source/WebCore/platform/graphics/ImageSource.h:
Canonical link: https://commits.webkit.org/263085@main
Commit: 114d3a1204242454ab9308bdf12379adf7a2aaa3
https://github.com/WebKit/WebKit/commit/114d3a1204242454ab9308bdf12379adf7a2aaa3
Author: Philippe Normand <philn at igalia.com>
Date: 2023-04-21 (Fri, 21 Apr 2023)
Changed paths:
M Source/WebKit/PlatformWPE.cmake
Log Message:
-----------
Cherry-pick 263007 at main (82caf34be7c8). https://bugs.webkit.org/show_bug.cgi?id=255481
REGRESSION(262028 at main): Broke WPE builds with locally built GStreamer dependency
https://bugs.webkit.org/show_bug.cgi?id=255481
Reviewed by Adrian Perez de Castro.
Fix the WPE InjectedBundle build by tweaking the system include directories, same as for GTK port.
* Source/WebKit/PlatformWPE.cmake:
Canonical link: https://commits.webkit.org/263007@main
Commit: b9071efe5331a01a333a602ab228edee65898146
https://github.com/WebKit/WebKit/commit/b9071efe5331a01a333a602ab228edee65898146
Author: Vitaly Dyachkov <vitaly at igalia.com>
Date: 2023-04-22 (Sat, 22 Apr 2023)
Changed paths:
M Source/WebCore/platform/graphics/Font.h
M Source/WebCore/platform/graphics/FontCustomPlatformData.h
M Source/WebCore/platform/graphics/freetype/FontCustomPlatformDataFreeType.cpp
Log Message:
-----------
Cherry-pick 263258 at main (dc4c470f9471). https://bugs.webkit.org/show_bug.cgi?id=255785
[WPE][GTK] Do not deref CreationData's buffer when Cairo font is destroyed
https://bugs.webkit.org/show_bug.cgi?id=255785
Reviewed by Carlos Alberto Lopez Perez.
Since 263084 at main `FontCustomPlatformData` takes
`FontPlatformData::CreationData` instead of `FragmentedSharedBuffer`.
The buffer is now a reference counted field of
`FontPlatformData::CreationData` struct and will be automatically
dereferenced when `FontCustomPlatformData` is destroyed.
It is an error to manually dereference it using Cairo font destroy
function.
* Source/WebCore/platform/graphics/freetype/FontCustomPlatformDataFreeType.cpp:
(WebCore::FontCustomPlatformData::FontCustomPlatformData):
(WebCore::releaseCustomFontData): Deleted.
Canonical link: https://commits.webkit.org/263258@main
Commit: 558c55192fc2828492612222a9c7a5f5c33977f8
https://github.com/WebKit/WebKit/commit/558c55192fc2828492612222a9c7a5f5c33977f8
Author: Adrian Perez de Castro <aperez at igalia.com>
Date: 2023-04-24 (Mon, 24 Apr 2023)
Changed paths:
M Source/WebCore/platform/graphics/egl/GLContextEGL.cpp
Log Message:
-----------
Cherry-pick 263299 at main (973843664d25). https://bugs.webkit.org/show_bug.cgi?id=255846
[GTK] Build failure due to EGLNativeWindowType cast when GTK only has Wayland support
https://bugs.webkit.org/show_bug.cgi?id=255846
Reviewed by Michael Catanzaro.
EGLNativeWindowType can be aliased to a different type depending on the
EGL implementation headers, and static_cast (or reinterpret_cast) may
not always work. This is similar to 194561 at main, but with the conversion
being done in the opposite direction, therefore we apply the same
solution using a C style cast expression, which works in all cases.
* Source/WebCore/platform/graphics/egl/GLContext.cpp:
(WebCore::GLContext::createWindowContext): Use a plain C cast expression.
Canonical link: https://commits.webkit.org/263299@main
Commit: 4e304ac6bc4dcd34825597a2fafda7afe825396b
https://github.com/WebKit/WebKit/commit/4e304ac6bc4dcd34825597a2fafda7afe825396b
Author: Antoine Quint <graouts at webkit.org>
Date: 2023-04-24 (Mon, 24 Apr 2023)
Changed paths:
A LayoutTests/webanimations/accelerated-animation-addition-lower-in-effect-stack-expected.html
A LayoutTests/webanimations/accelerated-animation-addition-lower-in-effect-stack.html
M Source/WebCore/animation/DocumentTimeline.cpp
M Source/WebCore/animation/KeyframeEffect.cpp
M Source/WebCore/animation/KeyframeEffect.h
M Source/WebCore/animation/KeyframeEffectStack.cpp
M Source/WebCore/animation/KeyframeEffectStack.h
M Source/WebCore/platform/graphics/ca/GraphicsLayerCA.cpp
Log Message:
-----------
Cherry-pick 262875 at main (d566d000c7a5). https://bugs.webkit.org/show_bug.cgi?id=255338
REGRESSION (260399 at main): animations flicker on https://payto.com.au
https://bugs.webkit.org/show_bug.cgi?id=255338
rdar://107532064
Reviewed by Dean Jackson.
When creating a new animation of any type (CSS Transition, CSS Animation, Web Animations API)
that is accelerated, we add it to the list of animations on GraphicsLayerCA regardless of its
composite order relative to other effects for the given target.
In the case of https://payto.com.au, a CSS Animation is applied to an element for the "transform"
property, and that property also yields a CSS Transition that is canceled and recreated on each
frame (whether this is the right behavior is discussed in w3c/csswg-drafts#8701
as Firefox, Chrome and Safari all have different behavior).
That perpetually-recreated CSS Transition is lower in the composite order, but since it's created
after the CSS Animation, due to how we create accelerated animations it would override the CSS Animation.
In this patch we change the behavior of DocumentTimeline::applyPendingAcceleratedAnimations() to
update the entire effect stack with which an effect pending application of an accelerated action
is associated. This guarantees the effect stack's order to be preserved.
We also ensure we remove any similarly-named animation before adding new animations in GraphicsLayerCA.
* LayoutTests/webanimations/accelerated-animation-addition-lower-in-effect-stack-expected.html: Added.
* LayoutTests/webanimations/accelerated-animation-addition-lower-in-effect-stack.html: Added.
* Source/WebCore/animation/DocumentTimeline.cpp:
(WebCore::DocumentTimeline::applyPendingAcceleratedAnimations):
* Source/WebCore/animation/KeyframeEffect.cpp:
(WebCore::KeyframeEffect::applyPendingAcceleratedActionsOrUpdateTimingProperties):
* Source/WebCore/animation/KeyframeEffect.h:
* Source/WebCore/animation/KeyframeEffectStack.cpp:
(WebCore::KeyframeEffectStack::applyPendingAcceleratedActions const):
* Source/WebCore/animation/KeyframeEffectStack.h:
* Source/WebCore/platform/graphics/ca/GraphicsLayerCA.cpp:
(WebCore::GraphicsLayerCA::createTransformAnimationsFromKeyframes):
(WebCore::GraphicsLayerCA::createFilterAnimationsFromKeyframes):
Canonical link: https://commits.webkit.org/262875@main
Commit: 7c01da714adecccf8124b73b88cd2f3cc65313e7
https://github.com/WebKit/WebKit/commit/7c01da714adecccf8124b73b88cd2f3cc65313e7
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2023-04-24 (Mon, 24 Apr 2023)
Changed paths:
M Tools/MiniBrowser/gtk/BrowserWindow.c
Log Message:
-----------
Cherry-pick 263308 at main (ba351310fb37). https://bugs.webkit.org/show_bug.cgi?id=255864
[GTK] MiniBrowser: pressing ESC doesn't exit pointer lock mode
https://bugs.webkit.org/show_bug.cgi?id=255864
Reviewed by Adrian Perez de Castro.
This is because we have an accelerator to stop loading when ESC is
pressed, but it's always enabled. The key press is always consumed by
the accel and never passed to the view.
* Tools/MiniBrowser/gtk/BrowserWindow.c:
(webViewIsLoadingChanged): Disable the stop page load action when not loading.
(stopPageLoad): Do not close the search bar in stop page load action.
Canonical link: https://commits.webkit.org/263308@main
Compare: https://github.com/WebKit/WebKit/compare/96b2c10f913a...7c01da714ade
More information about the webkit-changes
mailing list