Branch: refs/heads/webkitglib/2.54
Home: https://github.com/WebKit/WebKit
Commit: 35db2268b99336973e4bdddd923e5caf773c6a32
https://github.com/WebKit/WebKit/commit/35db2268b99336973e4bdddd923e5caf773c6a32
Author: Vitaly Dyachkov <[email protected]>
Date: 2026-09-30 (Wed, 30 Sep 2026)
Changed paths:
M Source/WebKit/UIProcess/API/glib/WebKitFindController.cpp
M
Tools/TestWebKitAPI/Tests/WebKit/WKWebView/glib/TestWebKitFindController.cpp
Log Message:
-----------
Cherry-pick 322036@main (f4390ce9ebd9).
https://bugs.webkit.org/show_bug.cgi?id=325421
[GTK][WPE] `WebKitFindController::found-text` reports `match_count` of 1
after `search_next()`/`search_previous()`
https://bugs.webkit.org/show_bug.cgi?id=325421
Reviewed by Carlos Garcia Campos.
`webkit_find_controller_search()` emits `found-text` with the correct
number of matches. Subsequent calls to
`webkit_find_controller_search_next()` or
`webkit_find_controller_search_previous()` emit `found-text` with
`match_count == 1`, regardless of how many matches the page has.
Unconditionally add `WebKit::FindOptions::DetermineMatchIndex` to the
default find options.
Test:
Tools/TestWebKitAPI/Tests/WebKit/WKWebView/glib/TestWebKitFindController.cpp
* Source/WebKit/UIProcess/API/glib/WebKitFindController.cpp:
(webKitFindControllerPerform):
*
Tools/TestWebKitAPI/Tests/WebKit/WKWebView/glib/TestWebKitFindController.cpp:
(testFindControllerNext):
(testFindControllerPrevious):
Canonical link: https://commits.webkit.org/322036@main
Canonical link: https://commits.webkit.org/317695.372@webkitglib/2.54
Commit: 2e344ab20c997814f64dfd609ee812f7b2b04b69
https://github.com/WebKit/WebKit/commit/2e344ab20c997814f64dfd609ee812f7b2b04b69
Author: Vitaly Dyachkov <[email protected]>
Date: 2026-09-30 (Wed, 30 Sep 2026)
Changed paths:
M LayoutTests/inspector/timeline/timeline-layout-events-iframe.html
M LayoutTests/inspector/timeline/timeline-layout-events.html
M Source/WebInspectorUI/UserInterface/Controllers/TimelineManager.js
M Source/WebInspectorUI/UserInterface/Models/LayoutTimelineRecord.js
M Source/WebInspectorUI/UserInterface/Views/LayoutTimelineDataGridNode.js
M Source/WebInspectorUI/UserInterface/Views/LayoutTimelineView.js
Log Message:
-----------
Cherry-pick 321679@main (7cee00153e19).
https://bugs.webkit.org/show_bug.cgi?id=324533
Web Inspector: Add `domNode` to `LayoutTimelineRecord` import/export
https://bugs.webkit.org/show_bug.cgi?id=324533
Reviewed by Devin Rousso.
`LayoutTimelineRecord`'s `domNode` is not currently preserved by the
Timeline's import/export mechanism, so after importing a previously
exported recording, layout and rendering events lose the DOM node
associated with them.
Serialize `LayoutTimelineRecord`'s `domNode` in `toJSON` as its display
name and CSS path, and resolve it back to a live `WI.DOMNode` in
`fromJSON` by querying the document for that CSS path, falling back to
a plain `{displayName, cssPath}` placeholder when the node can no longer
be found.
This replicates the technique already used by `MediaTimelineRecord` for
the same purpose.
* Source/WebInspectorUI/UserInterface/Models/LayoutTimelineRecord.js:
(WI.LayoutTimelineRecord.async fromJSON):
(WI.LayoutTimelineRecord.prototype.toJSON):
(WI.LayoutTimelineRecord.prototype.get domNodeOrInfo):
(WI.LayoutTimelineRecord.prototype.get domNode): Deleted.
* Source/WebInspectorUI/UserInterface/Views/LayoutTimelineDataGridNode.js:
(WI.LayoutTimelineDataGridNode.prototype.createCellContent):
(WI.LayoutTimelineDataGridNode):
(WI.LayoutTimelineDataGridNode.prototype.get data):
* Source/WebInspectorUI/UserInterface/Views/LayoutTimelineView.js:
(WI.LayoutTimelineView.prototype._showHighlightForRecord):
* Source/WebInspectorUI/UserInterface/Controllers/TimelineManager.js:
(WI.TimelineManager.prototype._processRecord):
* LayoutTests/inspector/timeline/timeline-layout-events-iframe.html:
* LayoutTests/inspector/timeline/timeline-layout-events.html:
Canonical link: https://commits.webkit.org/321679@main
Canonical link: https://commits.webkit.org/317695.373@webkitglib/2.54
Commit: 39482dee8beb03a37326df028e8a7507390d56ea
https://github.com/WebKit/WebKit/commit/39482dee8beb03a37326df028e8a7507390d56ea
Author: Vitaly Dyachkov <[email protected]>
Date: 2026-09-30 (Wed, 30 Sep 2026)
Changed paths:
M Source/WebInspectorUI/UserInterface/Views/DataGrid.js
M Source/WebInspectorUI/UserInterface/Views/Table.js
Log Message:
-----------
Cherry-pick 321529@main (3aee8e1ae028).
https://bugs.webkit.org/show_bug.cgi?id=324565
Web Inspector: Blank gap in tables after resizing
https://bugs.webkit.org/show_bug.cgi?id=324565
Reviewed by Devin Rousso.
Resizing the Web Inspector window while a table has more rows than
currently fit can leave a blank gap at the bottom of the table.
Both `WI.Table` and `WI.DataGrid` only render the rows currently on
screen, and skip recomputing them unless something relevant changed.
The early return condition never checks if the container height has
changed since the last computation, so a resize could leave old rows
and spacer heights behind.
Force a recompute of the visible row window when the container height
changes.
* Source/WebInspectorUI/UserInterface/Views/DataGrid.js:
(WI.DataGrid.prototype.updateVisibleRows):
(WI.DataGrid.prototype._calculateOffsetHeight):
(WI.DataGrid.prototype._calculateScrollTop):
* Source/WebInspectorUI/UserInterface/Views/Table.js:
(WI.Table.prototype._updateVisibleRows):
Canonical link: https://commits.webkit.org/321529@main
Canonical link: https://commits.webkit.org/317695.374@webkitglib/2.54
Commit: 92a5c5f4ae05c057f9b6742425c7c9352e683f41
https://github.com/WebKit/WebKit/commit/92a5c5f4ae05c057f9b6742425c7c9352e683f41
Author: Simon Pena <[email protected]>
Date: 2026-09-30 (Wed, 30 Sep 2026)
Changed paths:
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/glib/TestInputMethodContext.cpp
Log Message:
-----------
Cherry-pick 322039@main (391642161045).
https://bugs.webkit.org/show_bug.cgi?id=325166
[GTK][WPE] Input method delete-surrounding deletes the wrong text in
contenteditable
https://bugs.webkit.org/show_bug.cgi?id=325166
Reviewed by Adrian Perez de Castro.
The input method sends delete-surrounding with an offset relative to the
caret. WebPage::deleteSurrounding
turned it into a position counted from the start of the editable content,
but then looked that position
up in the whole tree scope. For <input> and <textarea> both start at the
same place, because the text is
in the control's own shadow tree. For a contenteditable element in the
document they do not: the position
was shifted by all the text in the page before the element. With
<h1>Title</h1> before the element, a
delete of the last character selected "t" in the heading instead. The
heading is not editable, so
nothing was deleted.
Look the position up in the range from the start to the end of the editable
content. This is the same
range that getPlatformEditorState uses to build the surrounding text sent
to the input method, so the
input method's offsets and the lookup now count from the same place. The
range variables now use the same
names as in getPlatformEditorState: surroundingRange is the whole editable
content, and
cursorPositionRange goes from its start to the caret.
Also return without doing anything if the delete would start before the
start of the editable content.
The caret position is unsigned, so such an offset wrapped round to a very
large position, and the caret
jumped to the end. Bug 206352 fixed a crash in this case with a null check,
but resolveCharacterRange
now always returns a range, so that check no longer had any effect. GtkText
in GTK also rejects a delete
that starts before the start of the text.
Test:
Tools/TestWebKitAPI/Tests/WebKit/WKWebView/glib/TestInputMethodContext.cpp
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::deleteSurrounding):
*
Tools/TestWebKitAPI/Tests/WebKit/WKWebView/glib/TestInputMethodContext.cpp:
(testWebKitInputMethodContextDeleteSurroundingContentEditable):
(testWebKitInputMethodContextDeleteSurroundingBeforeStart):
(beforeAll):
Canonical link: https://commits.webkit.org/322039@main
Canonical link: https://commits.webkit.org/317695.375@webkitglib/2.54
Commit: d76f57cf4b613c485573b607934e2e5dd6f2bb03
https://github.com/WebKit/WebKit/commit/d76f57cf4b613c485573b607934e2e5dd6f2bb03
Author: Claudio Saavedra <[email protected]>
Date: 2026-09-30 (Wed, 30 Sep 2026)
Changed paths:
M Source/WebCore/platform/mediarecorder/MediaRecorderPrivateGStreamer.cpp
M Source/WebCore/platform/mediarecorder/MediaRecorderPrivateGStreamer.h
Log Message:
-----------
Cherry-pick 322151@main (5f7c29241feb).
https://bugs.webkit.org/show_bug.cgi?id=322814
[GStreamer] MediaRecorder stop blocks the main thread until the pipeline
has drained
https://bugs.webkit.org/show_bug.cgi?id=322814
Reviewed by Philippe Normand and Xabier Rodriguez-Calvar.
MediaRecorderPrivateBackend::stopRecording() flushed the pipeline and then
waited on the main thread, in 200ms steps and for up to two seconds, for the
EOS event to reach the sink. The flush stops and joins the streaming tasks
of
the aggregator and of the sources, so on a loaded machine the call can block
the main thread for several seconds, during which no event can be
dispatched.
imported/w3c/web-platform-tests/mediacapture-record/MediaRecorder-error.html
expects the error event within two seconds of a track change and fails when
that happens.
Send the EOS event and return right away, as the AVFoundation backend does.
Data fetches requested while the EOS event is in flight are deferred until
it
reaches the sink, or until the existing two seconds watchdog fires, so the
last fragment written by the muxer is still part of the final dataavailable
event. A pipeline error message now also releases the deferred fetches. The
flush is not needed: the queued samples are encoded before the EOS event
passes, which is what a stop should produce anyway.
* LayoutTests/platform/glib/TestExpectations: Remove the expectation for
the test.
* Source/WebCore/platform/mediarecorder/MediaRecorderPrivateGStreamer.cpp:
(WebCore::MediaRecorderPrivateBackend::MediaRecorderPrivateBackend):
(WebCore::MediaRecorderPrivateBackend::~MediaRecorderPrivateBackend):
(WebCore::MediaRecorderPrivateBackend::stopRecording):
(WebCore::MediaRecorderPrivateBackend::eosTimerFired):
(WebCore::MediaRecorderPrivateBackend::didReachEOS):
(WebCore::MediaRecorderPrivateBackend::fetchData):
(WebCore::MediaRecorderPrivateBackend::preparePipeline):
(WebCore::MediaRecorderPrivateBackend::notifyEOS):
* Source/WebCore/platform/mediarecorder/MediaRecorderPrivateGStreamer.h:
Canonical link: https://commits.webkit.org/322151@main
Canonical link: https://commits.webkit.org/317695.376@webkitglib/2.54
Compare: https://github.com/WebKit/WebKit/compare/74ed86e1701f...d76f57cf4b61
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
