[webkit-changes] [WebKit/WebKit] b0e1a9: Update Node.lookupNamespaceURI() and XPathEvaluato...

2023-02-25 Thread Chris Dumez
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: b0e1a9c1d9b3b952faa97d997c57d6358d11b79f
  
https://github.com/WebKit/WebKit/commit/b0e1a9c1d9b3b952faa97d997c57d6358d11b79f
  Author: Chris Dumez 
  Date:   2023-02-25 (Sat, 25 Feb 2023)

  Changed paths:
M LayoutTests/dom/xhtml/level3/core/nodelookupnamespaceuri16.js
M LayoutTests/fast/dom/gc-9-expected.txt
M LayoutTests/fast/dom/gc-9.html
M 
LayoutTests/imported/w3c/web-platform-tests/dom/nodes/Node-lookupNamespaceURI-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/dom/nodes/Node-lookupNamespaceURI.html
A 
LayoutTests/imported/w3c/web-platform-tests/domxpath/xpathevaluatorbase-creatensresolver-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/domxpath/xpathevaluatorbase-creatensresolver.html
M Source/WebCore/dom/Document.h
M Source/WebCore/dom/Node.cpp
M Source/WebCore/xml/XPathEvaluator.h
M Source/WebCore/xml/XPathEvaluatorBase.idl

  Log Message:
  ---
  Update Node.lookupNamespaceURI() and XPathEvaluatorBase.createNSResolver()
https://bugs.webkit.org/show_bug.cgi?id=252716

Reviewed by Darin Adler.

Update Node.lookupNamespaceURI() and XPathEvaluatorBase.createNSResolver() per:
https://github.com/whatwg/dom/pull/1165
https://github.com/web-platform-tests/wpt/pull/38636

- lookupNamespaceURI():
Element should handle "xml" and "xmlns" by default.

- createNSResolver():
It should return the argument as is, and should not add "xml" prefix support.

* 
LayoutTests/imported/w3c/web-platform-tests/dom/nodes/Node-lookupNamespaceURI-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/dom/nodes/Node-lookupNamespaceURI.html:
* 
LayoutTests/imported/w3c/web-platform-tests/domxpath/xpathevaluatorbase-creatensresolver-expected.txt:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/domxpath/xpathevaluatorbase-creatensresolver.html:
 Added.
* Source/WebCore/dom/Document.h:
(WebCore::Document::createNSResolverForBindings const):
* Source/WebCore/dom/Node.cpp:
(WebCore::locateDefaultNamespace):
* Source/WebCore/xml/XPathEvaluator.h:
(WebCore::XPathEvaluator::createNSResolverForBindings const):
* Source/WebCore/xml/XPathEvaluatorBase.idl:

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


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


[webkit-changes] [WebKit/WebKit] 1eb1d4: [IFC][Partial layout] Do not run partial invalidat...

2023-02-25 Thread Alan Baradlay
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 1eb1d409c2d8f483080a20dc72e6ed68242a0889
  
https://github.com/WebKit/WebKit/commit/1eb1d409c2d8f483080a20dc72e6ed68242a0889
  Author: Alan Baradlay 
  Date:   2023-02-25 (Sat, 25 Feb 2023)

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

  Log Message:
  ---
  [IFC][Partial layout] Do not run partial invalidation when IFC has 
out-of-flow content
https://bugs.webkit.org/show_bug.cgi?id=252930


Reviewed by Antti Koivisto.

Disable partial invalidation when out-of-flow content is present. This is not 
supported yet.

* Source/WebCore/layout/integration/LayoutIntegrationCoverage.cpp:
(WebCore::LayoutIntegration::shouldInvalidateLineLayoutPathAfterContentChangeFor):
* Source/WebCore/layout/integration/inline/LayoutIntegrationLineLayout.cpp:
(WebCore::LayoutIntegration::LineLayout::hasOutOfFlowContent const):
* Source/WebCore/layout/integration/inline/LayoutIntegrationLineLayout.h:

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


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


[webkit-changes] [WebKit/WebKit] d9b516: [IFC][Partial layout] Implement BoxTree::updateCon...

2023-02-25 Thread Alan Baradlay
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: d9b5164807cbc2a39f6ed2dc626e57369072fdf2
  
https://github.com/WebKit/WebKit/commit/d9b5164807cbc2a39f6ed2dc626e57369072fdf2
  Author: Alan Baradlay 
  Date:   2023-02-25 (Sat, 25 Feb 2023)

  Changed paths:
M Source/WebCore/layout/integration/LayoutIntegrationBoxTree.cpp
M Source/WebCore/layout/layouttree/LayoutInlineTextBox.h

  Log Message:
  ---
  [IFC][Partial layout] Implement BoxTree::updateContent for RenderText
https://bugs.webkit.org/show_bug.cgi?id=252877

Reviewed by Antti Koivisto.

This patch is in preparation for supporting partial layout triggered by partial 
content mutation (e.g. typing in a text input field).

* Source/WebCore/layout/integration/LayoutIntegrationBoxTree.cpp:
(WebCore::LayoutIntegration::BoxTree::updateContent):
* Source/WebCore/layout/layouttree/LayoutInlineTextBox.h:
(WebCore::Layout::InlineTextBox::updateContent):

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


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


[webkit-changes] [WebKit/WebKit] acc0a6: [UI-side compositing] Prepare for the event handli...

2023-02-25 Thread Simon Fraser
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: acc0a64d65110f80170a0a3a89e3432983da85d5
  
https://github.com/WebKit/WebKit/commit/acc0a64d65110f80170a0a3a89e3432983da85d5
  Author: Simon Fraser 
  Date:   2023-02-25 (Sat, 25 Feb 2023)

  Changed paths:
M 
Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.cpp
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.h
M 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeEventDispatcher.cpp
M 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeEventDispatcher.h
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h

  Log Message:
  ---
  [UI-side compositing] Prepare for the event handling asynchrony introduced by 
a scrolling thread in the UI process
https://bugs.webkit.org/show_bug.cgi?id=252947
rdar://105927794

Reviewed by Alan Baradlay.

Once we dispatch wheel events to a scrolling thread in the UI process, we can 
no longer
have RemoteScrollingCoordinatorProxy::handleWheelEvent() return a 
WheelEventHandlingResult
synchronously. So we have to split the wheel event handling code up a little 
more, introducing
continueWheelEventHandling() which is called once the scrolling thread is done 
with the event.

Fix RemoteScrollingCoordinatorProxy::handleWheelEvent() to call 
continueWheelEventHandling();
this code will go away once we start sending events to 
RemoteLayerTreeEventDispatcher.

Rejigger WebPageProxy::handleWheelEvent() to move a bit of code into 
continueWheelEventHandling(),
and call that directly for the non-UI-side compositing code path.

continueWheelEventHandling() needs to receive a native wheel event in order to 
send it to
wheelEventCoalescer, so RemoteLayerTreeEventDispatcher needs a small queue of 
events to
keep around the event to send back.

* Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.cpp:
(WebKit::RemoteScrollingCoordinatorProxy::handleWheelEvent):
(WebKit::RemoteScrollingCoordinatorProxy::continueWheelEventHandling):
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.h:
* 
Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeEventDispatcher.cpp:
(WebKit::RemoteLayerTreeEventDispatcher::willHandleWheelEvent):
(WebKit::RemoteLayerTreeEventDispatcher::handleWheelEvent):
(WebKit::RemoteLayerTreeEventDispatcher::wheelEventWasHandledByScrollingThread):
(WebKit::RemoteLayerTreeEventDispatcher::displayLink const):
* Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeEventDispatcher.h:
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::handleWheelEvent):
(WebKit::WebPageProxy::continueWheelEventHandling):
* Source/WebKit/UIProcess/WebPageProxy.h:

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


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


[webkit-changes] [WebKit/WebKit] e08b1b: [IFC][Partial layout] Implement damaged line compu...

2023-02-25 Thread Alan Baradlay
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: e08b1be10290c376542e53aecc78b3e6d1bd795b
  
https://github.com/WebKit/WebKit/commit/e08b1be10290c376542e53aecc78b3e6d1bd795b
  Author: Alan Baradlay 
  Date:   2023-02-25 (Sat, 25 Feb 2023)

  Changed paths:
M 
Source/WebCore/layout/formattingContexts/inline/invalidation/InlineInvalidation.cpp

  Log Message:
  ---
  [IFC][Partial layout] Implement damaged line computation based on (damaged) 
InlineTextBox
https://bugs.webkit.org/show_bug.cgi?id=252867

Reviewed by Antti Koivisto.

Walk the display box list to figure out where the (existing) damaged 
InlineTextBox (with offset) is.

Currently we simply return the last line's index as the damaged line is always 
the last one when a new layout box is appended.
However when existing InlineTextBox content gets changed (e.g. append with 
offset), the damaged line is not necessarily the last one.

* 
Source/WebCore/layout/formattingContexts/inline/invalidation/InlineInvalidation.cpp:
(WebCore::Layout::damagedLineIndex):
(WebCore::Layout::leadingContentDisplayForLineIndex):
(WebCore::Layout::leadingInlineItemPositionForDamage):
(WebCore::Layout::leadingInlineItemPositionOnLastLine):
(WebCore::Layout::leadingInlineItemPositionByDamagedBox):
(WebCore::Layout::InlineInvalidation::textInserted):

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


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


[webkit-changes] [WebKit/WebKit] f86d28: Fix build error with MEDIA_STREAM=OFF

2023-02-25 Thread Pablo Saavedra
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: f86d288403eec12b32eff1ff5a34d785bbd0969b
  
https://github.com/WebKit/WebKit/commit/f86d288403eec12b32eff1ff5a34d785bbd0969b
  Author: Pablo Saavedra 
  Date:   2023-02-25 (Sat, 25 Feb 2023)

  Changed paths:
M Source/WebCore/platform/audio/gstreamer/AudioSourceProviderGStreamer.cpp

  Log Message:
  ---
  Fix build error with MEDIA_STREAM=OFF
https://bugs.webkit.org/show_bug.cgi?id=252892

Reviewed by Philippe Normand.

* Source/WebCore/platform/audio/gstreamer/AudioSourceProviderGStreamer.cpp:
(WebCore::AudioSourceProviderGStreamer::~AudioSourceProviderGStreamer):

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


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


[webkit-changes] [WebKit/WebKit] 19b6a7: Cherry-pick 260790@main (71065ff83269). https://bu...

2023-02-25 Thread Michael Catanzaro
  Branch: refs/heads/webkitglib/2.40
  Home:   https://github.com/WebKit/WebKit
  Commit: 19b6a7d45363d658f1dacfe32dc9493338563442
  
https://github.com/WebKit/WebKit/commit/19b6a7d45363d658f1dacfe32dc9493338563442
  Author: Žan Doberšek 
  Date:   2023-02-26 (Sun, 26 Feb 2023)

  Changed paths:
M Source/WebCore/platform/graphics/gbm/DMABufEGLUtilities.h
M Source/WebCore/platform/graphics/gbm/DMABufObject.h
M Source/WebCore/platform/graphics/gbm/GBMBufferSwapchain.cpp
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp

  Log Message:
  ---
  Cherry-pick 260790@main (71065ff83269). 
https://bugs.webkit.org/show_bug.cgi?id=252744

[Linux] DMABufObject modifiers should default to being not-present
https://bugs.webkit.org/show_bug.cgi?id=252744

Reviewed by Carlos Garcia Campos.

Until now, the modifier values on the DMABufObject instances defaulted to 0,
which is equivalent to DRM_FORMAT_MOD_LINEAR. These values were then used in
the constructEGLCreateImageAttributes() helper, specifying the modifier 
value
for the EGLImage import as long as the driver supported the relevant 
extension.

DRM_FORMAT_MOD_LINEAR enforces the linear format, but that is not the same 
as
leaving the modifier unspecified. The latter step is necessary when the
modifier value has not been specified otherwise, since it allows the driver 
to
detect the corresponding modifier through internal logic.

This problem has been exhibited with some GStreamer decoders that yield 
DMABufs
without any modifier specified (perhaps because a specified modifier isn't
required, but mostly because the GStreamer pipeline doesn't relay that
information yet). When the linear modifier was specified, sampling of the
DMABuf-backed EGLImage was incorrect.

To fix this, modifier presence is now tracked alongside the per-plane 
modifier
value. Only when the modifier usage is enabled and the modifier is actually
present, the relevant EGL attributes are set during the EGLImage import.

GStreamer sink, when operating on DMABufs, leaves the modifiers unspecified,
since for now there's no information to work with. In GBMBufferSwapchain, 
when
creating a DMABufObject for a given buffer, that information is retrievable
through libgbm API, and the modifier for a given plane is marked as present.

* Source/WebCore/platform/graphics/gbm/DMABufEGLUtilities.h:
(WebCore::DMABufEGLUtilities::constructEGLCreateImageAttributes):
* Source/WebCore/platform/graphics/gbm/DMABufObject.h:
(WebCore::DMABufObject::encode):
(WebCore::DMABufObject::decode):
* Source/WebCore/platform/graphics/gbm/GBMBufferSwapchain.cpp:
(WebCore::GBMBufferSwapchain::Buffer::createDMABufObject const):
* 
Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
(WebCore::MediaPlayerPrivateGStreamer::pushDMABufToCompositor):

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


  Commit: fe62fa076c5ebdfaab9f27efb162726729017b38
  
https://github.com/WebKit/WebKit/commit/fe62fa076c5ebdfaab9f27efb162726729017b38
  Author: Michael Catanzaro 
  Date:   2023-02-26 (Sun, 26 Feb 2023)

  Changed paths:
M Source/cmake/OptionsCommon.cmake

  Log Message:
  ---
  Cherry-pick 260818@main (fe4fdc28cd21). 
https://bugs.webkit.org/show_bug.cgi?id=252679

[CMake] Rework decision to enable -gsplit-dwarf by default
https://bugs.webkit.org/show_bug.cgi?id=252679

Reviewed by Adrian Perez de Castro.

-gsplit-dwarf breaks RPM builds due to zero-sized debug files. I could
override this with -DDEBUG_FISSION=OFF, but we're probably trying to be
_too_ helpful here by injecting debug flags into non-debug build types.
I doubt Fedora is the only distro that's not prepared for -gsplit-dwarf
so let's only inject it if the CMake build type is a debug build type,
and if ENABLE_DEVELOPER_MODE (set e.g. by build-webkit) which is a good
indication that incremental builds are desired. (The primary goal of
-gsplit-dwarf is to make incremental builds faster.) That way, we
improve CMake's default behavior for developers doing incremental
builds, but anyone manually passing CFLAGS will still get exactly what
they request without modification, and we avoid breaking find-debuginfo
scripts or other debuginfo machinery that CMake does not know about.

* Source/cmake/OptionsCommon.cmake:

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


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


[webkit-changes] [WebKit/WebKit] 5c3f5c: Add support for fading out document markers

2023-02-25 Thread Aditya Keerthi
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 5c3f5c350c623143a75e7b21c99695aeac53d2eb
  
https://github.com/WebKit/WebKit/commit/5c3f5c350c623143a75e7b21c99695aeac53d2eb
  Author: Aditya Keerthi 
  Date:   2023-02-25 (Sat, 25 Feb 2023)

  Changed paths:
M Source/WebCore/dom/DocumentMarkerController.cpp
M Source/WebCore/dom/DocumentMarkerController.h
M Source/WebCore/dom/RenderedDocumentMarker.h
M Source/WebCore/rendering/TextBoxPainter.cpp

  Log Message:
  ---
  Add support for fading out document markers
https://bugs.webkit.org/show_bug.cgi?id=252870
rdar://105857998

Reviewed by Megan Gardner.

Add the ability to fade out document markers, similar to DataDetector highlights
and PageOverlays.

* Source/WebCore/dom/DocumentMarkerController.cpp:
(WebCore::DocumentMarkerController::DocumentMarkerController):

Specify constants for the animation frame rate and duration. The frame rate
was selected to match other existing animations, such as fading out DataDetector
highlights and PageOverlays.

(WebCore::DocumentMarkerController::detach):
(WebCore::DocumentMarkerController::forEachOfTypes):

Add a helper method to iterate over all markers of a given type.

(WebCore::DocumentMarkerController::removeMarkers):
(WebCore::DocumentMarkerController::removeMarkersFromList):

Introduce a filter function, to avoid code duplication when it is time to
remove faded out markers.

(WebCore::DocumentMarkerController::dismissMarkers):

This method removes markers of a given type by fading them out, rather than
simply removing them from the list of rendered document markers.

Markers that are fading out, as marked as "being dismissed" and an animation
start time is recorded. If the animation timer is not already running, it is
started.

(WebCore::DocumentMarkerController::fadeAnimationTimerFired):

On each tick, update the opacity of markers being dismissed based on the
animation start time and the current time. Once the marker is fully faded out,
it is removed from the list of markers. If there are no more markers to animate,
the timer is stopped.

* Source/WebCore/dom/DocumentMarkerController.h:
* Source/WebCore/dom/RenderedDocumentMarker.h:

Add new properties to `RenderedDocumentMarker` to support animation.

(WebCore::RenderedDocumentMarker::opacity const):
(WebCore::RenderedDocumentMarker::setOpacity):
(WebCore::RenderedDocumentMarker::isBeingDismissed const):
(WebCore::RenderedDocumentMarker::setBeingDismissed):
(WebCore::RenderedDocumentMarker::animationStartTime const):
* Source/WebCore/rendering/TextBoxPainter.cpp:
(WebCore::TextBoxPainter::paintPlatformDocumentMarker):

Adjust the alpha value of the marker color to perform the fade.

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


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


[webkit-changes] [WebKit/WebKit] 6d701f: Fix a couple of memory leaks after 260826@main

2023-02-25 Thread Wenson Hsieh
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 6d701f331859f7ab05bd58c9931cc921297db3e7
  
https://github.com/WebKit/WebKit/commit/6d701f331859f7ab05bd58c9931cc921297db3e7
  Author: Wenson Hsieh 
  Date:   2023-02-25 (Sat, 25 Feb 2023)

  Changed paths:
M Tools/TestWebKitAPI/Tests/mac/FontManagerTests.mm

  Log Message:
  ---
  Fix a couple of memory leaks after 260826@main
https://bugs.webkit.org/show_bug.cgi?id=252922

Reviewed by Aditya Keerthi.

Use `adoptNS()` to avoid leaking the +1 dictionaries, returned from 
`-mutableCopy`.

* Tools/TestWebKitAPI/Tests/mac/FontManagerTests.mm:
(TestWebKitAPI::TEST):

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


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


[webkit-changes] [WebKit/WebKit] 3464e0: REGRESSION (260654@main): BaseXcconfigCheckerTest ...

2023-02-25 Thread EWS
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 3464e0af6f31f9b080796edb0576a2ce285a3411
  
https://github.com/WebKit/WebKit/commit/3464e0af6f31f9b080796edb0576a2ce285a3411
  Author: David Kilzer 
  Date:   2023-02-25 (Sat, 25 Feb 2023)

  Changed paths:
M Tools/Scripts/webkitpy/style/checkers/basexcconfig.py

  Log Message:
  ---
  REGRESSION (260654@main): BaseXcconfigCheckerTest fails when not run from 
top-level folder
https://bugs.webkit.org/show_bug.cgi?id=252946


Reviewed by Alexey Proskuryakov.

Construct a relative path to fix the bug.

* Tools/Scripts/webkitpy/style/checkers/basexcconfig.py:
(BaseXcconfigChecker.read_common_base_xcconfig_variables):
- Construct a relative path using __file__ to
  Configurations/CommonBase.xcconfig so that this test works
  no matter where test-webkitpy (or check-webkit-style) is
  invoked.

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


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


[webkit-changes] [WebKit/WebKit] 4a9923: [Flatpak SDK] local build is broken on Python 3.11...

2023-02-25 Thread Philippe Normand
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 4a9923315354fcdd9dea2fb21d8186c667b1dbdb
  
https://github.com/WebKit/WebKit/commit/4a9923315354fcdd9dea2fb21d8186c667b1dbdb
  Author: Philippe Normand 
  Date:   2023-02-25 (Sat, 25 Feb 2023)

  Changed paths:
M Tools/buildstream/Pipfile
M Tools/buildstream/Pipfile.lock
M Tools/buildstream/README.md

  Log Message:
  ---
  [Flatpak SDK] local build is broken on Python 3.11 runtimes
https://bugs.webkit.org/show_bug.cgi?id=250068

Reviewed by Michael Catanzaro.

Update our pipenv environment to BuildStream 1.6.9, the first release shipping 
support for Python
3.11.

* Tools/buildstream/Pipfile:
* Tools/buildstream/Pipfile.lock:
* Tools/buildstream/README.md:

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


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


[webkit-changes] [WebKit/WebKit] 9743d1: HTML maxlength attribute treats emoji of string le...

2023-02-25 Thread Chris Dumez
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 9743d10df7bc729130bf6bb1fa975aec17e71bc3
  
https://github.com/WebKit/WebKit/commit/9743d10df7bc729130bf6bb1fa975aec17e71bc3
  Author: Chris Dumez 
  Date:   2023-02-25 (Sat, 25 Feb 2023)

  Changed paths:
M 
LayoutTests/fast/forms/input-maxlength-paste-clusters-in-middle-expected.txt
M LayoutTests/fast/forms/input-maxlength-paste-clusters-in-middle.html
A LayoutTests/fast/forms/input-text-max-length-emojis-expected.txt
A LayoutTests/fast/forms/input-text-max-length-emojis.html
M LayoutTests/fast/forms/input-text-paste-maxlength-expected.txt
M LayoutTests/fast/forms/input-text-paste-maxlength.html
A 
LayoutTests/imported/w3c/web-platform-tests/html/semantics/forms/constraints/input-maxlength-emoji-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/html/semantics/forms/constraints/input-maxlength-emoji.html
M LayoutTests/platform/glib/TestExpectations
M Source/WebCore/html/HTMLInputElement.cpp
M Source/WebCore/html/HTMLTextAreaElement.cpp
M Source/WebCore/html/InputType.cpp
M Source/WebCore/html/TextFieldInputType.cpp
M Tools/WebKitTestRunner/gtk/UIScriptControllerGtk.cpp
M Tools/WebKitTestRunner/gtk/UIScriptControllerGtk.h

  Log Message:
  ---
  HTML maxlength attribute treats emoji of string length 11 as length 1
https://bugs.webkit.org/show_bug.cgi?id=252900

Reviewed by Ryosuke Niwa and Aditya Keerthi.

Per the HTML specification[1], minlength/maxlength attributes on  should
restrict the length of the value, which is defined in code units [2].

Historically, WebKit has been counting grapheme clusters instead of code units
because we felt it made more sense. However, Blink and Gecko follow the
specification and only WebKit has the particular behavior. This is bad for
interoperability and makes Web developers' life more difficult than it needs to
be.

As a result, I am proposing we update WebKit to align with the HTML
specification and other major browser engines.

[1] 
https://html.spec.whatwg.org/multipage/input.html#the-maxlength-and-minlength-attributes
[2] https://infra.spec.whatwg.org/#string-length

* LayoutTests/fast/forms/input-maxlength-paste-clusters-in-middle-expected.txt:
* LayoutTests/fast/forms/input-maxlength-paste-clusters-in-middle.html:
* LayoutTests/fast/forms/input-text-max-length-emojis-expected.txt: Added.
* LayoutTests/fast/forms/input-text-max-length-emojis.html: Added.
* LayoutTests/fast/forms/input-text-paste-maxlength-expected.txt:
* LayoutTests/fast/forms/input-text-paste-maxlength.html:
* Source/WebCore/html/HTMLInputElement.cpp:
(WebCore::HTMLInputElement::tooShort const):
(WebCore::HTMLInputElement::tooLong const):
* Source/WebCore/html/HTMLTextAreaElement.cpp:
(WebCore::computeLengthForSubmission):
* Source/WebCore/html/InputType.cpp:
(WebCore::InputType::validationMessage const):
* Source/WebCore/html/TextFieldInputType.cpp:
(WebCore::limitLength):
(WebCore::TextFieldInputType::handleBeforeTextInsertedEvent):

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


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


[webkit-changes] [WebKit/WebKit] 3c7d37: [IFC][Partial layout] InlineInvalidation::textInse...

2023-02-25 Thread Alan Baradlay
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 3c7d37eae4c7692b94429cf3b610ec5863409864
  
https://github.com/WebKit/WebKit/commit/3c7d37eae4c7692b94429cf3b610ec5863409864
  Author: Alan Baradlay 
  Date:   2023-02-25 (Sat, 25 Feb 2023)

  Changed paths:
M 
Source/WebCore/layout/formattingContexts/inline/invalidation/InlineInvalidation.cpp
M 
Source/WebCore/layout/formattingContexts/inline/invalidation/InlineInvalidation.h
M Source/WebCore/layout/integration/LayoutIntegrationBoxTree.cpp
M Source/WebCore/layout/integration/LayoutIntegrationBoxTree.h
M Source/WebCore/layout/integration/inline/LayoutIntegrationLineLayout.cpp

  Log Message:
  ---
  [IFC][Partial layout] InlineInvalidation::textInserted should be able to 
handle exiting content mutation
https://bugs.webkit.org/show_bug.cgi?id=252848

Reviewed by Antti Koivisto.

This (mostly refactoring) patch is in preparation for supporting existing 
content mutation where an InlineTextBox content gets expanded (as opposed to 
new "renderer" gets added to the tree),

Finding the damaged position now has the following distinct steps:
1. Find the damaged line index (currently it's always the last line) (see 
damagedLineIndex)
2. Find the first _content_ display box on the line (skipping leading root and 
spanning inline boxes) (see leadingContentDisplayForLineIndex)
3. Find the associated InlineItem and compute the offset inside the InlineItem 
when applicable (see inlineItemPositionForDisplayBox)

* 
Source/WebCore/layout/formattingContexts/inline/invalidation/InlineInvalidation.cpp:
(WebCore::Layout::leadingContentDisplayBox):
(WebCore::Layout::inlineItemPositionForDisplayBox):
(WebCore::Layout::leadingInlineItemPositionOnLastLine):
(WebCore::Layout::leadingInlineItemPositionOnByDamagedBox):
(WebCore::Layout::InlineInvalidation::textInserted):
(WebCore::Layout::leadingInlineItemPositionOnDamagedLine): Deleted.
* 
Source/WebCore/layout/formattingContexts/inline/invalidation/InlineInvalidation.h:
(WebCore::Layout::InlineInvalidation::textInserted):
* Source/WebCore/layout/integration/LayoutIntegrationBoxTree.cpp:
(WebCore::LayoutIntegration::BoxTree::updateContent):
* Source/WebCore/layout/integration/LayoutIntegrationBoxTree.h:
* Source/WebCore/layout/integration/inline/LayoutIntegrationLineLayout.cpp:
(WebCore::LayoutIntegration::LineLayout::insertedIntoTree):
(WebCore::LayoutIntegration::LineLayout::updateTextContent):

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


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


[webkit-changes] [WebKit/WebKit] 2f4844: Add URLSearchParams's size

2023-02-25 Thread Chris Dumez
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 2f4844a6f100a68a14c7682108916b4fd1df787a
  
https://github.com/WebKit/WebKit/commit/2f4844a6f100a68a14c7682108916b4fd1df787a
  Author: Chris Dumez 
  Date:   2023-02-25 (Sat, 25 Feb 2023)

  Changed paths:
A 
LayoutTests/imported/w3c/web-platform-tests/url/urlsearchparams-size.any-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/url/urlsearchparams-size.any.html
A 
LayoutTests/imported/w3c/web-platform-tests/url/urlsearchparams-size.any.js
A 
LayoutTests/imported/w3c/web-platform-tests/url/urlsearchparams-size.any.worker-expected.txt
A 
LayoutTests/imported/w3c/web-platform-tests/url/urlsearchparams-size.any.worker.html
M Source/WebCore/html/URLSearchParams.h
M Source/WebCore/html/URLSearchParams.idl

  Log Message:
  ---
  Add URLSearchParams's size
https://bugs.webkit.org/show_bug.cgi?id=252749
rdar://105781287

Reviewed by Darin Adler.

Add support for URLSearchParams.size:
- https://github.com/whatwg/url/pull/734
- https://github.com/web-platform-tests/wpt/pull/38655

* 
LayoutTests/imported/w3c/web-platform-tests/url/urlsearchparams-size.any-expected.txt:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/url/urlsearchparams-size.any.html: 
Added.
* LayoutTests/imported/w3c/web-platform-tests/url/urlsearchparams-size.any.js: 
Added.
(test):
* 
LayoutTests/imported/w3c/web-platform-tests/url/urlsearchparams-size.any.worker-expected.txt:
 Added.
* 
LayoutTests/imported/w3c/web-platform-tests/url/urlsearchparams-size.any.worker.html:
 Added.
* Source/WebCore/html/URLSearchParams.h:
(WebCore::URLSearchParams::size const):
* Source/WebCore/html/URLSearchParams.idl:

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


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


[webkit-changes] [WebKit/WebKit] 624d35: Crash under PowerObserver::didReceiveSystemPowerNo...

2023-02-25 Thread Chris Dumez
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 624d3538fd22d2a7e7a14f4937daf64f5361d9e7
  
https://github.com/WebKit/WebKit/commit/624d3538fd22d2a7e7a14f4937daf64f5361d9e7
  Author: Chris Dumez 
  Date:   2023-02-25 (Sat, 25 Feb 2023)

  Changed paths:
M Source/WebCore/platform/mac/PowerObserverMac.cpp
M Source/WebCore/platform/mac/PowerObserverMac.h

  Log Message:
  ---
  Crash under PowerObserver::didReceiveSystemPowerNotification()
https://bugs.webkit.org/show_bug.cgi?id=252940
rdar://90891509

Reviewed by David Kilzer.

Make sure `this` is still alive when we execute the block on the main thread,
before running m_powerOnHander.

* Source/WebCore/platform/mac/PowerObserverMac.cpp:
(WebCore::PowerObserver::didReceiveSystemPowerNotification):
* Source/WebCore/platform/mac/PowerObserverMac.h:

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


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


[webkit-changes] [WebKit/WebKit] 6470a2: [IFC][Partial layout] Introduce LineLayout::update...

2023-02-25 Thread Alan Baradlay
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 6470a2ca1e161436b1ad5561e191c619d1b9db62
  
https://github.com/WebKit/WebKit/commit/6470a2ca1e161436b1ad5561e191c619d1b9db62
  Author: Alan Baradlay 
  Date:   2023-02-25 (Sat, 25 Feb 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/RenderText.cpp
M Source/WebCore/rendering/RenderText.h
M Source/WebCore/rendering/RenderTextFragment.cpp
M Source/WebCore/rendering/RenderTextFragment.h

  Log Message:
  ---
  [IFC][Partial layout] Introduce LineLayout::updateTextContent
https://bugs.webkit.org/show_bug.cgi?id=252793

Reviewed by Antti Koivisto.

This is in preparation for supporting partial change on existing renderers 
(e.g. text insert).
1. RenderText::setText/setTextWidthOffset consult 
shouldInvalidateLineLayoutPathAfterContentChange to check whether the content 
mutation is supported
2. They call LineLayout::updateTextContent (blank at this point) to compute the 
damage extent.

* Source/WebCore/layout/integration/LayoutIntegrationCoverage.cpp:
(WebCore::LayoutIntegration::shouldInvalidateLineLayoutPathAfterContentChangeFor):
* Source/WebCore/layout/integration/LayoutIntegrationCoverage.h:
* Source/WebCore/layout/integration/inline/LayoutIntegrationLineLayout.cpp:
(WebCore::LayoutIntegration::LineLayout::blockContainer):
(WebCore::LayoutIntegration::LineLayout::shouldInvalidateLineLayoutPathAfterContentChange):
(WebCore::LayoutIntegration::LineLayout::updateTextContent):
* Source/WebCore/layout/integration/inline/LayoutIntegrationLineLayout.h:
* Source/WebCore/rendering/RenderText.cpp:
(WebCore::invalidateLineLayoutPathOnContentChangeIfNeeded):
(WebCore::RenderText::setTextInternal):
(WebCore::RenderText::setText):
(WebCore::RenderText::setTextWithOffset):
* Source/WebCore/rendering/RenderText.h:

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


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


[webkit-changes] [WebKit/WebKit] 4660c2: Remove _inspectorDelegate methods

2023-02-25 Thread Rose
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 4660c27d821bd675b38c067ce0c43d66ab346f36
  
https://github.com/WebKit/WebKit/commit/4660c27d821bd675b38c067ce0c43d66ab346f36
  Author: Rose <83477269+ataridre...@users.noreply.github.com>
  Date:   2023-02-25 (Sat, 25 Feb 2023)

  Changed paths:
M Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm

  Log Message:
  ---
  Remove _inspectorDelegate methods

https://bugs.webkit.org/show_bug.cgi?id=252823
Reviewed by Alex Christensen.

We are now on Safari 16, which is after Safari 14. Hence, we can remove
the methods removed herein.

*Source\WebKit\UIProcess\API\Cocoa\WKWebView.mm:

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


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


[webkit-changes] [WebKit/WebKit] 85c350: Remove WebKitSetIsClassic check

2023-02-25 Thread Rose
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 85c350cb0b0b9e0f1e8c762caa208a8904273536
  
https://github.com/WebKit/WebKit/commit/85c350cb0b0b9e0f1e8c762caa208a8904273536
  Author: Rose <83477269+ataridre...@users.noreply.github.com>
  Date:   2023-02-25 (Sat, 25 Feb 2023)

  Changed paths:
M Source/WebKitLegacy/ios/Misc/WebUIKitSupport.h
M Source/WebKitLegacy/ios/Misc/WebUIKitSupport.mm
M Source/WebKitLegacy/ios/WebKit.iOS.exp

  Log Message:
  ---
  Remove WebKitSetIsClassic check
https://bugs.webkit.org/show_bug.cgi?id=252822

Reviewed by Alex Christensen.

This function is no longer being called, so we can remove it.

*Source\WebKitLegacy\ios\Misc\WebUIKitSupport.h:
*Source\WebKitLegacy\ios\Misc\WebUIKitSupport.mm:
*Source\WebKitLegacy\ios\WebKit.iOS.exp:

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


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


[webkit-changes] [WebKit/WebKit] 6aa0ef: Remove old and deprecated UIProcess functions

2023-02-25 Thread Rose
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 6aa0efabfa86bed906c718e69d96005316035e79
  
https://github.com/WebKit/WebKit/commit/6aa0efabfa86bed906c718e69d96005316035e79
  Author: Rose <83477269+ataridre...@users.noreply.github.com>
  Date:   2023-02-25 (Sat, 25 Feb 2023)

  Changed paths:
M Source/WebKit/UIProcess/API/C/WKPage.cpp
M Source/WebKit/UIProcess/API/C/WKPage.h
M Source/WebKit/UIProcess/API/C/WKPreferences.cpp
M Source/WebKit/UIProcess/API/C/WKPreferencesRef.h
M Source/WebKit/UIProcess/API/C/WKPreferencesRefPrivate.h
M Source/WebKit/UIProcess/API/Cocoa/WKPreferences.mm
M Source/WebKit/UIProcess/API/Cocoa/WKPreferencesPrivate.h
M Source/WebKit/mac/WebKit2.order
M Source/WebKitLegacy/mac/WebKit.order
M Source/WebKitLegacy/mac/WebView/WebPreferences.mm
M Source/WebKitLegacy/mac/WebView/WebPreferencesPrivate.h
M Tools/WebKitTestRunner/TestController.cpp

  Log Message:
  ---
  Remove old and deprecated UIProcess functions
https://bugs.webkit.org/show_bug.cgi?id=251879

Reviewed by Alex Christensen.

The code in question is literally code that was commented to be removed
under certain conditions that have been met years ago, such as no longer
compiling for Safari 8 and when Mavericks support is gone.

This is very very old code that is the removal of which is obvious but
has yet to be done.

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


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


[webkit-changes] [WebKit/WebKit] 07fd62: WPT css-nesting test should fit in 800*600 window

2023-02-25 Thread Matthieu Dubet
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 07fd62d3686f0f1e86e38e88d1541faaf7a925c4
  
https://github.com/WebKit/WebKit/commit/07fd62d3686f0f1e86e38e88d1541faaf7a925c4
  Author: Matthieu Dubet 
  Date:   2023-02-25 (Sat, 25 Feb 2023)

  Changed paths:
M LayoutTests/TestExpectations
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-nesting/nesting-basic-expected.html
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-nesting/nesting-basic-ref.html
M 
LayoutTests/imported/w3c/web-platform-tests/css/css-nesting/nesting-basic.html

  Log Message:
  ---
  WPT css-nesting test should fit in 800*600 window
https://bugs.webkit.org/show_bug.cgi?id=252928
rdar://105900204

Reviewed by Tim Nguyen.

WPT ref-tests are only check against a window of 800*600,
the rest of the page is ignored.

https://web-platform-tests.org/writing-tests/reftests.html#components-of-a-reftest

* LayoutTests/TestExpectations:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-nesting/nesting-basic-expected.html:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-nesting/nesting-basic-ref.html:
* 
LayoutTests/imported/w3c/web-platform-tests/css/css-nesting/nesting-basic.html:

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


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


[webkit-changes] [WebKit/WebKit] bfd300: Extract ProxyObject::validateGetTrapResult()

2023-02-25 Thread EWS
  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: bfd300fb86cf2b9e1ee5df937072e242fec2e577
  
https://github.com/WebKit/WebKit/commit/bfd300fb86cf2b9e1ee5df937072e242fec2e577
  Author: Alexey Shvayka 
  Date:   2023-02-25 (Sat, 25 Feb 2023)

  Changed paths:
M Source/JavaScriptCore/runtime/JSGlobalObject.cpp
M Source/JavaScriptCore/runtime/JSGlobalObjectFunctions.cpp
M Source/JavaScriptCore/runtime/JSGlobalObjectFunctions.h
M Source/JavaScriptCore/runtime/ProxyObject.cpp
M Source/JavaScriptCore/runtime/ProxyObject.h

  Log Message:
  ---
  Extract ProxyObject::validateGetTrapResult()
https://bugs.webkit.org/show_bug.cgi?id=252934


Reviewed by Yusuke Suzuki.

This patch is a small refactor prior to a follow-up change that
will make performing these checks conditional to remove of the fast path.

Also co-locates globalFuncHandleProxyGetTrapResult() with other globalFunc* 
helpers
and makes validateGetTrapResult() consistent with validateSetTrapResult* method.

* Source/JavaScriptCore/runtime/JSGlobalObject.cpp:
* Source/JavaScriptCore/runtime/JSGlobalObjectFunctions.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* Source/JavaScriptCore/runtime/JSGlobalObjectFunctions.h:
* Source/JavaScriptCore/runtime/ProxyObject.cpp:
(JSC::performProxyGet):
(JSC::ProxyObject::validateGetTrapResult):
* Source/JavaScriptCore/runtime/ProxyObject.h:

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


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