[webkit-changes] [WebKit/WebKit] 866102: [JSC] add JSFunction::nameWithoutGC

2023-05-20 Thread Yusuke Suzuki
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 8661025c07ae37a7fecab656ea5d5fce16c2c293
  
https://github.com/WebKit/WebKit/commit/8661025c07ae37a7fecab656ea5d5fce16c2c293
  Author: Yusuke Suzuki 
  Date:   2023-05-20 (Sat, 20 May 2023)

  Changed paths:
A JSTests/stress/error-bound-function.js
M Source/JavaScriptCore/runtime/JSBoundFunction.cpp
M Source/JavaScriptCore/runtime/JSBoundFunction.h
M Source/JavaScriptCore/runtime/JSFunction.cpp
M Source/JavaScriptCore/runtime/JSFunction.h

  Log Message:
  ---
  [JSC] add JSFunction::nameWithoutGC
https://bugs.webkit.org/show_bug.cgi?id=257091
rdar://109614514

Reviewed by Keith Miller.

This patch does not change the production behavior, but it adds 
JSFunction::nameWithoutGC
to make it extra robust against ErrorInstance's stack cleaning up in GC end 
phase, which
must not cause any GC activity. Right now, JSBoundFunction::name can cause GC, 
but JSBoundFunction
was never listed in the error stack (so there is no problem), but let's make 
this invariant
clear for ErrorInstance to defend against the future possible extension.

* JSTests/stress/error-bound-function.js: Added.
(throwing):
(test):
(calling):
(i.catch):
* Source/JavaScriptCore/runtime/JSBoundFunction.cpp:
(JSC::JSBoundFunction::nameStringWithoutGCSlow):
* Source/JavaScriptCore/runtime/JSBoundFunction.h:
* Source/JavaScriptCore/runtime/JSFunction.cpp:
(JSC::JSFunction::nameWithoutGC):
(JSC::getCalculatedDisplayName):
* Source/JavaScriptCore/runtime/JSFunction.h:

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


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes


[webkit-changes] [WebKit/WebKit] f9cc49: [image-set] Handle zero resolution and clamping ne...

2023-05-20 Thread Ryan Reno
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: f9cc497c0b28ee7d1ca98585b072107d0e44f37b
  
https://github.com/WebKit/WebKit/commit/f9cc497c0b28ee7d1ca98585b072107d0e44f37b
  Author: Ryan Reno 
  Date:   2023-05-20 (Sat, 20 May 2023)

  Changed paths:
M LayoutTests/TestExpectations
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-negative-resolution-rendering-2.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-negative-resolution-rendering-3-expected.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-negative-resolution-rendering-3.html
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-negative-resolution-rendering-expected.html
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-negative-resolution-rendering.html
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-parsing-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-parsing.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-zero-resolution-rendering-2-expected.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-zero-resolution-rendering-2.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-zero-resolution-rendering-expected.html
A 
LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-zero-resolution-rendering.html
M Source/WebCore/css/parser/CSSPropertyParserHelpers.cpp
M Source/WebCore/rendering/style/StyleImageSet.cpp

  Log Message:
  ---
  [image-set] Handle zero resolution and clamping negative resolutions in calc 
expressions
https://bugs.webkit.org/show_bug.cgi?id=254388
rdar://107167273

Reviewed by Tim Nguyen.

In a CSSWG resolution it was decided that zero resolutions should be
accepted by image-set but that they should produce an invalid image.
This change accepts zero but will reject negative resolutions. In a
follow-up we should clamp the result of calc expressions to zero.

This change also resyncs the image-set WPT as of upstream commit
c56aec60503481604225fdb7705f67d82ce437b8

https://github.com/w3c/csswg-drafts/issues/8532#issuecomment-1499478038

* LayoutTests/TestExpectations:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-negative-resolution-rendering-2.html:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-negative-resolution-rendering-3-expected.html:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-negative-resolution-rendering-3.html:
 Copied from 
LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-negative-resolution-rendering.html.
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-negative-resolution-rendering-expected.html:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-negative-resolution-rendering.html:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-parsing-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-parsing.html:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-zero-resolution-rendering-2-expected.html:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-zero-resolution-rendering-2.html:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-zero-resolution-rendering-expected.html:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-images/image-set/image-set-zero-resolution-rendering.html:
 Added.

* Source/WebCore/css/parser/CSSPropertyParserHelpers.cpp:
(WebCore::CSSPropertyParserHelpers::consumeImageSetOption):
* Source/WebCore/rendering/style/StyleImageSet.cpp:
(WebCore::StyleImageSet::bestImageForScaleFactor):

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


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes


[webkit-changes] [WebKit/WebKit] f0847a: RemoteLayerTreeDisplayRefreshMonitor::requestRefre...

2023-05-20 Thread mattwoodrow
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: f0847a50740a2e312af43140a1c7bce1d0b941ff
  
https://github.com/WebKit/WebKit/commit/f0847a50740a2e312af43140a1c7bce1d0b941ff
  Author: Matt Woodrow 
  Date:   2023-05-20 (Sat, 20 May 2023)

  Changed paths:
M 
Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDisplayRefreshMonitor.mm
M 
Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.h

  Log Message:
  ---
  RemoteLayerTreeDisplayRefreshMonitor::requestRefreshCallback doesn't clear 
scheduled state.
https://bugs.webkit.org/show_bug.cgi?id=257004


Reviewed by Simon Fraser.

RemoteLayerTreeDisplayRefreshMonitor::requestRefreshCallback dispatches a task 
to the main thread and sets scheduled to true.

When that task runs, it triggers the rendering update but doesn't set scheduled 
back to false.

Normally, the rendering update results in a commit to the UI process, and then 
we get a RemoteLayerTreeDrawingArea::displayDidRefresh callback, which sets 
scheduled to false (but also triggers a second rendering update)

This makes it more clear as to whether we're dispatching a task, or waiting for 
a pending displayDidRefresh in order to schedule a refresh callback, and sets 
the scheduled state correctly.

* 
Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDisplayRefreshMonitor.mm:
(WebKit::RemoteLayerTreeDisplayRefreshMonitor::requestRefreshCallback):
(WebKit::RemoteLayerTreeDisplayRefreshMonitor::triggerDisplayDidRefresh):
* Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.h:
(WebKit::RemoteLayerTreeDrawingArea::displayDidRefreshIsPending const):

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


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes


[webkit-changes] [WebKit/WebKit] 09468e: [JSC] ARM64 Imm should accept -UInt12

2023-05-20 Thread Yusuke Suzuki
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 09468ef2b3b3474e17c023ad0d02c9fd087bf2ee
  
https://github.com/WebKit/WebKit/commit/09468ef2b3b3474e17c023ad0d02c9fd087bf2ee
  Author: Yusuke Suzuki 
  Date:   2023-05-20 (Sat, 20 May 2023)

  Changed paths:
M Source/JavaScriptCore/assembler/MacroAssemblerARM64.h
M Source/JavaScriptCore/b3/B3MoveConstants.cpp
M Source/JavaScriptCore/b3/air/AirArg.h

  Log Message:
  ---
  [JSC] ARM64 Imm should accept -UInt12
https://bugs.webkit.org/show_bug.cgi?id=257074
rdar://109596645

Reviewed by Keith Miller.

If ARM64 instructions is listed in AirOpcodes.opcode with Imm, this instruction 
supports
-UInt12 and UInt12 forms. We should correctly reflect it in 
Air::Arg::isValidImmForm.
This avoids unnecessary constant materialization for negative values, and it 
reduces register
pressures. Also ARM64 instruction selection can select cmn (cmp with negative 
UInt12) for example
with this change.

* Source/JavaScriptCore/assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::branchAdd64):
(JSC::MacroAssemblerARM64::branchSub64):
* Source/JavaScriptCore/b3/B3MoveConstants.cpp:
* Source/JavaScriptCore/b3/air/AirArg.h:
(JSC::B3::Air::Arg::isValidImmForm):

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


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes


[webkit-changes] [WebKit/WebKit] 26e31e: SynchronizationOfLazyAttribute should be an enum c...

2023-05-20 Thread Ryosuke Niwa
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 26e31e65add723107ead0a21c9e7174293b1d540
  
https://github.com/WebKit/WebKit/commit/26e31e65add723107ead0a21c9e7174293b1d540
  Author: Ryosuke Niwa 
  Date:   2023-05-20 (Sat, 20 May 2023)

  Changed paths:
M Source/WebCore/dom/Element.cpp
M Source/WebCore/dom/Element.h

  Log Message:
  ---
  SynchronizationOfLazyAttribute should be an enum class
https://bugs.webkit.org/show_bug.cgi?id=257069

Reviewed by Tim Nguyen.

* Source/WebCore/dom/Element.cpp:
(WebCore::Element::detachAttribute):
(WebCore::Element::removeAttribute):
(WebCore::Element::toggleAttribute):
(WebCore::Element::setAttribute):
(WebCore::Element::setAttributeWithoutOverwriting):
(WebCore::Element::setAttributeWithoutSynchronization):
(WebCore::Element::setSynchronizedLazyAttribute):
(WebCore::Element::setAttributeInternal):
(WebCore::Element::setAttributeNode):
(WebCore::Element::setAttributeNodeNS):
(WebCore::Element::removeAttributeNode):
(WebCore::Element::removeAttributeInternal):
(WebCore::Element::addAttributeInternal):
* Source/WebCore/dom/Element.h:

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


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes


[webkit-changes] [WebKit/WebKit] 7ef848: [ macOS ] TestWebKitAPI.PushAPI.firePushEventWithN...

2023-05-20 Thread btashawn
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 7ef848e96eac02067d79d57e5d79ec398c9032e6
  
https://github.com/WebKit/WebKit/commit/7ef848e96eac02067d79d57e5d79ec398c9032e6
  Author: Bri Harris 
  Date:   2023-05-20 (Sat, 20 May 2023)

  Changed paths:
M Tools/TestWebKitAPI/Tests/WebKitCocoa/PushAPI.mm

  Log Message:
  ---
  [ macOS ] TestWebKitAPI.PushAPI.firePushEventWithNoPagesTimeout is a flaky 
timeout.
rdar://109584763
https://bugs.webkit.org/show_bug.cgi?id=257054

Unreviewed test gardening.

Disabling API while investigated.

* Tools/TestWebKitAPI/Tests/WebKitCocoa/PushAPI.mm:

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


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes


[webkit-changes] [WebKit/WebKit] 0ee37c: Media Stats should show the media element's source

2023-05-20 Thread Jer Noble
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 0ee37c4333af683443d1934d4cbb137bfcc7cb26
  
https://github.com/WebKit/WebKit/commit/0ee37c4333af683443d1934d4cbb137bfcc7cb26
  Author: Jer Noble 
  Date:   2023-05-20 (Sat, 20 May 2023)

  Changed paths:
M Source/WebCore/Modules/mediacontrols/MediaControlsHost.cpp
M Source/WebCore/Modules/mediacontrols/MediaControlsHost.h
M Source/WebCore/Modules/mediacontrols/MediaControlsHost.idl
M Source/WebCore/Modules/modern-media-controls/media/media-controller.js
M Source/WebCore/bindings/scripts/CodeGenerator.pm
M Source/WebCore/en.lproj/modern-media-controls-localized-strings.js
M Source/WebCore/html/HTMLMediaElement.cpp
M Source/WebCore/html/HTMLMediaElement.h
M Source/WebCore/platform/graphics/MediaPlayerEnums.h
M 
Source/WebCore/platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.cpp
M 
Source/WebCore/platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.h
M 
Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.h
M 
Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in

  Log Message:
  ---
  Media Stats should show the media element's source
https://bugs.webkit.org/show_bug.cgi?id=256657
rdar://109219273

Reviewed by Eric Carlson.

Media Stats currently shows a lot of great information about the codecs and 
properties of the
media element's video and audio tracks. Also useful would be information about 
the element itself,
such as whether it's current source was a file, stream, media source, etc.

Add a new attribute to MediaControlsHost which vends this information up to the 
media controls. Add
support for detecting whether the AVURLAsset is backed by a HLS stream to 
MediaplayerPrivateAVFoundationObjC.

* Source/WebCore/Modules/mediacontrols/MediaControlsHost.cpp:
(WebCore::MediaControlsHost::sourceType const):
* Source/WebCore/Modules/mediacontrols/MediaControlsHost.h:
* Source/WebCore/Modules/mediacontrols/MediaControlsHost.idl:
* Source/WebCore/Modules/modern-media-controls/media/media-controller.js:
(MediaController.prototype.setShowingStats):
* Source/WebCore/bindings/scripts/CodeGenerator.pm:
(WK_ucfirst):
* Source/WebCore/en.lproj/modern-media-controls-localized-strings.js:
* Source/WebCore/platform/graphics/MediaPlayerEnums.h:
* 
Source/WebCore/platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.cpp:
(WebCore::MediaPlayerPrivateAVFoundation::movieLoadType const):
* 
Source/WebCore/platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.h:
(WebCore::MediaPlayerPrivateAVFoundation::isHLS const):
* 
Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.h:
* 
Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm:
(WebCore::MediaPlayerPrivateAVFoundationObjC::assetStatus const):
(WebCore::assetMetadataKeyNames):
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:

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


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes


[webkit-changes] [WebKit/WebKit] 340b0f: [Multicolumn] Handle multicol intrinsic inline-siz...

2023-05-20 Thread Ahmad Saleem
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 340b0f1155192cc2bddf1df560b345a56a4b2890
  
https://github.com/WebKit/WebKit/commit/340b0f1155192cc2bddf1df560b345a56a4b2890
  Author: Ahmad Saleem 
  Date:   2023-05-20 (Sat, 20 May 2023)

  Changed paths:
M LayoutTests/TestExpectations
M Source/WebCore/rendering/RenderFragmentContainer.cpp

  Log Message:
  ---
  [Multicolumn] Handle multicol intrinsic inline-size changes

https://bugs.webkit.org/show_bug.cgi?id=257027

Reviewed by Alan Baradlay.

This patch aligns WebKit with Blink / Chromium and Gecko / Firefox.

Merge: 
https://chromium.googlesource.com/chromium/src.git/+/209ad9840b0152a427e9d2b29318cfa47ca80d92

Currently we used to store intrinsic size in column sets but if any
change happen, 'column sets' do not get dirtied so this patch will
reset intrinsic size of column sets to 0 to fix this.

* Source/WebCore/rendering/RenderFragmentContainer.cpp:
(RenderFragmentContainer::computeIntrinsicLogicalWidths): As above
* LayoutTests/TestExpectations: Remove 'failing' test

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


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes


[webkit-changes] [WebKit/WebKit] 4dfb2a: [IFC] InlineIterator::TextBox::offsetForPosition i...

2023-05-20 Thread Alan Baradlay
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 4dfb2aad8c7250f7926c2948f5d9e538af986347
  
https://github.com/WebKit/WebKit/commit/4dfb2aad8c7250f7926c2948f5d9e538af986347
  Author: Alan Baradlay 
  Date:   2023-05-20 (Sat, 20 May 2023)

  Changed paths:
M Source/WebCore/layout/integration/inline/InlineIteratorTextBox.cpp
M Source/WebCore/layout/integration/inline/InlineIteratorTextBox.h
M Source/WebCore/rendering/CaretRectComputation.cpp

  Log Message:
  ---
  [IFC] InlineIterator::TextBox::offsetForPosition is only used by 
computeCaretRectForText
https://bugs.webkit.org/show_bug.cgi?id=257073

Reviewed by Antti Koivisto.

* Source/WebCore/layout/integration/inline/InlineIteratorTextBox.cpp:
(WebCore::InlineIterator::TextBox::positionForOffset const): Deleted.
* Source/WebCore/layout/integration/inline/InlineIteratorTextBox.h:
* Source/WebCore/rendering/CaretRectComputation.cpp:
(WebCore::computeCaretRectForText):

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


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes


[webkit-changes] [WebKit/WebKit] 93f950: Cherry-pick 264196@main (4c39f3875728). https://bu...

2023-05-20 Thread Patrick
  Branch: refs/heads/webkitglib/2.38
  Home:   https://github.com/WebKit/WebKit
  Commit: 93f9500b07c5e048dbf7c48dabcf1fb282fb0cc9
  
https://github.com/WebKit/WebKit/commit/93f9500b07c5e048dbf7c48dabcf1fb282fb0cc9
  Author: Patrick Griffis 
  Date:   2023-05-20 (Sat, 20 May 2023)

  Changed paths:
M Source/WTF/wtf/glib/Sandbox.cpp
M Source/WTF/wtf/glib/Sandbox.h
M Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp

  Log Message:
  ---
  Cherry-pick 264196@main (4c39f3875728). 
https://bugs.webkit.org/show_bug.cgi?id=256917

[GLib] Re-enable bwrap sandbox in containers when supported
https://bugs.webkit.org/show_bug.cgi?id=256917

Reviewed by Michael Catanzaro.

This detects if bwrap actually works inside of a container instead
of always disabling it.

* Source/WTF/wtf/glib/Sandbox.cpp:
(WTF::isInsideUnsupportedContainer):
(WTF::isInsideContainer): Deleted.
* Source/WTF/wtf/glib/Sandbox.h:
* Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp:
(WebKit::ProcessLauncher::launchProcess):

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


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes


[webkit-changes] [WebKit/WebKit] f20cec: Cherry-pick 264244@main (a84036c6d1d6). https://bu...

2023-05-20 Thread Carlos Alberto Lopez Perez
  Branch: refs/heads/webkitglib/2.38
  Home:   https://github.com/WebKit/WebKit
  Commit: f20cec83d13b9dc4c3cbab33bc43118f04c6590d
  
https://github.com/WebKit/WebKit/commit/f20cec83d13b9dc4c3cbab33bc43118f04c6590d
  Author: Carlos Alberto Lopez Perez 
  Date:   2023-05-20 (Sat, 20 May 2023)

  Changed paths:
M Source/cmake/BubblewrapSandboxChecks.cmake

  Log Message:
  ---
  Cherry-pick 264244@main (a84036c6d1d6). 
https://bugs.webkit.org/show_bug.cgi?id=256032

[WPE][GTK][CMake] The path to bwrap and xdg-dbus-proxy should not be 
auto-detected when cross-compiling
https://bugs.webkit.org/show_bug.cgi?id=256679

Reviewed by Adrian Perez de Castro.

When enabling -DENABLE_BUBBLEWRAP_SANDBOX=ON is needed to define to the 
build
the paths (full-paths) to the bwrap and xdg-dbus-proxy binaries.

The current CMake code is auto-detecting those paths by calling the CMake
function find_program(): so it is defining the paths to those programs with
the values from the host system.

But when cross-compiling that is wrong because the target binaries end with 
the
values for the paths from the host system which don't necessary have to 
match
the values from the target system.

I can't see how it will be possible to auto-detect the value that this 
programs
will have in the target system from the host system, so the only sane way of
dealing with this seems to be to give an error at configure time and ask for
those paths to be defined manually.

This patch changes the code to only try to auto-detect those binaries when 
no
cross-compiling.

Also update the default build parameters for the cross-building of targets
with cross-toolchain-helper to define the right paths that those targets 
will
have at run-time.

* Source/cmake/BubblewrapSandboxChecks.cmake:
* Tools/yocto/targets.conf:

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


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes


[webkit-changes] [WebKit/WebKit] c3a090: [IFC] Move canUseModernPathForPreferredWidthComput...

2023-05-20 Thread Alan Baradlay
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: c3a0908f24e8fcfe6ad90734cc53fd1142e67f29
  
https://github.com/WebKit/WebKit/commit/c3a0908f24e8fcfe6ad90734cc53fd1142e67f29
  Author: Alan Baradlay 
  Date:   2023-05-20 (Sat, 20 May 2023)

  Changed paths:
M Source/WebCore/layout/integration/LayoutIntegrationCoverage.cpp
M Source/WebCore/layout/integration/LayoutIntegrationCoverage.h
M Source/WebCore/layout/integration/inline/LayoutIntegrationLineLayout.cpp
M Source/WebCore/layout/integration/inline/LayoutIntegrationLineLayout.h
M Source/WebCore/rendering/RenderBlockFlow.cpp

  Log Message:
  ---
  [IFC] Move canUseModernPathForPreferredWidthComputation to 
LayoutIntegrationCoverage
https://bugs.webkit.org/show_bug.cgi?id=257050

Reviewed by Antti Koivisto.

All canUse* logic should live in LayoutIntegrationCoverage.

* Source/WebCore/layout/integration/LayoutIntegrationCoverage.cpp:
(WebCore::LayoutIntegration::canUseForPreferredWidthComputation):
* Source/WebCore/layout/integration/LayoutIntegrationCoverage.h:
* Source/WebCore/layout/integration/inline/LayoutIntegrationLineLayout.cpp:
(WebCore::LayoutIntegration::LineLayout::canUseForPreferredWidthComputation):
* Source/WebCore/layout/integration/inline/LayoutIntegrationLineLayout.h:
* Source/WebCore/rendering/RenderBlockFlow.cpp:
(WebCore::RenderBlockFlow::tryComputePreferredWidthsUsingModernPath):

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


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes


[webkit-changes] [WebKit/WebKit] e43b88: Cherry-pick 264114@main (5dd594fd96bb). https://bu...

2023-05-20 Thread Simon Fraser
  Branch: refs/heads/webkitglib/2.40
  Home:   https://github.com/WebKit/WebKit
  Commit: e43b88b16637965818e85a107c6edb00ad8348d1
  
https://github.com/WebKit/WebKit/commit/e43b88b16637965818e85a107c6edb00ad8348d1
  Author: Michael Catanzaro 
  Date:   2023-05-20 (Sat, 20 May 2023)

  Changed paths:
M Source/WebCore/html/PDFDocument.cpp

  Log Message:
  ---
  Cherry-pick 264114@main (5dd594fd96bb). 
https://bugs.webkit.org/show_bug.cgi?id=256470

Crash in PDFDocument::sendPDFArrayBuffer
https://bugs.webkit.org/show_bug.cgi?id=256470

Reviewed by Tim Nguyen.

When page loading is stopped, PDFDocument::finishedParsing will be
called (which makes sense, because the parsing is finished, even if not
completed). Here sendPDFArrayBuffer will be called if the content script
has been loaded, even if there is no main resource data yet. We need
guards to ensure we don't dereference nullptr when there is no main
resource data.

Additionally, I've added an extra guard to ensure the document loader is
not nullptr. Maybe that's not possible here -- not sure -- but since the
function returns a pointer and not a reference it seems safer to check.

* Source/WebCore/html/PDFDocument.cpp:
(WebCore::PDFDocument::sendPDFArrayBuffer):

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


  Commit: 0d947d1cfcaf5a0361a0d3f4ce27306066024224
  
https://github.com/WebKit/WebKit/commit/0d947d1cfcaf5a0361a0d3f4ce27306066024224
  Author: Joseph Griego 
  Date:   2023-05-20 (Sat, 20 May 2023)

  Changed paths:
M Source/WTF/wtf/text/StringCommon.h
M Tools/TestWebKitAPI/Tests/WTF/StringCommon.cpp

  Log Message:
  ---
  Cherry-pick 264088@main (d565c2070f7a). 
https://bugs.webkit.org/show_bug.cgi?id=256606

Fix off-by-one in WTF::findIgnoringASCIICaseWithoutLength
https://bugs.webkit.org/show_bug.cgi?id=256606

Reviewed by Chris Dumez.

A needle identical to the haystack won't be found by this function because 
of
the length comparison used. Luckily, this function is unused except in 
testb3,
so nothing else really needs to be changed.

* Source/WTF/wtf/text/StringCommon.h:
(WTF::findIgnoringASCIICaseWithoutLength):

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


  Commit: c1567e86b6b981448c1aab638cecc44f12a2662c
  
https://github.com/WebKit/WebKit/commit/c1567e86b6b981448c1aab638cecc44f12a2662c
  Author: Simon Fraser 
  Date:   2023-05-20 (Sat, 20 May 2023)

  Changed paths:
A LayoutTests/fast/css/background-clip-text-hairline-expected.html
A LayoutTests/fast/css/background-clip-text-hairline.html
M Source/WebCore/rendering/BackgroundPainter.cpp

  Log Message:
  ---
  Cherry-pick 263526@main (ccbeb1e341f1). 
https://bugs.webkit.org/show_bug.cgi?id=179333

Hairline pixel crack around background-clip: text
https://bugs.webkit.org/show_bug.cgi?id=179333
rdar://54325642

Reviewed by Alan Baradlay.

When there is some non-integral transform (or a non axis-aligned transform) 
in the CTM, we could
show some antialiasing noise at the edge of `background-clip: text` 
regions. This noise was not
in the buffer used as a mask, but seemed to come from some the transparency 
layer operations.

We can work around it by inflating maskRect by a pixel on each size, which 
pads the intermediate
buffer, and the size of the transparency layer.

* LayoutTests/fast/css/background-clip-text-hairline-expected.html: Added.
* LayoutTests/fast/css/background-clip-text-hairline.html: Added.
* Source/WebCore/rendering/BackgroundPainter.cpp:
(WebCore::BackgroundPainter::paintFillLayer):

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


Compare: https://github.com/WebKit/WebKit/compare/448a40e3dd2e...c1567e86b6b9
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes


[webkit-changes] [WebKit/WebKit] 891988: Cherry-pick 264088@main (d565c2070f7a). https://bu...

2023-05-20 Thread jjgriego
  Branch: refs/heads/webkitglib/2.38
  Home:   https://github.com/WebKit/WebKit
  Commit: 891988e5eb269450ccdaed22ab4cc7e3573c697f
  
https://github.com/WebKit/WebKit/commit/891988e5eb269450ccdaed22ab4cc7e3573c697f
  Author: Joseph Griego 
  Date:   2023-05-20 (Sat, 20 May 2023)

  Changed paths:
M Source/WTF/wtf/text/StringCommon.h
M Tools/TestWebKitAPI/Tests/WTF/StringCommon.cpp

  Log Message:
  ---
  Cherry-pick 264088@main (d565c2070f7a). 
https://bugs.webkit.org/show_bug.cgi?id=256606

Fix off-by-one in WTF::findIgnoringASCIICaseWithoutLength
https://bugs.webkit.org/show_bug.cgi?id=256606

Reviewed by Chris Dumez.

A needle identical to the haystack won't be found by this function because 
of
the length comparison used. Luckily, this function is unused except in 
testb3,
so nothing else really needs to be changed.

* Source/WTF/wtf/text/StringCommon.h:
(WTF::findIgnoringASCIICaseWithoutLength):

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


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes


[webkit-changes] [WebKit/WebKit] e17c21: Allow empty WPT variants from comments

2023-05-20 Thread Sam Sneddon
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: e17c2153ab908a5821a2b72ee9fe7856b98aac12
  
https://github.com/WebKit/WebKit/commit/e17c2153ab908a5821a2b72ee9fe7856b98aac12
  Author: Sam Sneddon 
  Date:   2023-05-20 (Sat, 20 May 2023)

  Changed paths:
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-1000-reason.any-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-1000-reason.any.worker-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-1000-verify-code.any-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-1000-verify-code.any.worker-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-1000.any-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-1000.any.worker-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-1005-verify-code.any-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-1005-verify-code.any.worker-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-1005.any-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-1005.any.worker-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-2999-reason.any-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-2999-reason.any.worker-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-3000-reason.any-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-3000-reason.any.worker-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-3000-verify-code.any-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-3000-verify-code.any.worker-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-4999-reason.any-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-4999-reason.any.worker-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-Reason-124Bytes.any-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-Reason-124Bytes.any.worker-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-delayed.any-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-delayed.any.worker-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-onlyReason.any-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-onlyReason.any.worker-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-readyState-Closed.any-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-readyState-Closed.any.worker-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-readyState-Closing.any-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-readyState-Closing.any.worker-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-reason-unpaired-surrogates.any-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-reason-unpaired-surrogates.any.worker-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-server-initiated-close.any-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-server-initiated-close.any.worker-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-undefined.any-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Close-undefined.any.worker-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Create-asciiSep-protocol-string.any-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Create-asciiSep-protocol-string.any.worker-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Create-blocked-port.any-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Create-blocked-port.any.worker-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Create-extensions-empty.any-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Create-extensions-empty.any.worker-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Create-nonAscii-protocol-string.any-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Create-nonAscii-protocol-string.any.worker-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Create-protocol-with-space.any-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Create-protocol-with-space.any.worker-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/websockets/Create-protocols-repeated-case-insensitive.any-expected.txt
  

[webkit-changes] [WebKit/WebKit] 05b6a8: Convert the remaining enums in FrameSelection.h to...

2023-05-20 Thread Ryosuke Niwa
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 05b6a82d72138cfb89e758d8c1afd70a88c9c850
  
https://github.com/WebKit/WebKit/commit/05b6a82d72138cfb89e758d8c1afd70a88c9c850
  Author: Ryosuke Niwa 
  Date:   2023-05-19 (Fri, 19 May 2023)

  Changed paths:
M Source/WebCore/editing/EditorCommand.cpp
M Source/WebCore/editing/FrameSelection.cpp
M Source/WebCore/editing/FrameSelection.h

  Log Message:
  ---
  Convert the remaining enums in FrameSelection.h to enum classes
https://bugs.webkit.org/show_bug.cgi?id=257061

Reviewed by Wenson Hsieh.

* Source/WebCore/editing/EditorCommand.cpp:
(WebCore::executeMovePageDown):
(WebCore::executeMovePageDownAndModifySelection):
(WebCore::executeMovePageUp):
(WebCore::executeMovePageUpAndModifySelection):
* Source/WebCore/editing/FrameSelection.cpp:
(WebCore::DragCaretController::DragCaretController):
(WebCore::FrameSelection::FrameSelection):
(WebCore::FrameSelection::modifyExtendingForward):
(WebCore::FrameSelection::modifyMovingForward):
(WebCore::FrameSelection::modifyExtendingBackward):
(WebCore::FrameSelection::modifyMovingBackward):
(WebCore::FrameSelection::modify):
(WebCore::FrameSelection::lineDirectionPointForBlockDirectionNavigation):
(WebCore::CaretBase::paintCaret const):
(WebCore::FrameSelection::focusedOrActiveStateChanged):
* Source/WebCore/editing/FrameSelection.h:
(WebCore::CaretBase::caretIsVisible const):

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


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes


[webkit-changes] [WebKit/WebKit] 21ee55: Unreviewed, reverting 264278@main.

2023-05-20 Thread Commit Queue
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 21ee55b48985e240ff8815048623207b83307c83
  
https://github.com/WebKit/WebKit/commit/21ee55b48985e240ff8815048623207b83307c83
  Author: Commit Queue 
  Date:   2023-05-19 (Fri, 19 May 2023)

  Changed paths:
M Source/WebKit/SwiftOverlay/WebKitSwiftOverlay.xcodeproj/project.pbxproj

  Log Message:
  ---
  Unreviewed, reverting 264278@main.
https://bugs.webkit.org/show_bug.cgi?id=257078

Broke Safari builds

Reverted changeset:

"WebKitSwiftOverlay should (once again) include a WebKitAdditions overlay"
https://bugs.webkit.org/show_bug.cgi?id=257046
https://commits.webkit.org/264278@main

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


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes


[webkit-changes] [WebKit/WebKit] 7a80df: Regression(263830@main) Frequent Jetsams on macOS ...

2023-05-20 Thread Chris Dumez
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 7a80dfacdb26f49d6dea6ded444f7b1ffce578b5
  
https://github.com/WebKit/WebKit/commit/7a80dfacdb26f49d6dea6ded444f7b1ffce578b5
  Author: Chris Dumez 
  Date:   2023-05-19 (Fri, 19 May 2023)

  Changed paths:
M Source/WebKit/Scripts/update-info-plist-for-runningboard.sh

  Log Message:
  ---
  Regression(263830@main) Frequent Jetsams on macOS 13.3+
https://bugs.webkit.org/show_bug.cgi?id=257077
rdar://109517882

Reviewed by Wenson Hsieh.

In 263830@main, I updated the script to compare TARGET_MAC_OS_X_VERSION_MAJOR
to 130300 instead of 13, since we only use RunningBoard on macOS 13.3+.
However, TARGET_MAC_OS_X_VERSION_MAJOR only contains the "major" version,
meaning that it is 13 on all macOS 13.x versions. As a result, the check
now fails on macOS 13.x and we don't mark our processes as managed by
RunningBoard, even though our code uses RunningBoard on macOS 13.3.

To address the issue, we now rely on the MACOSX_DEPLOYMENT_TARGET variable
instead, which contains both the major and minor version (formatted like
"13.3").

* Source/WebKit/Scripts/update-info-plist-for-runningboard.sh:

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


___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes