[webkit-changes] [WebKit/WebKit] 85145c: Cherry-pick 260851 at main (e6a31953a657). https://bu...
Žan Doberšek
noreply at github.com
Wed Apr 12 07:12:46 PDT 2023
Branch: refs/heads/webkitglib/2.40
Home: https://github.com/WebKit/WebKit
Commit: 85145cad40821a072a047eb0bb3dccaefcfef049
https://github.com/WebKit/WebKit/commit/85145cad40821a072a047eb0bb3dccaefcfef049
Author: Sammy Gill <sammy.gill at apple.com>
Date: 2023-04-10 (Mon, 10 Apr 2023)
Changed paths:
M LayoutTests/TestExpectations
A LayoutTests/imported/w3c/web-platform-tests/html/rendering/replaced-elements/attributes-for-embedded-content-and-images/video-default-object-height-constrained-by-max-width-expected.html
A LayoutTests/imported/w3c/web-platform-tests/html/rendering/replaced-elements/attributes-for-embedded-content-and-images/video-default-object-height-constrained-by-max-width.html
A LayoutTests/imported/w3c/web-platform-tests/html/rendering/replaced-elements/attributes-for-embedded-content-and-images/video-default-object-width-constrained-by-max-height-expected.html
A LayoutTests/imported/w3c/web-platform-tests/html/rendering/replaced-elements/attributes-for-embedded-content-and-images/video-default-object-width-constrained-by-max-height.html
A LayoutTests/imported/w3c/web-platform-tests/html/rendering/replaced-elements/attributes-for-embedded-content-and-images/video-inline-size-containment-no-crash.html
M LayoutTests/imported/w3c/web-platform-tests/html/rendering/replaced-elements/attributes-for-embedded-content-and-images/video-intrinsic-width-height.html
M LayoutTests/platform/gtk/TestExpectations
M LayoutTests/platform/wpe/TestExpectations
M Source/WebCore/rendering/RenderReplaced.cpp
Log Message:
-----------
Cherry-pick 260851 at main (e6a31953a657). https://bugs.webkit.org/show_bug.cgi?id=252589
RenderReplaced::computeAspectRatioInformationForRenderBox does not need to call into RenderBox::computeReplacedLogicalWidth
https://bugs.webkit.org/show_bug.cgi?id=252589
rdar://105489410
Reviewed by Alan Baradlay.
The call to RenderBox::computeReplacedLogicalWidth from RenderReplaced::computeAspectRatioInformationForRenderBox
when the object was a video with a default object size was extraneous
and can be safely removed without changing any functionality. It could
also result in a stack overflow in certain conditions. At this
point we know the intrinsic sizes of the object anyway since it is a
video with a default object size (300px x 150px). This is
because:
1.) RenderBox::computeReplacedLogicalWidth would call into computeReplacedLogicalWidthUsing(MainOrPreferredSize, style().logicalWidth())
com compute the width value to use
2.) The caller (RenderReplaced::computeReplacedLogicalWidth in this case)
will only use the width value of style().logicalWidth().isAuto()
returns true.
3.) If this is true RenderBox::computeReplacedLogicalWidth would have
returned the intrinsic width but constrained to min/max sizes. However,
the caller constrains the intrinsic width anyway.
4.) If this is false (style().logicalWidth().isAuto() returns false),
then the caller (RenderReplaced::computeReplacedLogicalWidth) will
use the intrinsic width anyway by calling into intrinsicLogicalWidth.
We can also take advantage of the existing logic to constrain the
intrinsic sizes in each dimension by transferred constraints from the
opposite one.
Here is an example of when this extra call could cause a stack overflow:
<style>
video {
aspect-ratio: 1;
container-type: inline-size;
inset: 0 auto;
min-width: min-content;
position: fixed;
}
</style>
<video></video>
WebCore::RenderBox::computeReplacedLogicalWidthRespectingMinMaxWidth(WebCore::LayoutUnit, WebCore::ShouldComputePreferred) const
WebCore::RenderBox::computeReplacedLogicalWidth(WebCore::ShouldComputePreferred) const
WebCore::RenderReplaced::computeIntrinsicSizesConstrainedByTransferredMinMaxSizes(WebCore::RenderBox*, WebCore::FloatSize&, WebCore::FloatSize&) const
WebCore::RenderReplaced::computeReplacedLogicalHeight(std::__1::optional<WebCore::LayoutUnit>) const
WebCore::RenderImage::computeReplacedLogicalHeight(std::__1::optional<WebCore::LayoutUnit>) const
WebCore::RenderBox::computePositionedLogicalHeightReplaced(WebCore::RenderBox::LogicalExtentComputedValues&) const
WebCore::RenderBox::computePositionedLogicalHeight(WebCore::RenderBox::LogicalExtentComputedValues&) const
WebCore::RenderBox::computeLogicalHeight(WebCore::LayoutUnit, WebCore::LayoutUnit) const
WebCore::RenderBox::computeLogicalWidthFromAspectRatioInternal() const
WebCore::RenderBox::computeIntrinsicLogicalWidthUsing(WebCore::Length, WebCore::LayoutUnit, WebCore::LayoutUnit) const
WebCore::RenderBox::computeReplacedLogicalWidthUsing(WebCore::SizeType, WebCore::Length) const
WebCore::RenderBox::computeReplacedLogicalWidthRespectingMinMaxWidth(WebCore::LayoutUnit, WebCore::ShouldComputePreferred) const
WebCore::RenderVideo::computeReplacedLogicalWidth(WebCore::ShouldComputePreferred) const
WebCore::RenderBox::computePositionedLogicalWidthReplaced(WebCore::RenderBox::LogicalExtentComputedValues&) const
WebCore::RenderBox::computePositionedLogicalWidth(WebCore::RenderBox::LogicalExtentComputedValues&, WebCore::RenderFragmentContainer*) const
WebCore::RenderBox::computeLogicalWidthInFragment(WebCore::RenderBox::LogicalExtentComputedValues&, WebCore::RenderFragmentContainer*) const
WebCore::RenderBox::updateLogicalWidth()
WebCore::RenderReplaced::layout()
WebCore::RenderImage::layout()
WebCore::RenderMedia::layout()
WebCore::RenderVideo::layout()
After we have computed the width for the video, we call RenderBox::RenderBox::computeReplacedLogicalWidthRespectingMinMaxWidth
to restrict it within any min and max constraints. This eventually calls into RenderBox::computeIntrinsicLogicalWidthUsing to compute the
min-width using MinContent as the width type.
The container-type: inline-size; and inset: 0 auto; properties cause RenderBox::shouldComputeLogicalWidthFromAspectRatio to return true
because the call to shouldComputeLogicalWidthFromAspectRatioAndInsets returns true. This last method returns true because:
1.) Applying the inline size containment causes hasConstrainedWidth to be false when it would normally be true from the video’s intrinsic width.
2.) hasConstrainedHeight gets set to false because inset causes the logical top and property values to get set to a fixed value
3.) The final call to style.logicalHeight().isAuto() returns true
Due to these series of events we end up calling computeLogicalWidthFromAspectRatioInternal inside RenderBox::computeIntrinsicLogicalWidthUsing.
This eventually recurses its way back into RenderBox::computeReplacedLogicalWidthRespectingMinMaxWidth through the reset of the stack trace.
* LayoutTests/TestExpectations:
* LayoutTests/imported/w3c/web-platform-tests/html/rendering/replaced-elements/attributes-for-embedded-content-and-images/video-default-object-height-constrained-by-max-width-expected.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/html/rendering/replaced-elements/attributes-for-embedded-content-and-images/video-default-object-height-constrained-by-max-width.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/html/rendering/replaced-elements/attributes-for-embedded-content-and-images/video-default-object-width-constrained-by-max-height-expected.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/html/rendering/replaced-elements/attributes-for-embedded-content-and-images/video-default-object-width-constrained-by-max-height.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/html/rendering/replaced-elements/attributes-for-embedded-content-and-images/video-inline-size-containment-no-crash.html: Added.
This test currently crashes due to a different reason (webkit.org/b/252594),
but is still useful to this patch as it was causing the stack
overflow.
* LayoutTests/imported/w3c/web-platform-tests/html/rendering/replaced-elements/attributes-for-embedded-content-and-images/video-intrinsic-width-height.html:
One of the test cases was incorrectly changed in a previous patch and
is being restored to its previous version. The height for this test
should be 150px and not 300px because it falls under the case:
If 'height' and 'width' both have computed values of 'auto' and the
element also has an intrinsic height, then that intrinsic height is
the used value of 'height'.
https://www.w3.org/TR/CSS22/visudet.html#inline-replaced-height
* LayoutTests/platform/gtk/TestExpectations:
* LayoutTests/platform/wpe/TestExpectations:
* Source/WebCore/rendering/RenderReplaced.cpp:
(WebCore::RenderReplaced::computeIntrinsicSizesConstrainedByTransferredMinMaxSizes const):
Canonical link: https://commits.webkit.org/260851@main
Commit: 0d676f9ae9c77b61e85591511cac8fe1dc733a5d
https://github.com/WebKit/WebKit/commit/0d676f9ae9c77b61e85591511cac8fe1dc733a5d
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2023-04-12 (Wed, 12 Apr 2023)
Changed paths:
M Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.cpp
M Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.h
M Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/LayerTreeHost.cpp
M Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/LayerTreeHost.h
M Source/WebKit/WebProcess/WebPage/DrawingArea.h
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
Log Message:
-----------
Cherry-pick 262812 at main (f938f81c9a7b). https://bugs.webkit.org/show_bug.cgi?id=255221
REGRESSION(262572 at main): [GTK] No contents renderer after process swap for navigation
https://bugs.webkit.org/show_bug.cgi?id=255221
Reviewed by Žan Doberšek.
In case of process swap current drawing area is destroyed causing the AC
mode to be exited, and the new drawing area sends the enter AC message
before the UI process has switched drawing areas, so the message is just
ignored. To be able to enter AC mode from the DrawingArea constructor
this patch removes the enablePainting methods, since it's always called
right after the drawing area is crewated and only used by coordinated
graphics drawing area.
* Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.cpp:
(WebKit::DrawingAreaCoordinatedGraphics::DrawingAreaCoordinatedGraphics): Enter AC mode here when always compositing.
(WebKit::DrawingAreaCoordinatedGraphics::setNeedsDisplayInRect): Remove painting enabled check.
(WebKit::DrawingAreaCoordinatedGraphics::scroll): Ditto.
(WebKit::DrawingAreaCoordinatedGraphics::forceRepaint): Ditto.
(WebKit::DrawingAreaCoordinatedGraphics::updatePreferences): Update async scrolling enabled here.
(WebKit::DrawingAreaCoordinatedGraphics::enterAcceleratedCompositingMode): Create the LayerTreeHost with the display ID
so that LayerTreeHost doesn't need to access the page drawing area that is being created.
(WebKit::DrawingAreaCoordinatedGraphics::sendEnterAcceleratedCompositingModeIfNeeded): Implement this.
(WebKit::DrawingAreaCoordinatedGraphics::enablePainting): Deleted.
* Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.h:
* Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/LayerTreeHost.cpp:
(WebKit::LayerTreeHost::LayerTreeHost): Use the given display ID.
* Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/LayerTreeHost.h:
* Source/WebKit/WebProcess/WebPage/DrawingArea.h:
(WebKit::DrawingArea::enablePainting): Deleted.
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::reinitializeWebPage): Remove enablePainting calls.
* Source/WebKit/WebProcess/WebPage/gtk/AcceleratedSurfaceDMABuf.cpp:
(WebKit::AcceleratedSurfaceDMABuf::didCreateGLContext): Do not resize
here that is too early in some cases, wait for the first frame to do the
resize.
Canonical link: https://commits.webkit.org/262812@main
Commit: dd32d56443016ea91d75a2aacd421155ae72ded3
https://github.com/WebKit/WebKit/commit/dd32d56443016ea91d75a2aacd421155ae72ded3
Author: Jean-Yves Avenard <jya at apple.com>
Date: 2023-04-12 (Wed, 12 Apr 2023)
Changed paths:
A LayoutTests/media/media-source/media-source-appendbuffer-durationchange-expected.txt
A LayoutTests/media/media-source/media-source-appendbuffer-durationchange.html
M Source/WebCore/Modules/mediasource/SourceBuffer.cpp
M Source/WebCore/Modules/mediasource/SourceBuffer.h
M Source/WebCore/platform/graphics/SourceBufferPrivate.cpp
M Source/WebCore/platform/graphics/SourceBufferPrivate.h
M Source/WebCore/platform/graphics/SourceBufferPrivateClient.h
M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.h
M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm
M Source/WebCore/platform/graphics/gstreamer/mse/AppendPipeline.cpp
M Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.cpp
M Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.h
M Source/WebCore/platform/mock/mediasource/MockSourceBufferPrivate.cpp
M Source/WebKit/GPUProcess/media/RemoteSourceBufferProxy.cpp
M Source/WebKit/GPUProcess/media/RemoteSourceBufferProxy.h
M Source/WebKit/WebProcess/GPU/media/SourceBufferPrivateRemote.cpp
M Source/WebKit/WebProcess/GPU/media/SourceBufferPrivateRemote.h
M Source/WebKit/WebProcess/GPU/media/SourceBufferPrivateRemote.messages.in
Log Message:
-----------
Cherry-pick 261029 at main (04a684748a69). https://bugs.webkit.org/show_bug.cgi?id=252886
[MSE] Only fire durationchange after parsing media buffer.
https://bugs.webkit.org/show_bug.cgi?id=252886
rdar://105870526
Reviewed by Youenn Fablet and Jer Noble.
Per spec MSE spec and the Coded Frame Processing algorithm [1]
"5. if the media segment contains data beyond the current duration, then
run the duration change algorithm with new duration set to the maximum of
the current duration and the [[group end timestamp]]."
Which occurs once all frames of a media segment added to a source buffer have been processed.
We were running step 5. after each frame parsed.
Only perform step 5. once we have parsed the entire buffer.
Note: Per spec, we should be firing a durationchange event after parsing
each individual media segment.
However, our data parsing infrastucture doesn't provide such level of details
and we can only parse the entire buffer (potentially made of multiple media segments)
at once, so we only fire a single durationchange in all cases.
However, this behaviour is preferable to firing hundreds of events unnecessarily.
The handling of a `durationchange` must occur before the `updateend` is
fired, so we make the method sourceBufferPrivateDurationChanged asynchronous
and continue the process once the it completes.
[1] https://w3c.github.io/media-source/#sourcebuffer-coded-frame-processing
* LayoutTests/media/media-source/media-source-appendbuffer-durationchange-expected.txt: Added.
* LayoutTests/media/media-source/media-source-appendbuffer-durationchange.html: Added.
* Source/WebCore/Modules/mediasource/SourceBuffer.cpp:
(WebCore::SourceBuffer::sourceBufferPrivateDurationChanged):
* Source/WebCore/Modules/mediasource/SourceBuffer.h:
* Source/WebCore/platform/graphics/SourceBufferPrivate.cpp:
(WebCore::SourceBufferPrivate::appendCompleted): Must be called once all samples have been processed.
(WebCore::SourceBufferPrivate::didReceiveSample):
* Source/WebCore/platform/graphics/SourceBufferPrivate.h:
* Source/WebCore/platform/graphics/SourceBufferPrivateClient.h:
* Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.h:
* Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm:
(WebCore::MediaPlayerPrivateMediaSourceAVFObjC::durationChanged):
* Source/WebCore/platform/graphics/gstreamer/mse/AppendPipeline.cpp:
(WebCore::AppendPipeline::consumeAppsinksAvailableSamples):
* Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.cpp:
(WebCore::MediaPlayerPrivateGStreamerMSE::durationChanged): Remove handling of longer needed blockDurationChanges/unblockDurationChanges
(WebCore::MediaPlayerPrivateGStreamerMSE::blockDurationChanges): Deleted.
(WebCore::MediaPlayerPrivateGStreamerMSE::unblockDurationChanges): Deleted.
* Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.h:
* Source/WebCore/platform/mock/mediasource/MockSourceBufferPrivate.cpp:
(WebCore::MockSourceBufferPrivate::append): Call appendCompleted.
* Source/WebKit/GPUProcess/media/RemoteSourceBufferProxy.cpp:
(WebKit::RemoteSourceBufferProxy::sourceBufferPrivateDurationChanged):
* Source/WebKit/GPUProcess/media/RemoteSourceBufferProxy.h:
* Source/WebKit/WebProcess/GPU/media/SourceBufferPrivateRemote.cpp:
(WebKit::SourceBufferPrivateRemote::sourceBufferPrivateDurationChanged):
* Source/WebKit/WebProcess/GPU/media/SourceBufferPrivateRemote.h:
* Source/WebKit/WebProcess/GPU/media/SourceBufferPrivateRemote.messages.in:
Canonical link: https://commits.webkit.org/261029@main
Commit: 6c97713d1ec616f25c6ce20cd82c34a3ac9098ec
https://github.com/WebKit/WebKit/commit/6c97713d1ec616f25c6ce20cd82c34a3ac9098ec
Author: ChangSeok Oh <changseok at webkit.org>
Date: 2023-04-12 (Wed, 12 Apr 2023)
Changed paths:
M LayoutTests/fast/css-generated-content/initial-letter-first-line-wrapping-expected.html
M LayoutTests/platform/glib/TestExpectations
M LayoutTests/platform/glib/fast/text/combining-enclosing-keycap-expected.txt
M LayoutTests/platform/gtk/fast/css-generated-content/initial-letter-basic-expected.txt
M LayoutTests/platform/gtk/fast/css-generated-content/initial-letter-border-padding-expected.txt
M LayoutTests/platform/gtk/fast/css-generated-content/initial-letter-clearance-expected.txt
M LayoutTests/platform/gtk/fast/css-generated-content/initial-letter-descender-expected.txt
M LayoutTests/platform/gtk/fast/css-generated-content/initial-letter-raised-expected.txt
M LayoutTests/platform/gtk/fast/css-generated-content/initial-letter-sunken-expected.txt
M LayoutTests/platform/wpe/fast/css-generated-content/initial-letter-basic-expected.txt
M LayoutTests/platform/wpe/fast/css-generated-content/initial-letter-border-padding-expected.txt
M LayoutTests/platform/wpe/fast/css-generated-content/initial-letter-clearance-expected.txt
M LayoutTests/platform/wpe/fast/css-generated-content/initial-letter-descender-expected.txt
M LayoutTests/platform/wpe/fast/css-generated-content/initial-letter-raised-expected.txt
M LayoutTests/platform/wpe/fast/css-generated-content/initial-letter-sunken-expected.txt
M Source/WebCore/platform/graphics/freetype/SimpleFontDataFreeType.cpp
Log Message:
-----------
Cherry-pick 262860 at main (eb50f369243c). https://bugs.webkit.org/show_bug.cgi?id=255082
Cap height is incorrect on platforms using FreeType.
https://bugs.webkit.org/show_bug.cgi?id=255082
Reviewed by Carlos Garcia Campos.
FreeType platforms use the height of cairo_font_extents_t as cap-height
for the given font. Unfortunately, that is not the cap-height we want. According
to the Cairo document [1], cairo_font_extents_t.height is the vertical distance
between baselines, which contains ascent, descent, and some margin. That is far
from the cap-height the CSS standard defines [2], and results in the failure of
font-size-adjust-009.html.
To fix this, we use the cap-height FreeType provided since its version 2 [3].
As we did for x-height, we fall back to cairo_text_extends_t if we cannot get
the cap-height from FreeType.
[1] https://www.cairographics.org/manual/cairo-cairo-scaled-font-t.html#cairo-font-extents-t
[2] https://www.w3.org/TR/css-values-4/#font-relative-lengths
[3] https://freetype.org/freetype2/docs/reference/ft2-truetype_tables.html#tt_os2
The following tests are manually verified by matching the results to ones of the mac port.
Test:
+ imported/w3c/web-platform-tests/css/css-fonts/font-size-adjust-009.html
+ fast/css-generated-content/initial-letter-basic.html
+ fast/css-generated-content/initial-letter-border-padding.html
+ fast/css-generated-content/initial-letter-clearance.html
+ fast/css-generated-content/initial-letter-descender.html
* fast/css-generated-content/initial-letter-first-line-wrapping.html:
+ fast/css-generated-content/initial-letter-raised.html
+ fast/css-generated-content/initial-letter-sunken.html
* fast/text/combining-enclosing-keycap.html
The following tests are marked as expected image test failures. Before this patch,
they passed because they rendered nothing (i.e., an empty page) due to inaccurate
font heights. To make them pass, custom fonts (e.g., color fonts) via
@font-face: font-family should work for Canvas. We handle them in a separate bug.
- http/tests/canvas/color-fonts/ctm-sbix.html
- http/tests/canvas/color-fonts/fill-color-sbix.html
- http/tests/canvas/color-fonts/fill-gradient-sbix.html
- http/tests/canvas/color-fonts/linedash-sbix.html
- http/tests/canvas/color-fonts/stroke-gradient-sbix.html
- http/tests/canvas/color-fonts/text-sbix.html
* LayoutTests/fast/css-generated-content/initial-letter-first-line-wrapping-expected.html: Updated.
* LayoutTests/platform/glib/TestExpectations:
* LayoutTests/platform/glib/fast/text/combining-enclosing-keycap-expected.txt: Updated.
* LayoutTests/platform/gtk/fast/css-generated-content/initial-letter-basic-expected.txt: Updated.
* LayoutTests/platform/gtk/fast/css-generated-content/initial-letter-border-padding-expected.txt: Updated.
* LayoutTests/platform/gtk/fast/css-generated-content/initial-letter-clearance-expected.txt: Updated.
* LayoutTests/platform/gtk/fast/css-generated-content/initial-letter-descender-expected.txt: Updated.
* LayoutTests/platform/gtk/fast/css-generated-content/initial-letter-raised-expected.txt: Updated.
* LayoutTests/platform/gtk/fast/css-generated-content/initial-letter-sunken-expected.txt: Updated.
* LayoutTests/platform/wpe/fast/css-generated-content/initial-letter-basic-expected.txt: Updated.
* LayoutTests/platform/wpe/fast/css-generated-content/initial-letter-border-padding-expected.txt: Updated.
* LayoutTests/platform/wpe/fast/css-generated-content/initial-letter-clearance-expected.txt: Updated.
* LayoutTests/platform/wpe/fast/css-generated-content/initial-letter-descender-expected.txt: Updated.
* LayoutTests/platform/wpe/fast/css-generated-content/initial-letter-raised-expected.txt: Updated.
* LayoutTests/platform/wpe/fast/css-generated-content/initial-letter-sunken-expected.txt: Updated.
* Source/WebCore/platform/graphics/freetype/SimpleFontDataFreeType.cpp:
(WebCore::heightOfCharacter):
(WebCore::Font::platformInit):
Canonical link: https://commits.webkit.org/262860@main
Commit: 022deb9fb3d4e398fc3d0e04e83b8979a6aec152
https://github.com/WebKit/WebKit/commit/022deb9fb3d4e398fc3d0e04e83b8979a6aec152
Author: Xabier Rodriguez-Calvar <calvaris at igalia.com>
Date: 2023-04-12 (Wed, 12 Apr 2023)
Changed paths:
M Source/WebCore/testing/MockCDMFactory.cpp
Log Message:
-----------
Cherry-pick 262819 at main (cc44de0d9d44). https://bugs.webkit.org/show_bug.cgi?id=251550
[EME] media/encrypted-media/mock-MediaKeySession-generateRequest.html is a flaky crash
https://bugs.webkit.org/show_bug.cgi?id=251550
Reviewed by Jer Noble.
We need to bail out with empty IDs.
* Source/WebCore/testing/MockCDMFactory.cpp:
(WebCore::MockCDMFactory::hasSessionWithID):
(WebCore::MockCDMFactory::removeSessionWithID):
Canonical link: https://commits.webkit.org/262819@main
Commit: 6af74a5b3420ea418cf5c5d1ed7b7103812a4d93
https://github.com/WebKit/WebKit/commit/6af74a5b3420ea418cf5c5d1ed7b7103812a4d93
Author: Carlos Garcia Campos <cgarcia at igalia.com>
Date: 2023-04-12 (Wed, 12 Apr 2023)
Changed paths:
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
Log Message:
-----------
Cherry-pick 262867 at main (b762cdb7aea0). https://bugs.webkit.org/show_bug.cgi?id=255330
REGRESSION(262812 at main): [CoordinatedGraphics] Contents rendered at the wrong size in HiDPI
https://bugs.webkit.org/show_bug.cgi?id=255330
Reviewed by Adrian Perez de Castro.
Since 262812 at main we are creating the accelerated surface from drawing
area constructor, but WebPage is setting the device scale factor after
creating the drawing area, so we end up using the unscaled size.
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::m_appHighlightsVisible): Set the device scale factor before creating the drawing area.
Canonical link: https://commits.webkit.org/262867@main
Commit: aec6f0d4ff2c8f04c2a7e585f993a7b1b36fa444
https://github.com/WebKit/WebKit/commit/aec6f0d4ff2c8f04c2a7e585f993a7b1b36fa444
Author: Mark Lam <mark.lam at apple.com>
Date: 2023-04-12 (Wed, 12 Apr 2023)
Changed paths:
M Source/JavaScriptCore/heap/Heap.cpp
M Source/JavaScriptCore/heap/Heap.h
M Source/JavaScriptCore/heap/HeapInlines.h
M Source/JavaScriptCore/runtime/ArgList.cpp
M Source/JavaScriptCore/runtime/ArgList.h
M Source/WebCore/Modules/webaudio/AudioWorkletProcessor.cpp
M Source/WebCore/Modules/webaudio/AudioWorkletProcessor.h
M Source/WebCore/bindings/js/SerializedScriptValue.cpp
Log Message:
-----------
Cherry-pick 259548.395 at safari-7615.1.26.11-branch (1039f0c3235f). https://bugs.webkit.org/show_bug.cgi?id=254797
Cherry-pick 2c49ff7b0481. rdar://problem/107369977
CloneDeserializer::deserialize() should store cell pointers in a MarkedVector.
https://bugs.webkit.org/show_bug.cgi?id=254797
rdar://107369977
Reviewed by Justin Michaud.
Previously, CloneDeserializer::deserialize() was storing pointers to newly created objects
in a few Vectors. This is problematic because the GC is not aware of Vectors, and cannot
scan them. In this patch, we refactor the MarkedArgumentBuffer class into a MarkedVector
template class that offer 2 enhancements:
1. It can be configured to store specific types of cell pointer types. This avoids us
having to constantly cast JSValues into these pointers.
2. It allows us to specify the type of OverflowHandler we want to use. In this case,
we want to use CrashOnOverflow. The previous MarkedArgumentBuffer always assumes
RecordOnOverflow. This allows us to avoid having to manually check for overflows,
or have to use appendWithCrashOnOverflow. For our current needs, MarkedVector can be
used as a drop in replacement for Vector.
And we fix the CloneDeserializer::deserialize() issue by replacing the use of Vectors
with MarkedVector instead.
* Source/JavaScriptCore/heap/Heap.cpp:
(JSC::Heap::addCoreConstraints):
* Source/JavaScriptCore/heap/Heap.h:
* Source/JavaScriptCore/heap/HeapInlines.h:
* Source/JavaScriptCore/runtime/ArgList.cpp:
(JSC::MarkedVectorBase::addMarkSet):
(JSC::MarkedVectorBase::markLists):
(JSC::MarkedVectorBase::slowEnsureCapacity):
(JSC::MarkedVectorBase::expandCapacity):
(JSC::MarkedVectorBase::slowAppend):
(JSC::MarkedArgumentBufferBase::addMarkSet): Deleted.
(JSC::MarkedArgumentBufferBase::markLists): Deleted.
(JSC::MarkedArgumentBufferBase::slowEnsureCapacity): Deleted.
(JSC::MarkedArgumentBufferBase::expandCapacity): Deleted.
(JSC::MarkedArgumentBufferBase::slowAppend): Deleted.
* Source/JavaScriptCore/runtime/ArgList.h:
(JSC::MarkedVectorWithSize::MarkedVectorWithSize):
(JSC::MarkedVectorWithSize::at const):
(JSC::MarkedVectorWithSize::clear):
(JSC::MarkedVectorWithSize::append):
(JSC::MarkedVectorWithSize::appendWithCrashOnOverflow):
(JSC::MarkedVectorWithSize::last const):
(JSC::MarkedVectorWithSize::takeLast):
(JSC::MarkedVectorWithSize::ensureCapacity):
(JSC::MarkedVectorWithSize::hasOverflowed):
(JSC::MarkedVectorWithSize::fill):
(JSC::MarkedArgumentBufferWithSize::MarkedArgumentBufferWithSize): Deleted.
* Source/WebCore/Modules/webaudio/AudioWorkletProcessor.cpp:
(WebCore::AudioWorkletProcessor::buildJSArguments):
* Source/WebCore/Modules/webaudio/AudioWorkletProcessor.h:
* Source/WebCore/bindings/js/SerializedScriptValue.cpp:
(WebCore::CloneDeserializer::deserialize):
Canonical link: https://commits.webkit.org/259548.530@safari-7615-branch
Identifier: 259548.395 at safari-7615.1.26.11-branch
Commit: de3f899c022bc428d293fe824ee0b38a00776249
https://github.com/WebKit/WebKit/commit/de3f899c022bc428d293fe824ee0b38a00776249
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2023-04-12 (Wed, 12 Apr 2023)
Changed paths:
A LayoutTests/fast/forms/select/selected-option-update-inner-html-expected.html
A LayoutTests/fast/forms/select/selected-option-update-inner-html.html
M Source/WebCore/html/HTMLSelectElement.cpp
Log Message:
-----------
Cherry-pick 262791 at main (d86fed1a2d3d). https://bugs.webkit.org/show_bug.cgi?id=255230
REGRESSION (255086 at main): Safari 16.4 and above does not render <option> label/text updates until <select> is focused
https://bugs.webkit.org/show_bug.cgi?id=255230
rdar://107838336
Reviewed by Chris Dumez.
255086 at main removed the call to `HTMLSelectElement::setRecalcListItems` in
`HTMLSelectElement::optionElementChildrenChanged` so that updating the text
inside an <option> element does not reset the <select> element's selected option.
However, this broke rendering of the option's new text, since
`setRecalcListItems` contained logic to update the rendered text. Fix by
reintroducing the logic that is responsible for ensuring the displayed text
matches the <option> element's text.
Add a regression (reference) test which would have caught this issue.
* LayoutTests/fast/forms/select/selected-option-update-inner-html-expected.html: Added.
* LayoutTests/fast/forms/select/selected-option-update-inner-html.html: Added.
* Source/WebCore/html/HTMLSelectElement.cpp:
(WebCore::HTMLSelectElement::optionElementChildrenChanged):
Canonical link: https://commits.webkit.org/262791@main
Commit: 362435471d740951b38ca67d29ee1e6196c13513
https://github.com/WebKit/WebKit/commit/362435471d740951b38ca67d29ee1e6196c13513
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-04-12 (Wed, 12 Apr 2023)
Changed paths:
M Source/WebKit/Shared/Cocoa/SandboxExtensionCocoa.mm
M Source/WebKit/UIProcess/WebProcessPool.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm
Log Message:
-----------
Cherry-pick 262709 at main (2dbbdbf493db). https://bugs.webkit.org/show_bug.cgi?id=255102
REGRESSION (iOS 16.4): Chrome crashes in WebBackForwardCache::takeSuspendedPage
https://bugs.webkit.org/show_bug.cgi?id=255102
rdar://107723629
Reviewed by Geoffrey Garen.
We recently added an AddAllowedFirstPartyForCookies async IPC call inside
WebProcessPool::processForNavigation(), right after we decide which process to
use. Because the IPC is async, this means that the selected process may crash
while we're waiting for a response. If this happens, we now call
processForNavigation() again to select a new process instead of trying to
proceed with the navigation with the terminated process.
Similarly, also make sure that the destination suspendedPage is still valid
after receiving the async IPC, in case the back/forward cache got cleared
during the IPC (e.g. due to memory pressure).
* Source/WebKit/UIProcess/WebProcessPool.cpp:
(WebKit::WebProcessPool::processForNavigation):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm:
Canonical link: https://commits.webkit.org/262709@main
Commit: 66ca744d21b55de0c00f39c10c087cc0d5c417da
https://github.com/WebKit/WebKit/commit/66ca744d21b55de0c00f39c10c087cc0d5c417da
Author: Alexey Shvayka <ashvayka at apple.com>
Date: 2023-04-12 (Wed, 12 Apr 2023)
Changed paths:
M LayoutTests/imported/w3c/web-platform-tests/css/selectors/user-invalid-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/css/selectors/user-invalid.html
M LayoutTests/imported/w3c/web-platform-tests/css/selectors/user-valid-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/css/selectors/user-valid.html
A LayoutTests/platform/ios-wk2/imported/w3c/web-platform-tests/css/selectors/user-invalid-expected.txt
A LayoutTests/platform/ios-wk2/imported/w3c/web-platform-tests/css/selectors/user-valid-expected.txt
M Source/WebCore/html/HTMLFormControlElement.h
Log Message:
-----------
Cherry-pick 262512 at main (bc8d5b0f582f). https://bugs.webkit.org/show_bug.cgi?id=254571
REGRESSION(258561 at main): :user-valid/:user-invalid stopped working
https://bugs.webkit.org/show_bug.cgi?id=254571
<rdar://problem/107300848>
Reviewed by Tim Nguyen.
This change adds missing virtual method overrides to fix :user-valid / :user-invalid
pseudoclasses, similar to those we have for :valid / :invalid.
They are necessary because ValidatedFormListedElement doesn't inherit from Element.
* LayoutTests/imported/w3c/web-platform-tests/css/selectors/user-invalid-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/css/selectors/user-invalid.html:
* LayoutTests/imported/w3c/web-platform-tests/css/selectors/user-valid-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/css/selectors/user-valid.html:
* LayoutTests/platform/ios-wk2/imported/w3c/web-platform-tests/css/selectors/user-invalid-expected.txt:
* LayoutTests/platform/ios-wk2/imported/w3c/web-platform-tests/css/selectors/user-valid-expected.txt:
* Source/WebCore/html/HTMLFormControlElement.h:
Co-authored-by: Tim Nguyen <ntim at apple.com>
Canonical link: https://commits.webkit.org/262512@main
Commit: c583baa9fe9bedb616592580ceae32dad898a880
https://github.com/WebKit/WebKit/commit/c583baa9fe9bedb616592580ceae32dad898a880
Author: Žan Doberšek <zdobersek at igalia.com>
Date: 2023-04-12 (Wed, 12 Apr 2023)
Changed paths:
M Source/WebCore/platform/graphics/SourceBrush.cpp
M Source/WebCore/platform/graphics/SourceBrush.h
M Source/WebKit/Platform/IPC/ArgumentCoders.h
Log Message:
-----------
Cherry-pick 262339 at main (fd977228c791). https://bugs.webkit.org/show_bug.cgi?id=254742
Build fix around std::variant in SourceBrush for Clang/libstdc++
https://bugs.webkit.org/show_bug.cgi?id=254742
Unreviewed, build fix for the SourceBrush::Brush std::variant construction when
using Clang with libstdc++.
Things get mixed up when using Ref<Pattern> for constructing the variant, with
the compiler using it as initialization for the LogicalGradient type, the other
possible type in the variant, which ends up in a compile-time error.
This can be avoided by using the in-place tag when constructing the variant in
the SourceBrush::setPattern() method, specifying which variant-alternative type
should be used.
Similar fix for the same reasons is also needed in the decoding part of the
ArgumentCoder<std::variant<>> specialization, this being problematic due to the
SourceBrush::Brush decoding produced for the generated serializers purpose.
There the variant is constructed with the in-place tag that's based on the index
value of the alternative.
* Source/WebCore/platform/graphics/SourceBrush.cpp:
(WebCore::SourceBrush::setPattern):
* Source/WebCore/platform/graphics/SourceBrush.h:
* Source/WebKit/Platform/IPC/ArgumentCoders.h:
Canonical link: https://commits.webkit.org/262339@main
Compare: https://github.com/WebKit/WebKit/compare/2804afc60700...c583baa9fe9b
More information about the webkit-changes
mailing list