[webkit-changes] [WebKit/WebKit] dee4f1: Unreviewed, fix the Catalyst build after 281844@main

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: dee4f12753e7a935fe46553d9193212556210919
  
https://github.com/WebKit/WebKit/commit/dee4f12753e7a935fe46553d9193212556210919
  Author: Wenson Hsieh 
  Date:   2024-08-05 (Mon, 05 Aug 2024)

  Changed paths:
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm

  Log Message:
  ---
  Unreviewed, fix the Catalyst build after 281844@main
rdar://133239668

Specify an explicit return value of `BOOL` for the lambda, which currently 
returns either `bool` or
`BOOL`.

* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView gestureRecognizerShouldBegin:]):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 26bb74: [iOS] Add an internal setting to allow the keyboar...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 26bb7484b4f6853b76ff5d3b2b843668f38ab019
  
https://github.com/WebKit/WebKit/commit/26bb7484b4f6853b76ff5d3b2b843668f38ab019
  Author: Wenson Hsieh 
  Date:   2024-08-05 (Mon, 05 Aug 2024)

  Changed paths:
A LayoutTests/fast/forms/ios/dismiss-keyboard-after-tapping-expected.txt
A LayoutTests/fast/forms/ios/dismiss-keyboard-after-tapping.html
M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
M Source/WebKit/SourcesCocoa.txt
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.h
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
A Source/WebKit/UIProcess/ios/WKScrollViewTrackingTapGestureRecognizer.h
A Source/WebKit/UIProcess/ios/WKScrollViewTrackingTapGestureRecognizer.mm
M Source/WebKit/UIProcess/ios/WKSyntheticTapGestureRecognizer.h
M Source/WebKit/UIProcess/ios/WKSyntheticTapGestureRecognizer.mm
M Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm
M Source/WebKit/WebKit.xcodeproj/project.pbxproj
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/WebPage.messages.in
M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm

  Log Message:
  ---
  [iOS] Add an internal setting to allow the keyboard to dismiss after tapping
https://bugs.webkit.org/show_bug.cgi?id=277551
rdar://130552664

Reviewed by Aditya Keerthi.

Add an internal setting to make it possible to dismiss the keyboard by tapping 
over the page,
regardless of whether the page prevents default on touch, mouse or click 
events. See below for more
details.

Test: fast/forms/ios/dismiss-keyboard-after-tapping.html

* LayoutTests/fast/forms/ios/dismiss-keyboard-after-tapping-expected.txt: Added.
* LayoutTests/fast/forms/ios/dismiss-keyboard-after-tapping.html: Added.

Add a test case to verify that after focusing a text field with the new flag 
enabled:

1.  Tapping within the focused field does not dismiss the keyboard.
2.  Tapping another text field keeps the keyboard up.
3.  Tapping an empty part of the page that prevents `touchend`, `mousedown` and 
`click` dismisses
the keyboard.

* Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml:
* Source/WebKit/SourcesCocoa.txt:
* Source/WebKit/UIProcess/WebPageProxy.h:
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.h:
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _createAndConfigureDoubleTapGestureRecognizer]):
(-[WKContentView setUpInteraction]):
(-[WKContentView cleanUpInteraction]):

Add a new gesture, `_keyboardDismissalGestureRecognizer`, that's only enabled 
when the new setting
is enabled, and whose only purpose is to drive keyboard dismissal. This is a 
new gesture recognizer
because:

a.  We should recognize a tap regardless of whether default was prevented, so 
we can't key off of
the synthetic click gesture.

b.  We should not recognize in the case where the user is double tapping the 
page to zoom out (i.e.
single tap recognition should be delayed by double tap).

(-[WKContentView _removeDefaultGestureRecognizers]):
(-[WKContentView _addDefaultGestureRecognizers]):
(-[WKContentView 
gestureRecognizer:shouldRecognizeSimultaneouslyWithGestureRecognizer:]):
(-[WKContentView gestureRecognizerShouldBegin:]):

Bail early from the keyboard dismissal gesture if any of the following are true:
1. The keyboard is not shown.
2. The tap is inside of the focused element.
3. A hidden contenteditable element has focus.
4. The tap gesture is used to stop momentum scrolling.

(-[WKContentView _keyboardDismissalGestureRecognized:]):

Asynchronously check if a tap at this location should result in keyboard 
dismissal using
`shouldDismissKeyboardAfterTapAtPoint` (see below).

(-[WKContentView 
deferringGestureRecognizer:shouldDeferOtherGestureRecognizer:]):
* Source/WebKit/UIProcess/ios/WKScrollViewTrackingTapGestureRecognizer.h: 
Copied from Source/WebKit/UIProcess/ios/WKSyntheticTapGestureRecognizer.h.
* Source/WebKit/UIProcess/ios/WKScrollViewTrackingTapGestureRecognizer.mm: 
Copied from Source/WebKit/UIProcess/ios/WKSyntheticTapGestureRecognizer.h.
(-[WKScrollViewTrackingTapGestureRecognizer reset]):
(-[WKScrollViewTrackingTapGestureRecognizer touchesBegan:withEvent:]):

Split out logic to keep track of the last touched scroll view out into a 
separate class, which we
use for the new gesture recognizer. This allows us to check whether the 
keyboard dismissal tap
gesture was recognized while momentum scrolling, in which case we don't allow 
it to recognize.

* Source/WebKit/UIProcess/ios/WKSyntheticTapGestureRecognizer.h:
* Source/WebKit/UIProcess/ios/WKSyntheticTapGestureRecognizer.mm:
(-[WKSyntheticTapGestureRecognizer reset]):
(-[WKSyntheticTapGestureRecognizer touchesBegan:withEvent:]): Deleted.
(-[WKSyntheticTapGestureRecognizer lastTouchedScrollView]): Deleted.
* Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm

[webkit-changes] [WebKit/WebKit] a08ec0: [ Sonoma Release ] 2 Storage API tests are flaky t...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: a08ec0dd1f5593f7845b88891bae4d23f1399b88
  
https://github.com/WebKit/WebKit/commit/a08ec0dd1f5593f7845b88891bae4d23f1399b88
  Author: Wenson Hsieh 
  Date:   2024-08-01 (Thu, 01 Aug 2024)

  Changed paths:
M Tools/TestWebKitAPI/Tests/WebKitCocoa/IndexedDBTempFileSize.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/LocalStoragePersistence.mm

  Log Message:
  ---
  [ Sonoma Release ] 2 Storage API tests are flaky timeouts.
https://bugs.webkit.org/show_bug.cgi?id=277455
rdar://132941950

Reviewed by Abrar Rahman Protyasha.

Adjust two API tests, IndexedDB.IndexedDBTempFileSize and 
WKWebView.LocalStorageProcessCrashes, so
that they're more robust. Currently, these tests both trigger actions that 
cause the web process to
post exactly two script messages and then use the following pattern to wait for 
both messages to be
received in `TestWebKitAPI`:

```
receivedScriptMessage = false;
TestWebKitAPI::Util::run(); // <--- (a)

receivedScriptMessage = false;
TestWebKitAPI::Util::run(); // <--- (b)
```

...however, it's possible for both messages to be posted right after each other 
in the UI process,
causing *both* messages to be received when the runloop turns in step (a), 
marked above. This
results in a timeout, as (b) will never return since the second message has 
already been received.

To avoid this flaky timeout, we can simply refactor these two tests so that we 
wait for the second
message to be received in the UI process, keep track of all messages received 
in an array, and then
check the contents of the array instead of the last received message.

* Tools/TestWebKitAPI/Tests/WebKitCocoa/IndexedDBTempFileSize.mm:
(-[IndexedDBFileSizeMessageHandler 
userContentController:didReceiveScriptMessage:]):
(TEST(IndexedDB, IndexedDBTempFileSize)):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/LocalStoragePersistence.mm:
(-[LocalStorageMessageHandler userContentController:didReceiveScriptMessage:]):
(TEST(WKWebView, LocalStorageProcessCrashes)):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] b8175c: Click simulation should be able to target clickabl...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: b8175c8e661431d426d0ab8efe0459d8dd20c98b
  
https://github.com/WebKit/WebKit/commit/b8175c8e661431d426d0ab8efe0459d8dd20c98b
  Author: Wenson Hsieh 
  Date:   2024-07-31 (Wed, 31 Jul 2024)

  Changed paths:
M Source/WebCore/editing/TextIterator.h
M Source/WebCore/html/HTMLInputElement.h
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/SimulateClickOverText.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/click-targets.html

  Log Message:
  ---
  Click simulation should be able to target clickable elements with matching 
accessibility labels
https://bugs.webkit.org/show_bug.cgi?id=277423
rdar://132902431

Reviewed by Abrar Rahman Protyasha.

When the target text passed to 
`simulateClickOverFirstMatchingTextInViewportWithUserInteraction`
does not match any visible text on the webpage, fall back to searching all 
hit-testable elements in
the viewport (using an area-based hit-test) for elements that have relevant 
accessibility labels
(`aria-label`) or semantically interesting DOM attributes (e.g. `value` for 
button inputs), which
match the target text.

* Source/WebCore/editing/TextIterator.h:
* Source/WebCore/html/HTMLInputElement.h:
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::simulateClickOverFirstMatchingTextInViewportWithUserInteraction):

See above for more details. Also make a slight adjustment here to return `true` 
in the completion
handler, even if the event was not handled as a default action or prevented by 
the page. This is
because mouse or click events may still result in interesting changes on the 
page even if the event
is not prevented, so it's better to err on the side of not reporting an error 
if we do end up
dispatching synthetic events over a target element.

* Tools/TestWebKitAPI/Tests/WebKitCocoa/SimulateClickOverText.mm:
(TestWebKitAPI::TEST(SimulateClickOverText, ClickTargets)):
(TestWebKitAPI::TEST(SimulateClickOverText, ClickTargetsAfterScrolling)):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/click-targets.html:

Augment these two API tests to cover more scenarios, where the click targets 
are:
• `input` of type `"button"`.
• `input` of type `"submit"`.
• `div` with click handler and accessibility label.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] d15c4b: [Remote Inspection] Refactor ElementTargetingContr...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: d15c4b4addcad589c6dda36bc3bde03a78da1e10
  
https://github.com/WebKit/WebKit/commit/d15c4b4addcad589c6dda36bc3bde03a78da1e10
  Author: Wenson Hsieh 
  Date:   2024-07-30 (Tue, 30 Jul 2024)

  Changed paths:
M Source/WebCore/page/ElementTargetingController.cpp

  Log Message:
  ---
  [Remote Inspection] Refactor ElementTargetingController to avoid a rare 
nullptr crash
https://bugs.webkit.org/show_bug.cgi?id=277371
rdar://132831879

Reviewed by Aditya Keerthi.

This is a speculative fix for a `nullptr` (or `CheckedPtr`) crash, due to the 
fact that `renderer`
is a `CheckedPtr` below:

```
CheckedPtr renderer = element.renderer();

…

return {
.elementIdentifier = element.identifier(),
.documentIdentifier = element.document().identifier(),
.offsetEdges = computeOffsetEdges(renderer->style()),   // 
<--- A
.renderedText = WTFMove(renderedText),
.searchableText = searchableTextForTarget(element), // 
<--- B
.screenReaderText = WTFMove(screenReaderText),
.selectors = selectorsForTarget(element, cache),
.boundsInRootView = element.boundingBoxInRootViewCoordinates(),
.boundsInClientCoordinates = computeClientRect(*renderer),  // 
<--- C

…
};
```

Because we may update layout in (B) (and rebuild parts of the render tree in 
the process), it's
possible for the renderer to become null by the time we get to line (C). To 
address this, we make
the `renderer` a `WeakPtr` and limit its lifetime to only code that accesses 
information from
`RenderStyle` and geometry information, without updating layout.

No new test case, since it only seemed to reproduce once.

* Source/WebCore/page/ElementTargetingController.cpp:
(WebCore::targetedElementInfo):
(WebCore::ElementTargetingController::extractTargets):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 72212a: [macOS] Dictation UI no longer shows up when begin...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 72212a28c6b2c3b605bebb33a5c9e14196952586
  
https://github.com/WebKit/WebKit/commit/72212a28c6b2c3b605bebb33a5c9e14196952586
  Author: Wenson Hsieh 
  Date:   2024-07-28 (Sun, 28 Jul 2024)

  Changed paths:
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Tools/TestWebKitAPI/Tests/mac/WKWebViewMacEditingTests.mm

  Log Message:
  ---
  [macOS] Dictation UI no longer shows up when beginning dictation after 
focusing an empty text field
https://bugs.webkit.org/show_bug.cgi?id=277236
rdar://131534054

Reviewed by Richard Robinson.

After the changes in 279576@main, 
`-firstRectForCharacterRange:completionHandler:` returns an empty
rect in the case where the selection is a caret in a focused, empty `textarea` 
or text field. This
happens because the selected range is the first position inside of an empty 
block-level container
underneath the text form control's shadow root, which causes `endOfLine` to 
return the null position
and subsequently means `lineEndBoundary` is null, so we bail early.

Avoid this by falling back to the selection start in the case where `endOfLine` 
returns a null
position.

Test: WKWebViewMacEditingTests.FirstRectForCharacterRangeInTextArea

* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::firstRectForCharacterRangeAsync):

See above for more details.

* Tools/TestWebKitAPI/Tests/mac/WKWebViewMacEditingTests.mm:
(-[WKWebView _firstRectForCharacterRange:]):
(TEST(WKWebViewMacEditingTests, FirstRectForCharacterRange)):
(TEST(WKWebViewMacEditingTests, FirstRectForCharacterRangeInTextArea)):

Add a new API test to exercise the change; clean up some of these existing 
tests as well, by
factoring out some of the common logic to asynchronously request the first rect 
for a
character range into a new category helper method that returns a `std::pair`.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 38771c: [Remote Inspection] numberOfVisibilityAdjustmentRe...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 38771c35ceb476acc7d75e856add5df546ec8db3
  
https://github.com/WebKit/WebKit/commit/38771c35ceb476acc7d75e856add5df546ec8db3
  Author: Wenson Hsieh 
  Date:   2024-07-27 (Sat, 27 Jul 2024)

  Changed paths:
M Source/WebCore/page/ElementTargetingController.cpp
M Source/WebCore/page/ElementTargetingController.h
M Source/WebCore/page/LocalFrame.cpp
M Source/WebCore/page/Page.cpp
M Source/WebCore/page/Page.h
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm

  Log Message:
  ---
  [Remote Inspection] numberOfVisibilityAdjustmentRects returns 0 after loading 
from back/forward cache
https://bugs.webkit.org/show_bug.cgi?id=277187
rdar://132521358

Reviewed by Richard Robinson.

`ElementTargetingController`'s set of `m_adjustedElements` is currently reset 
whenever a load is
committed. This causes `numberOfVisibilityAdjustmentRects()` to always return 0 
when the current
document has been restored from the back/forward cache, since adjustment state 
persists on the DOM
nodes in the new document, but `m_adjustedElements` is empty.

To address this, we:

1.  Keep track of a `WeakSet` of documents wherein we've previously applied 
adjustments.

2.  Add plumbing to inform `ElementTargetingController` when the main document 
will change; if the
new document is one where we've previously applied adjustments, then set a 
boolean flag,
`m_shouldRecomputeAdjustedElements`, to indicate that we need to lazily 
compute
`m_adjustedElements` if the client ever asks for the adjusted rect count.

3.  If `m_shouldRecomputeAdjustedElements` is set and

This design ensures that we do no additional work (i.e. the full tree 
traversal) in the following
scenarios:

(a) No element has ever been adjusted in the document we're loading.
(b) The client never requests the adjustment rect count.

* Source/WebCore/page/ElementTargetingController.cpp:
(WebCore::ElementTargetingController::adjustVisibility):
(WebCore::ElementTargetingController::adjustVisibilityInRepeatedlyTargetedRegions):
(WebCore::ElementTargetingController::applyVisibilityAdjustmentFromSelectors):
(WebCore::ElementTargetingController::didChangeMainDocument):
(WebCore::ElementTargetingController::numberOfVisibilityAdjustmentRects):
(WebCore::ElementTargetingController::recomputeAdjustedElementsIfNeeded):

Collect the set of elements with active visibility adjustments, if necessary. 
See above for more
details.

(WebCore::ElementTargetingController::numberOfVisibilityAdjustmentRects const): 
Deleted.

Make this non-const, now that it invokes `recomputeAdjustedElementsIfNeeded`.

* Source/WebCore/page/ElementTargetingController.h:
* Source/WebCore/page/LocalFrame.cpp:
(WebCore::LocalFrame::setDocument):
* Source/WebCore/page/Page.cpp:
(WebCore::Page::didChangeMainDocument):

Additionally plumb the new document through `didChangeMainDocument()`. Perhaps 
counterintuitively,
`didChangeMainDocument` is invoked *before* the main frame's document has 
actually changed to the
new value.

* Source/WebCore/page/Page.h:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm:
(TestWebKitAPI::TEST(ElementTargeting, 
CountVisibilityAdjustmentsAfterNavigatingBack)):

Add a new API test to exercise the change.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 0a5b0a: Dynamic viewport expansion heuristic does not work...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 0a5b0aa9a91f97e7a2e2d4e308356b7f7b3520d3
  
https://github.com/WebKit/WebKit/commit/0a5b0aa9a91f97e7a2e2d4e308356b7f7b3520d3
  Author: Wenson Hsieh 
  Date:   2024-07-26 (Fri, 26 Jul 2024)

  Changed paths:
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm

  Log Message:
  ---
  Dynamic viewport expansion heuristic does not work on bigfishgames.com
https://bugs.webkit.org/show_bug.cgi?id=277113
rdar://128572358

Reviewed by Richard Robinson.

Adjust the viewport height expansion heuristic once again, so that we trigger 
an update whenever a
fixed-position container finishes animating. Additionally, add logic to 
throttle these updates to
a maximum of one every ~200 ms, to prevent websites with constantly-running 
animations from either
(1) indefinitely deferring updates, or (2) triggering constant and frequent 
updates.

* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::didCommitLoad):
(WebKit::WebPage::didAddOrRemoveViewportConstrainedObjects):

Move this logic into a common helper method, 
`scheduleLayoutViewportHeightExpansionUpdate`.

* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::completeSyntheticClick):

Also, schedule an update whenever synthetic click events are dispatched (i.e. 
user taps the screen).

(WebKit::WebPage::scheduleLayoutViewportHeightExpansionUpdate):
(WebKit::WebPage::updateLayoutViewportHeightExpansionTimerFired):
(WebKit::WebPage::animationDidFinishForElement):
(WebKit::WebPage::scheduleEditorStateUpdateAfterAnimationIfNeeded):

Pull this existing logic for scheduling an EditorState update after completing 
an animation out into
a separate helper method.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 9ecd55: Unreviewed, add a couple of missing header include...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 9ecd5544bc460820fdf266e3c934e91cb2ea3669
  
https://github.com/WebKit/WebKit/commit/9ecd5544bc460820fdf266e3c934e91cb2ea3669
  Author: Wenson Hsieh 
  Date:   2024-07-24 (Wed, 24 Jul 2024)

  Changed paths:
M Source/WebCore/page/Quirks.cpp
M Source/WebKit/UIProcess/mac/WKImmediateActionController.mm

  Log Message:
  ---
  Unreviewed, add a couple of missing header includes (due to source 
unification)

Add a couple of missing header includes to fix the build without unified 
sources.

* Source/WebCore/page/Quirks.cpp:
* Source/WebKit/UIProcess/mac/WKImmediateActionController.mm:

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 1aa0ec: Avoid surfacing invisible `pointer-events: none; ` ...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 1aa0ecbc9e1bc8f99ae9a9f6484f32d0dced128f
  
https://github.com/WebKit/WebKit/commit/1aa0ecbc9e1bc8f99ae9a9f6484f32d0dced128f
  Author: Wenson Hsieh 
  Date:   2024-07-24 (Wed, 24 Jul 2024)

  Changed paths:
M 
LayoutTests/fast/element-targeting/targeted-element-ignores-pointer-events-none-overlay-expected.txt
M 
LayoutTests/fast/element-targeting/targeted-element-ignores-pointer-events-none-overlay.html
M Source/WebCore/page/ElementTargetingController.cpp

  Log Message:
  ---
  Avoid surfacing invisible `pointer-events: none;` elements with a single 
rendered child as targets
https://bugs.webkit.org/show_bug.cgi?id=277011
rdar://130710791

Reviewed by Abrar Rahman Protyasha.

Make a small adjustment to target an only child below a fixed-position 
`pointer-events: none;` or a
negative `z-index` when selecting targets for remote inspection (as opposed to 
targeting the outer
container).

* 
LayoutTests/fast/element-targeting/targeted-element-ignores-pointer-events-none-overlay-expected.txt:
* 
LayoutTests/fast/element-targeting/targeted-element-ignores-pointer-events-none-overlay.html:
* Source/WebCore/page/ElementTargetingController.cpp:
(WebCore::ElementTargetingController::extractTargets):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] b9e8a1: Unreviewed, fix internal iOS family builds after 2...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: b9e8a1a14a18aebb7dab6b39888963f2f28fbb8e
  
https://github.com/WebKit/WebKit/commit/b9e8a1a14a18aebb7dab6b39888963f2f28fbb8e
  Author: Wenson Hsieh 
  Date:   2024-07-24 (Wed, 24 Jul 2024)

  Changed paths:
M Source/WebCore/dom/Node.cpp

  Log Message:
  ---
  Unreviewed, fix internal iOS family builds after 281285@main
rdar://132403886

Reinclude `TouchEvent.h`, since we reference the class in 
`Node::defaultEventHandler`.

Also, remove a redundant include for `WebCoreOpaqueRoot.h`.

* Source/WebCore/dom/Node.cpp:

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 3438b4: [tvOS] Disable the default text context menu inter...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 3438b4a0f7342beedb09b8fce78185c802489978
  
https://github.com/WebKit/WebKit/commit/3438b4a0f7342beedb09b8fce78185c802489978
  Author: Wenson Hsieh 
  Date:   2024-07-23 (Tue, 23 Jul 2024)

  Changed paths:
M Source/WebKit/UIProcess/ios/WKTextInteractionWrapper.mm

  Log Message:
  ---
  [tvOS] Disable the default text context menu interaction
https://bugs.webkit.org/show_bug.cgi?id=276983
rdar://132339317

Reviewed by Aditya Keerthi.

Disable the text context menu on tvOS by removing the associated context menu 
interaction from
`WKContentView`.

* Source/WebKit/UIProcess/ios/WKTextInteractionWrapper.mm:
(-[WKTextInteractionWrapper initWithView:]):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 5081bf: [iOS] Adjust the viewport expansion heuristic to b...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 5081bf058b8d9343d7f7227b486e02e47e31ed2d
  
https://github.com/WebKit/WebKit/commit/5081bf058b8d9343d7f7227b486e02e47e31ed2d
  Author: Wenson Hsieh 
  Date:   2024-07-21 (Sun, 21 Jul 2024)

  Changed paths:
M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm

  Log Message:
  ---
  [iOS] Adjust the viewport expansion heuristic to better detect full-page 
modal containers
https://bugs.webkit.org/show_bug.cgi?id=276849
rdar://132160090

Reviewed by Abrar Rahman Protyasha.

Make some more adjustments to the layout viewport expansion heuristic:

-   When hit-testing to see if there's a large modal container covering most of 
the viewport,
perform an area-based hit-test in the entire viewport. This avoids a false 
negative in the case
where the center of the viewport hit-tests to a smaller fixed-position 
container that does not
cover the screen.

-   Don't re-expand to double height after shrinking, to avoid cases where the 
viewport height might
thrash too frequently.

* Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::updateLayoutViewportHeightExpansionTimerFired):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 26daa5: [iOS 18] Web view lays out at the wrong dimensions...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 26daa5456ac48a643162f426bb1ebebe6e46a5e5
  
https://github.com/WebKit/WebKit/commit/26daa5456ac48a643162f426bb1ebebe6e46a5e5
  Author: Wenson Hsieh 
  Date:   2024-07-16 (Tue, 16 Jul 2024)

  Changed paths:
M Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h
M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm

  Log Message:
  ---
  [iOS 18] Web view lays out at the wrong dimensions after rotating in element 
fullscreen
https://bugs.webkit.org/show_bug.cgi?id=276661
rdar://131329311

Reviewed by Richard Robinson.

After the changes in 279030@main to enable live resize on iPad along with the 
rest of the
`BrowserEngineKit` integration when `UIKit/async_text_input_ipad` is enabled, 
rotating the device
on YouTube.com while watching a video in element fullscreen mode causes the 
webpage to lay out at
the wrong dimensions after rotation for about 500 ms, before adjusting to the 
new size.

This happens because the codepaths to engage live resize in response to frame 
or bounds changes
activates now, when it didn't before the change. This codepath was previously 
guarded by a check for
`-[UIWindowScene _isInLiveResize]`, which was only set when adjusting the 
dimensions of the window
in Stage Manager. However, since 279030@main stopped using that SPI in favor of 
matching the
automatic live resize behavior on visionOS, we no longer have that constraint, 
and will enter this
live resize codepath in more cases (e.g. when changing the interface 
orientation).

To mitigate this, we reintroduce some more constraints, to avoid automatic live 
resize in a couple
of cases:

1.  Only the window height is changing (there's typically no need to keep the 
web view stable in
this case, since we'd just reveal more content underneath the previous 
viewport which could be
scrolled to anyways).

2.  The window is changing interface orientation (to address the immediate 
cause of this issue).

* Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h:

Keep track of the last known interface orientation, in addition to the last 
known window size.

* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm:
(-[WKWebView _updateLastKnownWindowSizeAndOrientation]):
(-[WKWebView didMoveToWindow]):
(-[WKWebView _beginAutomaticLiveResizeIfNeeded]):
(-[WKWebView _frameOrBoundsWillChange]):

See above for more details.

(-[WKWebView _updateLastKnownWindowSize]): Deleted.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] e00498: Add a way for WKWebView clients to simulate a clic...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: e004985d096c19792336fb1ef1fd9f0ce825e02a
  
https://github.com/WebKit/WebKit/commit/e004985d096c19792336fb1ef1fd9f0ce825e02a
  Author: Wenson Hsieh 
  Date:   2024-07-15 (Mon, 15 Jul 2024)

  Changed paths:
M Source/WebCore/dom/BoundaryPoint.cpp
M Source/WebCore/dom/BoundaryPoint.h
M Source/WebCore/dom/Node.h
M Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm
M Source/WebKit/UIProcess/API/Cocoa/WKWebViewPrivate.h
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/WebPage.messages.in
M Tools/TestWebKitAPI/SourcesCocoa.txt
M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
A Tools/TestWebKitAPI/Tests/WebKitCocoa/SimulateClickOverText.mm
A Tools/TestWebKitAPI/Tests/WebKitCocoa/click-targets.html

  Log Message:
  ---
  Add a way for WKWebView clients to simulate a click over visible text in the 
page
https://bugs.webkit.org/show_bug.cgi?id=276613
rdar://131758473

Reviewed by Ryosuke Niwa.

Add a way to simulate mouse events over clickable elements on the webpage, 
based on matches of found
text. See below for more details.

Tests:  SimulateClickOverText.ClickTargets
SimulateClickOverText.ClickTargetsAfterScrolling

* Source/WebCore/dom/BoundaryPoint.cpp:
(WebCore::treeOrderInternal):
(WebCore::treeOrder):

Export only `treeOrder(const BoundaryPoint&, const 
BoundaryPoint&)`.

(WebCore::treeOrder):
* Source/WebCore/dom/BoundaryPoint.h:
* Source/WebCore/dom/Node.h:

Add `WEBCORE_EXPORT`s to several methods and helper functions.

* Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView _pauseNowPlayingMediaSession:]):
(-[WKWebView 
_simulateClickOverFirstMatchingTextInViewportWithUserInteraction:completionHandler:]):
* Source/WebKit/UIProcess/API/Cocoa/WKWebViewPrivate.h:
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::simulateClickOverFirstMatchingTextInViewportWithUserInteraction):

Add plumbing from `WKWebView` -> `WebPageProxy` -> `WebPage`.

* Source/WebKit/UIProcess/WebPageProxy.h:
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::simulateClickOverFirstMatchingTextInViewportWithUserInteraction):

Implement the main heuristic here. At a high level, this is how it works:

1.  Use `findPlainText` to search for the target text in the main document.
2.  Filter out any matches that aren't within links, or otherwise clickable 
containers by walking up
the composed tree.
3.  Compute the first text rect (in content coordinates) for each matching 
range; filter out any
matches that are outside of the visual viewport.
4.  Perform one final hit-test to filter out potential targets that are 
obscured.
5.  If there are 2 or more candidates after the above filtering, exit early and 
don't attempt to
click anything (we may need a more sophisticated strategy to deal with 
ambiguous targets in the
future).
6.  Otherwise, if there is exactly one match, create and send synthetic click 
events.

* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Source/WebKit/WebProcess/WebPage/WebPage.messages.in:
* Tools/TestWebKitAPI/SourcesCocoa.txt:
* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/SimulateClickOverText.mm: Added.
(-[WKWebView simulateClickOverText:]):
(TestWebKitAPI::TEST(SimulateClickOverText, ClickTargets)):
(TestWebKitAPI::TEST(SimulateClickOverText, ClickTargetsAfterScrolling)):

Add a couple of API tests to exercise the new functionality by verifying that 
mouse and click events
are dispatched on several types of visible (and clickable) DOM elements when 
simulating clicks based
on found text.

* Tools/TestWebKitAPI/Tests/WebKitCocoa/click-targets.html: Added.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 1308aa: Unreviewed, fix the macOS Ventura build after 2809...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 1308aad8fbeb042da1b1faef99efec0abb8753cf
  
https://github.com/WebKit/WebKit/commit/1308aad8fbeb042da1b1faef99efec0abb8753cf
  Author: Wenson Hsieh 
  Date:   2024-07-15 (Mon, 15 Jul 2024)

  Changed paths:
M Source/WebCore/PAL/pal/spi/cocoa/VisionKitCoreSPI.h

  Log Message:
  ---
  Unreviewed, fix the macOS Ventura build after 280955@main

`-[VKWKLineInfo layoutDirection]` is only available on Sonoma and later. Move 
this declaration back
into a staging category for now — we can move entirely off of this staging 
declaration anyways, once
Sonoma becomes the minimum supported macOS version.

* Source/WebCore/PAL/pal/spi/cocoa/VisionKitCoreSPI.h:

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 691008: [iPadOS] Plumb the image rect in root view space t...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 6910086011dac0a98069ee26156aecbe087dc367
  
https://github.com/WebKit/WebKit/commit/6910086011dac0a98069ee26156aecbe087dc367
  Author: Wenson Hsieh 
  Date:   2024-07-14 (Sun, 14 Jul 2024)

  Changed paths:
M Source/WebCore/PAL/pal/spi/cocoa/VisionKitCoreSPI.h
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Tools/TestWebKitAPI/cocoa/ImageAnalysisTestingUtilities.mm
M Tools/WebKitTestRunner/cocoa/TestControllerCocoa.mm

  Log Message:
  ---
  [iPadOS] Plumb the image rect in root view space to VKCImageAnalysis when 
long pressing a QR code
https://bugs.webkit.org/show_bug.cgi?id=276593
rdar://131643168

Reviewed by Richard Robinson.

Adopt the new `rectForMrcActionInPresentingViewController` property on 
`VKCImageAnalysis` when
presenting a context menu for QR codes. This allows the `Add to Calendar` 
action (which shows a
popover on iPad) to present from the long-pressed image, after the changes in 
rdar://119388199.

* Source/WebCore/PAL/pal/spi/cocoa/VisionKitCoreSPI.h:
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView updateImageAnalysisForContextMenuPresentation:elementBounds:]):
(-[WKContentView 
_completeImageAnalysisRequestForContextMenu:requestIdentifier:hasTextResults:]):

Also move the call to `-updateImageAnalysisForContextMenuPresentation:` up 
before we ask for
`-mrcMenu`, so that the rect for MRC menu actions is honored when VisionKit 
creates the menu item.

(-[WKContentView updateImageAnalysisForContextMenuPresentation:]): Deleted.
* Tools/TestWebKitAPI/cocoa/ImageAnalysisTestingUtilities.mm:
* Tools/WebKitTestRunner/cocoa/TestControllerCocoa.mm:

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 0c29e6: [Remote Inspection] `elementAndAncestorsAreOnlyRen...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 0c29e60b7f0a3238a625297d8c6a6c6b57ec1bb7
  
https://github.com/WebKit/WebKit/commit/0c29e60b7f0a3238a625297d8c6a6c6b57ec1bb7
  Author: Wenson Hsieh 
  Date:   2024-07-11 (Thu, 11 Jul 2024)

  Changed paths:
A 
LayoutTests/fast/element-targeting/target-container-with-anonymous-sibling-expected.txt
A 
LayoutTests/fast/element-targeting/target-container-with-anonymous-sibling.html
M LayoutTests/resources/ui-helper.js
M Source/WebCore/page/ElementTargetingController.cpp

  Log Message:
  ---
  [Remote Inspection] `elementAndAncestorsAreOnlyRenderedChildren` sometimes 
yields false positives
https://bugs.webkit.org/show_bug.cgi?id=276503
rdar://131535241

Reviewed by Megan Gardner and Abrar Rahman Protyasha.

`elementAndAncestorsAreOnlyRenderedChildren` is currently incorrect in the case 
where a parent
renderer has anonymous renderers as children, for which `element()` is null. 
This causes us to
(falsely) assume that certain elements are only children in the render tree 
(along with all of their
ancestors), and avoid surfacing them as target candidates.

Fix this by refactoring the function, such that it doesn't ignore anonymous 
renderers.

* 
LayoutTests/fast/element-targeting/target-container-with-anonymous-sibling-expected.txt:
 Added.
* 
LayoutTests/fast/element-targeting/target-container-with-anonymous-sibling.html:
 Added.
* LayoutTests/resources/ui-helper.js:
(window.UIHelper.adjustVisibilityForFrontmostTarget):
* Source/WebCore/page/ElementTargetingController.cpp:
(WebCore::elementAndAncestorsAreOnlyRenderedChildren):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] c8c3aa: REGRESSION (visionOS 2): Yahoo and AOL login pages...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: c8c3aac34000d459e3d3a3408a891f934d8ed262
  
https://github.com/WebKit/WebKit/commit/c8c3aac34000d459e3d3a3408a891f934d8ed262
  Author: Wenson Hsieh 
  Date:   2024-07-09 (Tue, 09 Jul 2024)

  Changed paths:
M Source/WebCore/platform/ios/LocalCurrentTraitCollection.h
M Source/WebCore/platform/ios/LocalCurrentTraitCollection.mm
M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm

  Log Message:
  ---
  REGRESSION (visionOS 2): Yahoo and AOL login pages flicker when adding a new 
Mail account
https://bugs.webkit.org/show_bug.cgi?id=276387
rdar://129308652

Reviewed by Aditya Keerthi.

On visionOS 2, after (what are probably) the changes in either rdar://117186193 
or rdar://117807846,
the following logic:

```
auto userInterfaceStyleTrait = [UITraitCollection 
traitCollectionWithUserInterfaceStyle:UIUserInterfaceStyleLight];
auto backgroundLevelTrait = [UITraitCollection 
traitCollectionWithUserInterfaceLevel:UIUserInterfaceLevelBase];
auto combinedTrait = [UITraitCollection 
traitCollectionWithTraitsFromCollections:@[ originalTrait.get(), 
userInterfaceStyleTrait, backgroundLevelTrait ]];
```

...no longer yields a `combinedTrait` that has a user interface idiom of 
`vision`, in the case
where `originalTrait` had a user interface of `vision`. Instead, the idiom 
reverts to `unspecified`,
which breaks downstream logic that attempts to override the user interface 
idiom in visionOS to be
equal to `pad`.

Subsequently, this causes `+[UIColor systemBackgroundColor]` to return 
transparent black instead of
white in `RenderThemeIOS::cssValueToSystemColorMap()`, which ultimately causes 
the page background
to be (incorrectly) transparent in `SLYahooAuthService`, leading to a flash as 
the page loads.

Interestingly...

(1) `+traitCollectionWithTraitsFromCollections:` is deprecated anyways, in 
favor of
`-traitCollectionByModifyingTraits:` or `+traitCollectionWithTraits:`.

(2) `-traitCollectionByModifyingTraits:` doesn't have the same issue, and 
adopting it fixes the bug.

With that in mind, we can address the regression by moving from the deprecated 
API to one of the
replacements (`-traitCollectionByModifyingTraits:`).

* Source/WebCore/platform/ios/LocalCurrentTraitCollection.h:
* Source/WebCore/platform/ios/LocalCurrentTraitCollection.mm:

Adopt `-traitCollectionByModifyingTraits:`.

(WebCore::traitCollectionWithAdjustedIdiomForSystemColors):

Rename this from `adjustedTraitCollection` to 
`traitCollectionWithAdjustedIdiomForSystemColors` to
make the intent more obvious. Also, export it for use in the client layer.

(WebCore::LocalCurrentTraitCollection::LocalCurrentTraitCollection):
(WebCore::adjustedTraitCollection): Deleted.
* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm:
(scrollViewBackgroundColor):

Also add a missing idiom adjustment here, when determining the scroll view 
background color. This
ensures that `+systemBackgroundColor` is white to match the iPad idiom here as 
well.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 90ab26: [iOS 18] Undo voice command in Mail compose view d...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 90ab262c20a7ad6601d72961b4fd7a2d745b8f41
  
https://github.com/WebKit/WebKit/commit/90ab262c20a7ad6601d72961b4fd7a2d745b8f41
  Author: Wenson Hsieh 
  Date:   2024-07-08 (Mon, 08 Jul 2024)

  Changed paths:
M Source/WebCore/editing/Editor.cpp
M Source/WebCore/editing/Editor.h
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/UIProcess/ios/WKContentView.mm
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.h
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/WebPage.messages.in
M Tools/TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm

  Log Message:
  ---
  [iOS 18] Undo voice command in Mail compose view does not fully undo dictated 
text
https://bugs.webkit.org/show_bug.cgi?id=276300
rdar://126653644

Reviewed by Abrar Rahman Protyasha.

In iOS 18, dictation recognizes the phrase "Undo" while dictating text, and 
reverts the most
recently inserted dictation phrase. However, in the following scenario:

1. Type "Hello"
2. Begin dictation and say "world"
3. Say "Undo"

...the resulting text will sometimes end up being `"Hello wo"` or `"Hello 
wor"`. To understand why,
we first need to understand how dictation-triggered undo works — when phrases 
are dictated,
`UIDictationController` begins a new undo group by calling `-[NSUndoManager 
beginUndoGrouping]` on
the editing responder (`WKContentView`). As the user continues speaking, the 
"hypothesis text" is
updated, which repeatedly uses `-insertText:` and 
`-adjustSelectionByRange:completionHandler:` to
replace the dictated text. When the user says "Undo", the dictation controller 
then undoes this
entire group.

The issue is that when the dictation controller first calls `-insertText:` 
after beginning the undo
group, this inserted text is added to the last open typing command (after the 
user types `"Hello"`)
instead of being a part of the newly established group that encapsulates all of 
the edit commands
triggered by dictation. As such, when the undo group is undone, we end up with 
`"Hello"` along with
the first piece of text, with which the dictation controller called 
`-insertText:`.

To fix this, we detect when any WebKit client (or the system, in this case 
dictation code) tells the
`WKContentView`'s undo manager to `-beginUndoGrouping`, and close the current 
typing command to
ensure that edit commands triggered in the new undo group aren't merged into 
the previous typing
command before the undo group.

Test: KeyboardInputTests.NewUndoGroupClosesPreviousTypingCommand

* Source/WebCore/editing/Editor.cpp:
(WebCore::Editor::closeTyping):
* Source/WebCore/editing/Editor.h:

Add a helper command to close the typing command if needed.

* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::closeCurrentTypingCommand):
* Source/WebKit/UIProcess/WebPageProxy.h:
* Source/WebKit/UIProcess/ios/WKContentView.mm:
(-[WKNSUndoManager initWithContentView:]):
(-[WKNSUndoManager beginUndoGrouping]):
(-[WKNSUndoManager registerUndoWithTarget:selector:object:]):
(-[WKNSUndoManager registerUndoWithTarget:handler:]):

Add a helper class that overrides `-beginUndoGrouping` and tells the webpage to 
close the current
typing command when a new undo group starts. Note that we avoid this codepath 
when a new command is
being registered, so that we don't prematurely close typing commands while 
typing.

(-[WKContentView undoManagerForWebView]):
(-[WKQuirkyNSUndoManager initWithContentView:]): Deleted.
(-[WKQuirkyNSUndoManager canUndo]): Deleted.
(-[WKQuirkyNSUndoManager canRedo]): Deleted.
(-[WKQuirkyNSUndoManager undo]): Deleted.
(-[WKQuirkyNSUndoManager redo]): Deleted.

Rename this helper class to `WKNSKeyEventSimulatorUndoManager` to better 
reflect its purpose, and
make it subclass `WKNSUndoManager`.

* Source/WebKit/UIProcess/ios/WKContentViewInteraction.h:
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _closeCurrentTypingCommand]):
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::closeCurrentTypingCommand):
* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Source/WebKit/WebProcess/WebPage/WebPage.messages.in:
* Tools/TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm:
(TestWebKitAPI::TEST(KeyboardInputTests, 
NewUndoGroupClosesPreviousTypingCommand)):

Add a new API test to exercise the change by inserting text within an undo 
group, bookended using
`-(begin|end)UndoGrouping`.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications

[webkit-changes] [WebKit/WebKit] 1c989c: [Cocoa] Fall back to playing the largest video in ...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 1c989ca2a15285de8c1720fa2b1d0887e46b153f
  
https://github.com/WebKit/WebKit/commit/1c989ca2a15285de8c1720fa2b1d0887e46b153f
  Author: Wenson Hsieh 
  Date:   2024-07-06 (Sat, 06 Jul 2024)

  Changed paths:
M Source/WebCore/dom/Document.h
M Source/WebCore/html/HTMLMediaElement.h
M Source/WebKit/UIProcess/Cocoa/WebPageProxyCocoa.mm
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/WebPage.messages.in
M Tools/TestWebKitAPI/Tests/WebKitCocoa/VideoControlsManager.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/large-videos-with-audio.html

  Log Message:
  ---
  [Cocoa] Fall back to playing the largest video in the main frame if there's 
no actively controlled element
https://bugs.webkit.org/show_bug.cgi?id=276263
rdar://131185180

Reviewed by Tim Horton.

Augment `playPredominantOrNowPlayingMediaSession` so that it additionally 
detects and plays the
largest video element in the viewport, in the absence of any active Now Playing 
session.

* Source/WebCore/dom/Document.h:
* Source/WebCore/html/HTMLMediaElement.h:
* Source/WebKit/UIProcess/Cocoa/WebPageProxyCocoa.mm:
(WebKit::WebPageProxy::playPredominantOrNowPlayingMediaSession):
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::startPlayingPredominantVideo):

Begin playing the largest (by area) video in the main frame that isn't already 
playing. Use this as
a fallback, only when no other video is being controlled.

* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Source/WebKit/WebProcess/WebPage/WebPage.messages.in:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/VideoControlsManager.mm:
(-[VideoControlsManagerTestWebView waitForVideoToPlay]):
(-[VideoControlsManagerTestWebView waitForVideoToPlay:]):
(-[VideoControlsManagerTestWebView isVideoPaused:]):
(-[VideoControlsManagerTestWebView waitForVideoToPause]):
(TestWebKitAPI::TEST(VideoControlsManager, StartPlayingLargestVideoInViewport)):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/large-videos-with-audio.html:

Add an API test to exercise the change — only the first video (out of the three 
in the page) should
begin playing, since it covers most of the visible viewport.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] f89ad9: Add basic support to play or pause media playback ...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: f89ad9045bd3cacee1f67b30d07a8420fb563be1
  
https://github.com/WebKit/WebKit/commit/f89ad9045bd3cacee1f67b30d07a8420fb563be1
  Author: Wenson Hsieh 
  Date:   2024-07-05 (Fri, 05 Jul 2024)

  Changed paths:
M Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm
M Source/WebKit/UIProcess/API/Cocoa/WKWebViewPrivate.h
M Source/WebKit/UIProcess/Cocoa/WebPageProxyCocoa.mm
M Source/WebKit/UIProcess/WebPageProxy.h
M Tools/TestWebKitAPI/Tests/WebKitCocoa/VideoControlsManager.mm

  Log Message:
  ---
  Add basic support to play or pause media playback for active (Now Playing) 
media
https://bugs.webkit.org/show_bug.cgi?id=276235
rdar://131137466

Reviewed by Eric Carlson.

Add support for `-_playPredominantOrNowPlayingMediaSession:` and 
`-_pauseNowPlayingMediaSession:`.
See comments below.

* Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView _playPredominantOrNowPlayingMediaSession:]):
(-[WKWebView _pauseNowPlayingMediaSession:]):
* Source/WebKit/UIProcess/API/Cocoa/WKWebViewPrivate.h:
* Source/WebKit/UIProcess/Cocoa/WebPageProxyCocoa.mm:
(WebKit::WebPageProxy::playPredominantOrNowPlayingMediaSession):

Add plumbing to get to the playback session model of the active playback 
session. Note that these
currently take completion handlers (despite being synchronous), since the next 
patch will add a
heuristic to asynchronously find and play the most prominent video element in 
the viewport as a
fallback, in the case where there's no current media session.

(WebKit::WebPageProxy::pauseNowPlayingMediaSession):
(WebKit::WebPageProxy::tryToSendCommandToActiveControlledVideo):

Add a helper method to send a `RemoteControlCommandType` to the current 
playback session model.

* Source/WebKit/UIProcess/WebPageProxy.h:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/VideoControlsManager.mm:
(-[VideoControlsManagerTestWebView _playPredominantOrNowPlayingMediaSession]):
(-[VideoControlsManagerTestWebView _pauseNowPlayingMediaSession]):
(-[VideoControlsManagerTestWebView waitForVideoToPlay]):
(-[VideoControlsManagerTestWebView waitForVideoToPause]):
(TestWebKitAPI::TEST(VideoControlsManager, TogglePlaybackForControlledVideo)):

Add an API test that exercises the new `WKWebView` methods.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 308acd: Demote WKWebView SPI that's are used only for test...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 308acd124365dd2b711b82336deb50199cbd8cc0
  
https://github.com/WebKit/WebKit/commit/308acd124365dd2b711b82336deb50199cbd8cc0
  Author: Wenson Hsieh 
  Date:   2024-07-03 (Wed, 03 Jul 2024)

  Changed paths:
M Source/WebKit/UIProcess/API/Cocoa/WKWebViewPrivate.h
M Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm
M Source/WebKit/UIProcess/API/mac/WKWebViewPrivateForTestingMac.h
M Source/WebKit/UIProcess/API/mac/WKWebViewTestingMac.mm

  Log Message:
  ---
  Demote WKWebView SPI that's are used only for testing to internal methods
https://bugs.webkit.org/show_bug.cgi?id=276197

Reviewed by Aditya Keerthi and Abrar Rahman Protyasha.

Move these out of `WKWebViewPrivate.h` and into 
`WKWebViewPrivateForTestingMac.h`, so that they're
not part of the `WKWebView` SPI surface. As their names suggest, these methods 
are only used by API
tests, and are not intended to be used by any WebKit clients.

See: 279557@main for more information.

* Source/WebKit/UIProcess/API/Cocoa/WKWebViewPrivate.h:
* Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm:
(-[WKWebView _createFlagsChangedEventMonitorForTesting]): Deleted.
(-[WKWebView _removeFlagsChangedEventMonitorForTesting]): Deleted.
* Source/WebKit/UIProcess/API/mac/WKWebViewPrivateForTestingMac.h:
* Source/WebKit/UIProcess/API/mac/WKWebViewTestingMac.mm:
(-[WKWebView _createFlagsChangedEventMonitorForTesting]):
(-[WKWebView _removeFlagsChangedEventMonitorForTesting]):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 96ab97: Mitigate sporadic keyboard task queue deadlocks wh...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 96ab975fa598b15fd457a525ac5c735259f08a7e
  
https://github.com/WebKit/WebKit/commit/96ab975fa598b15fd457a525ac5c735259f08a7e
  Author: Wenson Hsieh 
  Date:   2024-07-02 (Tue, 02 Jul 2024)

  Changed paths:
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm

  Log Message:
  ---
  Mitigate sporadic keyboard task queue deadlocks when pressing arrow keys when 
editing
https://bugs.webkit.org/show_bug.cgi?id=276143
rdar://88371405

Reviewed by Abrar Rahman Protyasha.

Mitigate one reproducible source of hangs when pressing arrow keys when editing 
in Mac Catalyst, to
modify the current selection. It's currently possible for UIKit to dispatch key 
events before the
previous key event has been handled on Mac Catalyst (this is in contrast to 
iPadOS or iOS, where key
events are only dispatched once the last event has been handled).

For arrow keys, this can end up triggering methods like 
`-_moveLeft:withHistory:` before the
previous key event has been handled by the web content process. We subsequently 
call back into UIKit
via `-selectionWillChange:` in this method, which then causes UIKit to block 
the main thread while
it waits for the completion handler of the previously-dispatched key event to 
be called. Of course,
this never happens because this completion handler must be called on the main 
thread, and so we
permanently deadlock and eventually crash.

There are a number of architectural issues in this sequence of events that 
cause this bug (most
egregiously, the way UIKit locks the main thread to wait for a completion 
handler call, which can
only be run on the main thread). The divergence in behavior between iPad and 
Catalyst which causes
new key events to be sent without waiting for previous key events to be 
completed is also not ideal.
However, these are both pretty difficult to fix, especially in the short term.

Instead, we can work around this issue for now (and thereby mitigate the 
most-easily-reproducible
scenario where the user just uses arrow keys to modify the selection) by 
immediately rejecting key
events from being handled, if they're sent while a pending arrow key event is 
still in flight. This
fixes the special case of this deadlock, where the `-interpretKeyEvent:` call 
triggers selection
modification while any other key event is still pending.

* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _internalHandleKeyWebEvent:withCompletionHandler:]):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 868193: [iOS] Several editing-related layout tests are fla...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 868193b30419dc7d9692914ca3f8f30a7f66d16e
  
https://github.com/WebKit/WebKit/commit/868193b30419dc7d9692914ca3f8f30a7f66d16e
  Author: Wenson Hsieh 
  Date:   2024-07-01 (Mon, 01 Jul 2024)

  Changed paths:
M LayoutTests/editing/selection/ios/change-selection-by-tapping.html
M LayoutTests/fast/events/ios/key-command-delete-to-end-of-paragraph.html
M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm

  Log Message:
  ---
  [iOS] Several editing-related layout tests are flaky on x86_64 simulator
https://bugs.webkit.org/show_bug.cgi?id=276101
rdar://130607129

Reviewed by Megan Gardner.

For reasons that are still unknown, keyboard autocorrection triggers very 
aggressively on selection
changes when both of the following conditions are true:

1. Running tests in iOS simulator on an Intel (x86_64) host machine.
2. The iOS simulator was newly created (e.g. using `xcrun simctl create`).

This causes the following two tests to fail…

• editing/selection/ios/change-selection-by-tapping.html

This test fails because `can't` is autocorrected to `can’t` (with an 
apostrophe instead of a
straight quote), leading to a text diff.

• editing/selection/ios/show-grammar-replacements-on-tap.html

This test fails because `thing` is "autocorrected" to `thing` immediately 
upon tapping to change
the selection, which triggers an editing command that clears the grammar 
markers underneath the
word.

• fast/events/ios/key-command-delete-to-end-of-paragraph.html

It's actually unclear why this test is failing, due to the fact that I was 
unable to reproduce
this at all in any configuration.

Keep these tests passing by making a couple of minor adjustments:

* LayoutTests/editing/selection/ios/change-selection-by-tapping.html:
* LayoutTests/fast/events/ios/key-command-delete-to-end-of-paragraph.html:

Force `spellcheck="false"` here to prevent correction from triggering when 
simulating selection
changes.

* Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::applyAutocorrectionInternal):

Return early if the original and new strings are identical, to prevent editing 
commands from
triggering (which blow away the grammar markers in 
`show-grammar-replacements-on-tap.html`).

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] efda30: Unreviewed, fix the internal tvOS build after 2804...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: efda30cd17580654bd7ad686702929f3776be441
  
https://github.com/WebKit/WebKit/commit/efda30cd17580654bd7ad686702929f3776be441
  Author: Wenson Hsieh 
  Date:   2024-06-28 (Fri, 28 Jun 2024)

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

  Log Message:
  ---
  Unreviewed, fix the internal tvOS build after 280459@main

`-[UIPasteboard setItemProviders:]` is unavailable on tvOS and watchOS.
Fall back to `-setData:forPasteboardType:` instead.

* Tools/TestWebKitAPI/Tests/WebKitCocoa/AdaptiveImageGlyph.mm:
(TestWebKitAPI::TEST(AdaptiveImageGlyph, InsertWKAttachmentsOnPaste)):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] bd4053: UIIntelligenceSupport context retrieval should avo...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: bd405371c620acba4b52f4cae521c98c02592156
  
https://github.com/WebKit/WebKit/commit/bd405371c620acba4b52f4cae521c98c02592156
  Author: Wenson Hsieh 
  Date:   2024-06-28 (Fri, 28 Jun 2024)

  Changed paths:
A 
LayoutTests/fast/text-extraction/avoid-extracting-password-fields-expected.txt
A LayoutTests/fast/text-extraction/avoid-extracting-password-fields.html
M Source/WebCore/page/text-extraction/TextExtraction.cpp

  Log Message:
  ---
  UIIntelligenceSupport context retrieval should avoid extracting text in 
password fields
https://bugs.webkit.org/show_bug.cgi?id=276022
rdar://129415710

Reviewed by Richard Robinson.

Make a couple of minor adjustments to context retrieval:

1.  Consider text fields as secure for the purposes of context retrieval, if 
they were previously
password fields.

2.  Skip extracting text inside password fields altogether (note that we still 
extract some metadata
about the password field itself, such as the placeholder text).

* 
LayoutTests/fast/text-extraction/avoid-extracting-password-fields-expected.txt: 
Added.
* LayoutTests/fast/text-extraction/avoid-extracting-password-fields.html: Added.

Add a layout test to exercise the change.

* Source/WebCore/page/text-extraction/TextExtraction.cpp:
(WebCore::TextExtraction::shouldTreatAsPasswordField):
(WebCore::TextExtraction::extractItemData):

See comments above.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 2c0db4: Add a way to conditionally disable JIT cage at run...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 2c0db498f18fdde2d8781770ce110a4ccbf2a936
  
https://github.com/WebKit/WebKit/commit/2c0db498f18fdde2d8781770ce110a4ccbf2a936
  Author: Wenson Hsieh 
  Date:   2024-06-28 (Fri, 28 Jun 2024)

  Changed paths:
M 
Source/WebKit/Shared/EntryPointUtilities/Cocoa/XPCService/XPCServiceEntryPoint.h
M Source/WebKit/UIProcess/Cocoa/WebProcessProxyCocoa.mm
M Source/WebKit/UIProcess/Launcher/ProcessLauncher.h
M Source/WebKit/UIProcess/Launcher/cocoa/ProcessLauncherCocoa.mm
M Source/WebKit/UIProcess/WebProcessProxy.cpp
M Source/WebKit/UIProcess/WebProcessProxy.h

  Log Message:
  ---
  Add a way to conditionally disable JIT cage at runtime
https://bugs.webkit.org/show_bug.cgi?id=276001
rdar://130669638

Reviewed by Keith Miller.

Add some plumbing to disable JIT cage at runtime, via a new `disable-jit-cage` 
XPC initialization
key that can be set by the process launcher.

* 
Source/WebKit/Shared/EntryPointUtilities/Cocoa/XPCService/XPCServiceEntryPoint.h:
(WebKit::XPCServiceInitializer):
* Source/WebKit/UIProcess/Cocoa/WebProcessProxyCocoa.mm:
(WebKit::WebProcessProxy::shouldDisableJITCage const):
* Source/WebKit/UIProcess/Launcher/ProcessLauncher.h:
(WebKit::ProcessLauncher::Client::shouldDisableJITCage const):
* Source/WebKit/UIProcess/Launcher/cocoa/ProcessLauncherCocoa.mm:
(WebKit::ProcessLauncher::finishLaunchingProcess):
* Source/WebKit/UIProcess/WebProcessProxy.cpp:
(WebKit::WebProcessProxy::shouldDisableJITCage const):
* Source/WebKit/UIProcess/WebProcessProxy.h:

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 219438: [iOS] Implement a strategy to dynamically adjust t...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 219438e733d3c323fa7ce3eee04d0685c933835f
  
https://github.com/WebKit/WebKit/commit/219438e733d3c323fa7ce3eee04d0685c933835f
  Author: Wenson Hsieh 
  Date:   2024-06-26 (Wed, 26 Jun 2024)

  Changed paths:
M Source/WebCore/page/ChromeClient.h
M Source/WebCore/page/LocalFrameView.cpp
M Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.cpp
M Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.h
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm

  Log Message:
  ---
  [iOS] Implement a strategy to dynamically adjust the fixed-position viewport 
height
https://bugs.webkit.org/show_bug.cgi?id=275910
rdar://130606240

Reviewed by Aditya Keerthi.

Refactor `m_allowsLayoutViewportHeightExpansion` to be an `OptionSet` of reason 
flags instead, which
encompasses the existing `ElementFullScreen` logic as well as a new codepath 
for checking whether
there is a large fixed-position element in the page.

* Source/WebCore/page/ChromeClient.h:
(WebCore::ChromeClient::didAddOrRemoveViewportConstrainedObjects):
* Source/WebCore/page/LocalFrameView.cpp:
(WebCore::LocalFrameView::addViewportConstrainedObject):
(WebCore::LocalFrameView::removeViewportConstrainedObject):

Add a client hook to start a one-shot timer when the set of viewport 
constrained renderers updates.

* Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.cpp:
(WebKit::WebChromeClient::didAddOrRemoveViewportConstrainedObjects):
* Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.h:
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::closeFullScreen):
(WebKit::WebPage::prepareToEnterElementFullScreen):
(WebKit::WebPage::prepareToExitElementFullScreen):
(WebKit::WebPage::didCommitLoad):

Refactor these to use the new reason flags.

(WebKit::WebPage::didAddOrRemoveViewportConstrainedObjects):
(WebKit::WebPage::addReasonsToDisallowLayoutViewportHeightExpansion):
(WebKit::WebPage::removeReasonsToDisallowLayoutViewportHeightExpansion):
(WebKit::WebPage::setAllowsLayoutViewportHeightExpansion): Deleted.
* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::dynamicViewportSizeUpdate):
(WebKit::WebPage::updateLayoutViewportHeightExpansionTimerFired):

Implement the main heuristic here, which checks for a fixed-position container 
that both:
1. Covers the fixed-position viewport rect, and…
2. Can be found by hit-testing the center of the fixed-position viewport rect.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 8fecda: Unreviewed, fix the Xcode build after 280355@main

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 8fecda23a5780619109d133ba0e6d1405f71d2b4
  
https://github.com/WebKit/WebKit/commit/8fecda23a5780619109d133ba0e6d1405f71d2b4
  Author: Wenson Hsieh 
  Date:   2024-06-26 (Wed, 26 Jun 2024)

  Changed paths:
M Source/WebCore/DerivedSources-input.xcfilelist

  Log Message:
  ---
  Unreviewed, fix the Xcode build after 280355@main

Add `page/NavigationActivation.idl` to the DerivedSources list.

* Source/WebCore/DerivedSources-input.xcfilelist:

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 538702: [Webpage Translation] Text fields are incorrectly ...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 5387029f37335aefb7c6a2fa4fec42b58a0f1aef
  
https://github.com/WebKit/WebKit/commit/5387029f37335aefb7c6a2fa4fec42b58a0f1aef
  Author: Wenson Hsieh 
  Date:   2024-06-25 (Tue, 25 Jun 2024)

  Changed paths:
M Source/WebCore/editing/TextManipulationController.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/TextManipulation.mm

  Log Message:
  ---
  [Webpage Translation] Text fields are incorrectly translated after invoking 
AutoFill
https://bugs.webkit.org/show_bug.cgi?id=275878
rdar://130413693

Reviewed by Abrar Rahman Protyasha.

Make a couple of minor adjustments to avoid extracting text within text fields, 
in the case where
the user has inserted text in those fields via AutoFill. See below for more 
details.

Test: TextManipulation.CompleteTextManipulationDoesNotFillAutoFilledField

* Source/WebCore/editing/TextManipulationController.cpp:
(WebCore::shouldExtractValueForTextManipulation):

Add a FIXME regarding how we directly check against for `type='text'` instead 
of using the effective
`type()`.

(WebCore::shouldIgnoreNodeInTextField):

Add a helper function to check whether a node is inside of an AutoFilled or 
user-edited text field,
and deploy it in several places below.

(WebCore::TextManipulationController::scheduleObservationUpdate):

Check whether the node should be ignored, before observing it.

(WebCore::TextManipulationController::replace):

Run another check right before replacement, to ensure that we don't replace 
text in the node if:

1. An observation update runs.
2. The node is AutoFilled.
3. Replacement results arrive.

We bail early with `ContentChanged`, since the node has become AutoFilled in 
between the observation
and replacement.

* Tools/TestWebKitAPI/Tests/WebKitCocoa/TextManipulation.mm:
(TestWebKitAPI::TEST(TextManipulation, 
CompleteTextManipulationDoesNotFillAutoFilledField)):

Add an API test to exercise the change.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 56c04a: Refactor some logic to adjust the viewport in prep...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 56c04aa4f72aacc51e189a3b4d611ceab6922073
  
https://github.com/WebKit/WebKit/commit/56c04aa4f72aacc51e189a3b4d611ceab6922073
  Author: Wenson Hsieh 
  Date:   2024-06-25 (Tue, 25 Jun 2024)

  Changed paths:
M Source/WebKit/UIProcess/PageClient.h
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/UIProcess/WebPageProxy.messages.in
M Source/WebKit/UIProcess/WebPageProxyInternals.h
M Source/WebKit/UIProcess/ios/PageClientImplIOS.h
M Source/WebKit/UIProcess/ios/PageClientImplIOS.mm
M Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm
M Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm
M Source/WebKit/WebProcess/FullScreen/WebFullScreenManager.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm

  Log Message:
  ---
  Refactor some logic to adjust the viewport in preparation for element 
fullscreen
https://bugs.webkit.org/show_bug.cgi?id=275830
rdar://130216576

Reviewed by Aditya Keerthi.

Refactor some logic to adjust the viewport in preparation for element 
fullscreen. See below for
more details.

* Source/WebKit/UIProcess/PageClient.h:
(WebKit::PageClient::scheduleVisibleContentRectUpdate):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::resetState):
(WebKit::WebPageProxy::setAllowsLayoutViewportHeightExpansion):

Add support for a new UI-side flag (updated via IPC from the web process) to 
determine whether or
not we should allow layout viewport height expansion. Currently, this is only 
influenced by
fullscreen presentation state, but this will need to change in a subsequent 
patch to be tracked
using an option set of reasons.

* Source/WebKit/UIProcess/WebPageProxy.h:
* Source/WebKit/UIProcess/WebPageProxy.messages.in:
* Source/WebKit/UIProcess/WebPageProxyInternals.h:
* Source/WebKit/UIProcess/ios/PageClientImplIOS.h:
* Source/WebKit/UIProcess/ios/PageClientImplIOS.mm:
(WebKit::PageClientImpl::scheduleVisibleContentRectUpdate):

Add a page client hook to schedule a visible content rect update.

* Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm:
(WebKit::WebPageProxy::computeLayoutViewportRect const):
* Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm:
(-[WKFullScreenWindowController enterFullScreen:]):
* Source/WebKit/WebProcess/FullScreen/WebFullScreenManager.cpp:
(WebKit::WebFullScreenManager::enterFullScreenForElement):
(WebKit::WebFullScreenManager::exitFullScreenForElement):

Add a couple of new hooks to call into `WebPage` when we're about to enter or 
exit fullscreen — note
that these calls are here instead of inside `willEnterFullScreen`, since the 
latter is too late.

(WebKit::WebFullScreenManager::close):
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::closeFullScreen):
(WebKit::WebPage::prepareToEnterElementFullScreen):
(WebKit::WebPage::prepareToExitElementFullScreen):
(WebKit::WebPage::didCommitLoad):
(WebKit::WebPage::setAllowsLayoutViewportHeightExpansion):

Update the UI process whenever this state changes.

* Source/WebKit/WebProcess/WebPage/WebPage.h:

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] aa6c1d: REGRESSION (278484@main): Chinese Input Method (pi...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: aa6c1d4264f0176f1a925227bd3e80266ec7e2f6
  
https://github.com/WebKit/WebKit/commit/aa6c1d4264f0176f1a925227bd3e80266ec7e2f6
  Author: Wenson Hsieh 
  Date:   2024-06-23 (Sun, 23 Jun 2024)

  Changed paths:
A 
LayoutTests/editing/selection/ios/navigating-in-subframe-does-not-dismiss-edit-menu-expected.txt
A 
LayoutTests/editing/selection/ios/navigating-in-subframe-does-not-dismiss-edit-menu.html
M LayoutTests/platform/ios/TestExpectations
M Source/WebKit/Scripts/webkit/messages.py
M Source/WebKit/UIProcess/API/gtk/PageClientImpl.h
M Source/WebKit/UIProcess/API/wpe/PageClientImpl.h
M Source/WebKit/UIProcess/PageClient.h
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/UIProcess/WebPageProxy.messages.in
M Source/WebKit/UIProcess/ios/PageClientImplIOS.h
M Source/WebKit/UIProcess/ios/PageClientImplIOS.mm
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.h
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Source/WebKit/UIProcess/mac/PageClientImplMac.h
M Source/WebKit/UIProcess/playstation/PageClientImpl.h
M Source/WebKit/UIProcess/win/PageClientImpl.h
M Source/WebKit/WebProcess/WebCoreSupport/WebLocalFrameLoaderClient.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h

  Log Message:
  ---
  REGRESSION (278484@main): Chinese Input Method (pinyin) is broken on 
ChatGPT/Google translate
https://bugs.webkit.org/show_bug.cgi?id=275754
rdar://130020224

Reviewed by Abrar Rahman Protyasha.

After the changes in 278484@main, navigations occurring in subframes that are 
not empty now cause us
to clear UI-side editor state, through 
`WebPage::clearEditorStateAfterPageTransition()`. The
intention in 278484@main was to only trigger this codepath when completing a 
page transition due to
mainframe navigation, but because the `InitializingIframe` flag is set when 
navigating away from
subframes that have already loaded content, this ended up sometimes clearing 
the UI-side selection
when loading subframes.

To fix this, this patch begins by reverting the "clear UI-side editor state 
during page transition"
approach that I previously attempted in 278484@main and 278902@main. Of course, 
this causes the API
test `ScrollViewScrollabilityTests.ScrollableWithOverflowHiddenWhenZoomed` to 
start failing again.

After investigating this test failure further, I discovered that this happens 
because having an up-
to-date `EditorState` with post-layout data means that logic which attempts to 
adjust the selection
views after scale changes in `-[WKContentView 
observeValueForKeyPath:ofObject:change:context:]` will
now call into `-_updateChangedSelection:` without returning immediately in that 
method. As a
consequence, we end up calling into UIKit code under `-selectionChanged`, which 
(internally)
instantiates the shared `UIKeyboardImpl` instance in the process of posting a 
notification for
`UITextInputResponderCapabilitiesChangedNotification`.

Instantiating a `UIKeyboardImpl` in the middle of a call to `-[WKScrollView 
setZoomScale:animated:]`
subsequently causes UIKit to install some native selection views under the 
scroll view, which (for
reasons that are still unclear) causes the scroll view to revert to a zoom 
scale of 1.

To keep this test passing after reverting 278484@main and 278902@main, we add a 
slight optimization
to `-[WKContentView observeValueForKeyPath:ofObject:change:context:]`, such 
that we avoid trying to
update UIKit's selection views (and therefore prevent `UIKeyboardImpl` from 
being instantiated) in
the case where the following conditions are both true:

1. There is no selection (i.e. the current `EditorState` has a selection type 
that is `None`).
2. No selection was previously shown (i.e. `_lastSelectionDrawingInfo`'s type 
is also `None`).

There should be no need to update platform selection state in this case, since 
nothing is visually
changing.

For easier bookkeeping — the full tree of fixes (and followup fixes) is 
currently:

```
rdar://102563363 (fixed in 276962@main)
↳ …caused: rdar://126280854 (fixed in 277910@main)
↳ …caused: rdar://127547621 (fixed in 278484@main)
↳ …caused: rdar://130020224 (fixed by this PR)
↳ …caused: rdar://128086114 (fixed in 278902@main)
↳ …caused: rdar://128497371 (fixed by this PR)
```

* 
LayoutTests/editing/selection/ios/navigating-in-subframe-does-not-dismiss-edit-menu-expected.txt:
 Added.
* 
LayoutTests/editing/selection/ios/navigating-in-subframe-does-not-dismiss-edit-menu.html:
 Added.

Add a new layout test to verify that UI-side editor state isn't cleared when 
navigating in subframes
that don't contain the selection (which is the root cause of the bug on 
ChatGPT/Google Translate).

* LayoutTests/platform/ios/TestExpectations:

R

[webkit-changes] [WebKit/WebKit] 50abb5: Clicking Edit > Paste in the in-page menu on Googl...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 50abb533176213b4ecf8d0e9f749d1ee15cc43ca
  
https://github.com/WebKit/WebKit/commit/50abb533176213b4ecf8d0e9f749d1ee15cc43ca
  Author: Wenson Hsieh 
  Date:   2024-06-18 (Tue, 18 Jun 2024)

  Changed paths:
A 
LayoutTests/editing/pasteboard/dom-paste/dom-paste-in-child-frame-does-not-crash-expected.txt
A 
LayoutTests/editing/pasteboard/dom-paste/dom-paste-in-child-frame-does-not-crash.html
M Source/WebCore/dom/DOMPasteAccess.h
M Source/WebKit/UIProcess/API/gtk/PageClientImpl.cpp
M Source/WebKit/UIProcess/API/gtk/PageClientImpl.h
M Source/WebKit/UIProcess/API/wpe/PageClientImpl.cpp
M Source/WebKit/UIProcess/API/wpe/PageClientImpl.h
M Source/WebKit/UIProcess/PageClient.h
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/ios/PageClientImplIOS.h
M Source/WebKit/UIProcess/ios/PageClientImplIOS.mm
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.h
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Source/WebKit/UIProcess/mac/PageClientImplMac.h
M Source/WebKit/UIProcess/mac/PageClientImplMac.mm
M Source/WebKit/UIProcess/mac/WebViewImpl.h
M Source/WebKit/UIProcess/mac/WebViewImpl.mm
M Source/WebKit/UIProcess/playstation/PageClientImpl.cpp
M Source/WebKit/UIProcess/playstation/PageClientImpl.h
M Source/WebKit/UIProcess/win/PageClientImpl.cpp
M Source/WebKit/UIProcess/win/PageClientImpl.h

  Log Message:
  ---
  Clicking Edit > Paste in the in-page menu on Google Docs results in a failed 
MESSAGE_CHECK
https://bugs.webkit.org/show_bug.cgi?id=275608
rdar://130078654

Reviewed by Abrar Rahman Protyasha.

The security hardening in https://commits.webkit.org/279133@main introduced a 
`MESSAGE_CHECK` to
verify that the ID of the frame requesting access to the pasteboard matches the 
security origin used
as the document's `originIdentifierForPasteboard()` (which is either a security 
origin string, or a
randomly-generated UUID in the case of a null origin).

```
auto originFromFrame = SecurityOrigin::create(frame->url());
MESSAGE_CHECK_COMPLETION(m_legacyMainFrameProcess, 
origin->isSameOriginDomain(originFromFrame),
completionHandler(DOMPasteAccessResponse::DeniedForGesture));
```

Importantly, note that this uses the given frame ID to find the corresponding 
`WebFrameProxy`, get
the frame's URL in the UI process, and check whether the origins match using 
that URL.

This check (unintentionally) fails in the case where a `src`-less frame, whose 
security origin
matches that of the `Document` that created it, triggers programmatic paste and 
sends a frame ID
corresponding to the subframe (which doesn't have a source). We'll end up 
getting an opaque security
origin for the frame above (based on its URL), which causes the 
`isSameOriginDomain` check to return
`false` even though the subframe's document actually has the same security 
origin. Subsequently, the
failed message check results in the web process crashing.

To address this crash and prevent simimlar bugs from causing the web process to 
terminate without
regressing the security guarantees of the original fix, we take the following 
approach instead:

(1) Relax the check so that we allow the `originIdentifier` as long as the 
frame, or one of its
parent frames have the same origin.

(2) Instead of `MESSAGE_CHECK`-ing and terminating the web process, simply fall 
back on showing the
paste prompt instead, regardless of whether the given `originIdentifier` 
matches the identifier
on the pasteboard. This turns a would-be crash into a much-less-egregious 
bug where the paste
prompt might show up unnecessarily.

* 
LayoutTests/editing/pasteboard/dom-paste/dom-paste-in-child-frame-does-not-crash-expected.txt:
 Added.
* 
LayoutTests/editing/pasteboard/dom-paste/dom-paste-in-child-frame-does-not-crash.html:
 Added.

Add a layout test to exercise the crash.

* Source/WebCore/dom/DOMPasteAccess.h:

Add a new `enum class` flag to indicate whether or not `requestDOMPasteAccess` 
should be allowed to
proceed without explicit user interaction, in the case where the origins match 
(e.g. copying and
pasting across tabs of the same origin).

* Source/WebKit/UIProcess/API/gtk/PageClientImpl.cpp:
(WebKit::PageClientImpl::requestDOMPasteAccess):
* Source/WebKit/UIProcess/API/gtk/PageClientImpl.h:
* Source/WebKit/UIProcess/API/wpe/PageClientImpl.cpp:

Plumb the new `DOMPasteRequiresInteraction` flag through all codepaths that 
trigger DOM a paste
access request.

(WebKit::PageClientImpl::requestDOMPasteAccess):
* Source/WebKit/UIProcess/API/wpe/PageClientImpl.h:
* Source/WebKit/UIProcess/PageClient.h:
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::requestDOMPasteAccess):

Implement the main fix here; see comments above for more details.

* Source/WebKit/UIProcess/ios/PageClientImplIOS.h:
* Source/WebKit/UIProcess/ios/PageClientI

[webkit-changes] [WebKit/WebKit] 3fecce: [results.webkit.org] ⌘F should not override system...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 3fecce8a9b38374458fabf95582d6be8074fe357
  
https://github.com/WebKit/WebKit/commit/3fecce8a9b38374458fabf95582d6be8074fe357
  Author: Wenson Hsieh 
  Date:   2024-06-17 (Mon, 17 Jun 2024)

  Changed paths:
M Tools/Scripts/libraries/resultsdbpy/resultsdbpy/view/static/js/drawer.js

  Log Message:
  ---
  [results.webkit.org] ⌘F should not override system find-in-page if the search 
panel is collapsed
https://bugs.webkit.org/show_bug.cgi?id=275531

Reviewed by BJ Burg.

Avoid preventing default and attempting to focus the search field when the user 
presses ⌘F, if the
search field is disabled (and therefore cannot be edited in the first place). 
The existing logic
makes it difficult to invoke the browser's built-in find-in-page functionality 
at all in
results.webkit.org, which can be useful in some cases (e.g. when searching for 
specific trains, OS
build versions, etc.).

* Tools/Scripts/libraries/resultsdbpy/resultsdbpy/view/static/js/drawer.js:

Also drive-by-fix a typo in a nearby local variable.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 86e40f: Unreviewed, fix the non-internal visionOS build af...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 86e40f940d83e3ca53b454af4769d3ccac28e5b2
  
https://github.com/WebKit/WebKit/commit/86e40f940d83e3ca53b454af4769d3ccac28e5b2
  Author: Wenson Hsieh 
  Date:   2024-06-15 (Sat, 15 Jun 2024)

  Changed paths:
M Source/WTF/wtf/PlatformHave.h

  Log Message:
  ---
  Unreviewed, fix the non-internal visionOS build after 280051@main

* Source/WTF/wtf/PlatformHave.h:

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 66195e: [Cocoa] Upstream support for system context retrie...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 66195e98c7605c01ceea07a626f4122f33f14dfa
  
https://github.com/WebKit/WebKit/commit/66195e98c7605c01ceea07a626f4122f33f14dfa
  Author: Wenson Hsieh 
  Date:   2024-06-15 (Sat, 15 Jun 2024)

  Changed paths:
M LayoutTests/fast/text-extraction/basic-text-extraction.html
M LayoutTests/fast/text-extraction/text-extraction-when-scrolled.html
M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
M Source/WTF/wtf/PlatformHave.h
M Source/WebKit/Configurations/WebKitSwift.xcconfig
M Source/WebKit/DerivedSources-input.xcfilelist
M Source/WebKit/DerivedSources.make
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/WebKit.xcodeproj/project.pbxproj
A Source/WebKit/WebKitSwift/TextExtraction/WKWebView+TextExtraction.swift
M Tools/WebKitTestRunner/TestOptions.cpp
M Tools/WebKitTestRunner/TestOptions.h
M Tools/WebKitTestRunner/cocoa/TestControllerCocoa.mm

  Log Message:
  ---
  [Cocoa] Upstream support for system context retrieval through 
UIIntelligenceSupport
https://bugs.webkit.org/show_bug.cgi?id=275510

Reviewed by Aditya Keerthi and Megan Gardner.

Upstream support for system context retrieval through the UIIntelligenceSupport 
framework on iOS 18
and macOS Sequoia. See below for more comments.

* LayoutTests/fast/text-extraction/basic-text-extraction.html:
* LayoutTests/fast/text-extraction/text-extraction-when-scrolled.html:

Add an explicit `textExtractionEnabled=true` to enable use of the text 
extraction SPI.

* Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml:
* Source/WTF/wtf/PlatformHave.h:

Add a new compile-time flag: `HAVE(UIINTELLIGENCESUPPORT_FRAMEWORK)`. Use this 
flag to enable the
runtime flag `TextExtractionEnabled` by default on supported platforms.

* Source/WebKit/Configurations/WebKitSwift.xcconfig:

Remove `WKWebView+TextExtraction.swift` as an excluded source, now that the 
file is no longer in
WebKitAdditions.

* Source/WebKit/DerivedSources-input.xcfilelist:
* Source/WebKit/DerivedSources.make:
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::didCommitLoadForFrame):

Remove an unnecessary compile-time flag, `ENABLE(TEXT_EXTRACTION)`. This was 
only used to avoid
eagerly loading `libWebKitSwift` on platforms where support for 
UIIntelligenceSupport is missing;
it's a bit cleaner to just turn the runtime feature off by default when the 
above compile-time flag,
`HAVE(UIINTELLIGENCESUPPORT_FRAMEWORK)`, is off.

* Source/WebKit/WebKit.xcodeproj/project.pbxproj:
* Source/WebKit/WebKitSwift/TextExtraction/WKWebView+TextExtraction.swift: 
Added.

Move this source file to `WebKitSwift/`, from WebKitAdditions.

(createEditable(for:)):
(createElementContent(for:)):
(createIntelligenceElement(_:)):
(WKWebView._intelligenceBaseClass):
(WKWebView._intelligenceCollectContent(in:collector:)):
(WKWebView._intelligenceCollectRemoteContent(in:remoteContextWrapper:)):
(WKWebView._requestTextExtraction(in:completionHandler:)):

Upstream support code for converting `WKTextExtractionItem` → 
`IntelligenceElement`.

* Tools/WebKitTestRunner/TestOptions.cpp:
(WTR::TestOptions::defaults):
(WTR::TestOptions::keyTypeMapping):
* Tools/WebKitTestRunner/TestOptions.h:
(WTR::TestOptions::textExtractionEnabled const):
* Tools/WebKitTestRunner/cocoa/TestControllerCocoa.mm:
(WTR::TestController::cocoaResetStateToConsistentValues):

Reintroduce a test option to enable TextExtraction, since enablement is now 
properly gated on
`HAVE(UIINTELLIGENCESUPPORT_FRAMEWORK)`. Prior to this upstreaming, it was 
unconditionally (and
unnecessarily) enabled everywhere.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 8fef28: [iOS] Several editing pasteboard tests fail when b...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 8fef2855838a2286018250ed68dad20cb1cee1f6
  
https://github.com/WebKit/WebKit/commit/8fef2855838a2286018250ed68dad20cb1cee1f6
  Author: Wenson Hsieh 
  Date:   2024-06-14 (Fri, 14 Jun 2024)

  Changed paths:
M Source/WebCore/platform/ios/PasteboardIOS.mm

  Log Message:
  ---
  [iOS] Several editing pasteboard tests fail when built WebKit is binary 
compatible with system WebKit
https://bugs.webkit.org/show_bug.cgi?id=275494
rdar://129306120

Reviewed by Abrar Rahman Protyasha and Tim Horton.

When running tests on `safari-7618-branch` on iOS, the following 4 layout tests 
fail only in the
case where the built WebKit stack is binary compatible with the system WebKit 
version:

• editing/pasteboard/4930986-1-paste-as-quotation.html
• editing/pasteboard/4930986-2-paste-as-quotation.html
• editing/pasteboard/4930986-3-paste-as-quotation.html
• editing/pasteboard/paste-content-with-overflow-auto-parent-across-origin.html

This happens because since iOS 17.4, `nsattributedstringagent` is launched in 
response to a request
for `com.apple.flat-rtfd` data on the pasteboard in the following case:

1. `com.apple.flat-rtfd` data was not written explicitly to the pasteboard.
2. One or both of `public.html` or `com.apple.webarchive` was explicitly 
written to the pasteboard.

This attributed string agent links against the built WebKit stack via 
`__XPC_DYLD_FRAMEWORK_PATH`,
but because the `__XPC_` prefix only propagates the DYLD framework path 
override to XPC services
launched by `WebKitTestRunnerApp`, the web content process that's launched by 
this attributed string
agent ends up linking against the system WebKit stack instead of the built 
WebKit stack.

Normally, this results in `nsattributedstringagent`'s web content process 
terminating shortly after
launch due to binary incompatibilities with various IPC message identifiers, 
which causes code in
`PasteboardIOS.mm` that requests flat RTFD data from the pasteboard to fail 
(and return 0 bytes) in
the case where there's only `text/html` data on the pasteboard (and the flat 
RTFD data is therefore
synthesized by system frameworks). This, in turn, effectively disables the new 
UIKit pasteboard
attributed string coercion codepaths introduced in iOS 17.4, causes us to just 
read the raw
`text/html`, and thus allows the tests to pass because the round trip from 
markup to attributed
string and back would otherwise drops the `apple-style-span` class attribute.

However, if (by some miracle) the built WebKit stack is binary compatible 
enough with the system
version of WebKit that attributed string conversion succeeds, we end up reading 
an attributed string
from the system pasteboard in this case, which leads to different results due 
to the round tripping.

While it's not great that round tripping loses `apple-style-span`, it's also 
pretty bad (for
performance as well as testing sanity) that we even try to use 
`nsattributedstringagent` in this
scenario, since the HTML or web archive data already has full fidelity. To fix 
this, we instead
detect that the pasteboard contains a payload that we (WebKit) wrote ourselves 
when copying web
content, and use that as a hint to prefer HTML and web archive data over either 
RTF or flat RTFD.
Since any RTF/flat RTFD content we write to the pasteboard is derived from web 
content anyways, the
HTML and web archive representation will always be higher fidelity than their 
TextKit counterparts.

* Source/WebCore/platform/ios/PasteboardIOS.mm:
(WebCore::isTypeAllowedByReadingPolicy):

Also adopt `UniformTypeIdentifiers.framework` in a few more places while I'm 
refactoring this code,
to fix some would-be deprecation warnings due to using `kUTType*`.

(WebCore::supportedWebContentPasteboardTypesWhenCustomDataIsPresent):
(WebCore::Pasteboard::read):
(WebCore::Pasteboard::supportedWebContentPasteboardTypes):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] c3b614: Unreviewed, bump WebCore.xcodeproj `objectVersion`...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: c3b6149c2cdfad5aea3f46592a87e74067320aba
  
https://github.com/WebKit/WebKit/commit/c3b6149c2cdfad5aea3f46592a87e74067320aba
  Author: Wenson Hsieh 
  Date:   2024-06-14 (Fri, 14 Jun 2024)

  Changed paths:
M Source/WebCore/WebCore.xcodeproj/project.pbxproj

  Log Message:
  ---
  Unreviewed, bump WebCore.xcodeproj `objectVersion` back up to 55

This was unintentionally reverted as a part of 
https://commits.webkit.org/279983@main.

* Source/WebCore/WebCore.xcodeproj/project.pbxproj:

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] cf817c: [macOS] Crash when inserting writing suggestions i...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: cf817ce46fd4faa5382882e69f75bcd49b8a1956
  
https://github.com/WebKit/WebKit/commit/cf817ce46fd4faa5382882e69f75bcd49b8a1956
  Author: Wenson Hsieh 
  Date:   2024-06-13 (Thu, 13 Jun 2024)

  Changed paths:
A 
LayoutTests/editing/input/mac/inline-prediction-in-grid-container-expected.txt
A LayoutTests/editing/input/mac/inline-prediction-in-grid-container.html
M Source/WebCore/rendering/updating/RenderTreeUpdaterGeneratedContent.cpp

  Log Message:
  ---
  [macOS] Crash when inserting writing suggestions in an editable `display: 
grid` container
https://bugs.webkit.org/show_bug.cgi?id=275426
rdar://129366300

Reviewed by Richard Robinson and Abrar Protyasha.

Make writing suggestions robust in the case where the process of attaching the 
suggestions renderer
to its parent in the render tree causes the parent to become destroyed. This 
can happen if, for
instance, the renderer is being inserted underneath an anonymous renderer 
inside of a grid
container like so:

```



```

...with render tree:

```
RenderBlock {HTML} at (0,0)
  RenderBody {BODY} at (8,8)
RenderGrid {DIV} at (0,0)
  RenderBlock (anonymous) at (0,0)
RenderText {#text} at (0,0) // <- text before suggestion
```

As a result of inserting the renderer, `removeLeftoverAnonymousBlock()` will 
replace the parent
renderer, which currently leads to a crash since we hold a `CheckedPtr` to it 
on the stack. Instead,
gracefully handle this (and similar) scenarios by deploying `WeakPtr`, and 
clean up the writing
suggestions renderer and return early in the case where the parent is destroyed 
after insertion.

Test: editing/input/mac/inline-prediction-in-grid-container.html

* 
LayoutTests/editing/input/mac/inline-prediction-in-grid-container-expected.txt: 
Added.
* LayoutTests/editing/input/mac/inline-prediction-in-grid-container.html: Added.
* Source/WebCore/rendering/updating/RenderTreeUpdaterGeneratedContent.cpp:
(WebCore::RenderTreeUpdater::GeneratedContent::updateWritingSuggestionsRenderer):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 3d0b28: REGRESSION (275396@main): [iOS] Safari sometimes c...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 3d0b28687be1fcb0a39e95db941f1742d121cd9a
  
https://github.com/WebKit/WebKit/commit/3d0b28687be1fcb0a39e95db941f1742d121cd9a
  Author: Wenson Hsieh 
  Date:   2024-06-11 (Tue, 11 Jun 2024)

  Changed paths:
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Tools/TestWebKitAPI/Tests/ios/AutocorrectionTestsIOS.mm

  Log Message:
  ---
  REGRESSION (275396@main): [iOS] Safari sometimes crashes under 
-[WKContentView textStylingAtPosition:inDirection:]
https://bugs.webkit.org/show_bug.cgi?id=275339
rdar://127571335

Reviewed by Aditya Keerthi.

After the change in 275396@main, it's possible for 
`-textStylingAtPosition:inDirection:` to crash
when attempting to insert a `nil` value into the resulting dictionary. This is 
because
`+[UIFont fontWithDescriptor:size:]` can apparently return a `nil` `UIFont`, 
but our code just
assumes that it always returns a non-null value.

Harden against this possibility by null-checking the font before trying to add 
it to the result, and
also augment a test to exercise this mitigation by forcing 
`+fontWithDescriptor:size:` to return
`nil` in the middle of the test, and verify that we handle that case gracefully 
by returning the
original font (without the new symbolic traits).

* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView textStylingAtPosition:inDirection:]):
* Tools/TestWebKitAPI/Tests/ios/AutocorrectionTestsIOS.mm:
(returnNil):
(TEST(AutocorrectionTests, FontAtCaretWhenUsingUICTFontTextStyle)):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 703a5b: REGRESSION (iOS 17.2): Infinite recursion in -[WKC...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 703a5b6bfcf1ff18afc3c0b46042d9ccee39371f
  
https://github.com/WebKit/WebKit/commit/703a5b6bfcf1ff18afc3c0b46042d9ccee39371f
  Author: Wenson Hsieh 
  Date:   2024-06-07 (Fri, 07 Jun 2024)

  Changed paths:
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.h
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm

  Log Message:
  ---
  REGRESSION (iOS 17.2): Infinite recursion in -[WKContentView(WKInteraction) 
inputViewForWebView]
https://bugs.webkit.org/show_bug.cgi?id=275171
rdar://127722998

Reviewed by Richard Robinson.

The changes in rdar://116751305&104994662 seem to have made it possible for 
`-inputViewForWebView`
to trigger infinite recursion, due to a new `-[UITextInputAssistantItem 
leadingBarButtonGroups]`
KVO listener in UIKit. Underneath this new KVO logic, UIKit calls into some 
internal methods which
ultimately call back into `-[WKContentView inputViewForWebView]`. In order of 
stack depth (growing
downwards), the reentrant calls to update the input accessory view look like 
this:

```
-[WKContentView(WKInteraction) _updateAccessory]
-[WKContentView(WKInteraction) formAccessoryView]
-[WKFormAccessoryView _initForUniversalControlBar:] // <--- Setting up 
WKFormAccessoryView

  … (KVO triggered by setting leading/trailing bar button groups)

-[UISystemInputAssistantViewController 
observeValueForKeyPath:ofObject:change:context:]
-[TUISystemInputAssistantView setInputAssistantItem:force:]

  … (UIKit internals)

-[UIKeyboardSceneDelegate expectedInputViewSetIsCustom]
-[WKContentView(WKInteraction) inputViewForWebView]
-[WKContentView(WKInteraction) _updateAccessory]
-[WKContentView(WKInteraction) formAccessoryView]
-[WKFormAccessoryView _initForUniversalControlBar:] // <--- Setting up 
WKFormAccessoryView (reentrancy!)
```

While I wasn't able to reproduce the crash at all, we can at least harden 
against this scenario by
making `-_updateAccessory` robust against reentrancy. Achieve this by adding a 
new ivar that's only
set during the scope of `-_updateAccessory`, and return early if it's set.

* Source/WebKit/UIProcess/ios/WKContentViewInteraction.h:
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView setUpInteraction]):
(-[WKContentView _updateAccessory]):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] d4fa89: visualViewport.scale() should be 1 at the default ...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: d4fa89ab44bce81fa25269d46b955777dd1804fb
  
https://github.com/WebKit/WebKit/commit/d4fa89ab44bce81fa25269d46b955777dd1804fb
  Author: Wenson Hsieh 
  Date:   2024-06-07 (Fri, 07 Jun 2024)

  Changed paths:
M Source/WebCore/page/ChromeClient.h
M Source/WebCore/page/VisualViewport.cpp
M Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.cpp
M Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.h
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm

  Log Message:
  ---
  visualViewport.scale() should be 1 at the default scale when using automatic 
view scale adjustment
https://bugs.webkit.org/show_bug.cgi?id=275260

Reviewed by Aditya Keerthi.

Report a `visualViewport.scale()` of 1 at the default scale (i.e. without any 
explicit user scaling)
when automatic view scale adjustments are enabled.

For context, the idea of applying a layout size scale factor is that WebKit can 
take the normal
minimum layout size it would've used, scale those dimensions by an arbitrary 
amount, perform layout
using those scaled dimensions, and finally scale down (or up) to fit the real 
view dimensions when
computing initial scale.

Without this change, `scale()` reports the actual page scale factor, which may 
not be equal to 1 (by
default) when `automaticallyAdjustsViewScaleUsingMinimumEffectiveDeviceWidth` 
is enabled. This
causes the entire page to be clipped on certain websites, where the result of
`(visualViewport.width * visualViewport.scale)` is used to compute an 
"effective layout width which
is used to size the rest of the webpage.

Mitigate this by pretending to be `scale=1` in this case, such that the result 
of `width * scale`
can no longer be used to infer the real size of the web view, and we can 
properly scale up to fit
the webpage to the view without clipping the page.

* Source/WebCore/page/ChromeClient.h:
(WebCore::ChromeClient::baseViewportLayoutSizeScaleFactor const):

Add a chrome client hook to ask for the current base layout size scale factor, 
so that we can adjust
the scale factor reported by `visualViewport.scale()` by this amount. See above.

* Source/WebCore/page/VisualViewport.cpp:
(WebCore::VisualViewport::update):
* Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.cpp:
(WebKit::WebChromeClient::baseViewportLayoutSizeScaleFactor const):
* Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.h:
* Source/WebKit/WebProcess/WebPage/WebPage.h:
(WebKit::WebPage::baseViewportLayoutSizeScaleFactor const):
* Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::setViewportConfigurationViewLayoutSize):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 036077: Avoid layout viewport height expansion when the do...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 036077f49ec800df04fb3453433e0dc4c162e709
  
https://github.com/WebKit/WebKit/commit/036077f49ec800df04fb3453433e0dc4c162e709
  Author: Wenson Hsieh 
  Date:   2024-06-07 (Fri, 07 Jun 2024)

  Changed paths:
M Source/WebCore/page/LocalFrameView.cpp

  Log Message:
  ---
  Avoid layout viewport height expansion when the document is shorter than the 
expanded viewport
https://bugs.webkit.org/show_bug.cgi?id=275239

Reviewed by Aditya Keerthi.

Limit the layout viewport height expansion heuristic to only cases where the 
scrollable height of
the document is larger than the expanded viewport itself.

* Source/WebCore/page/LocalFrameView.cpp:
(WebCore::LocalFrameView::expandedLayoutViewportSize):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] d63730: Add a runtime setting to disable text autosizing a...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: d63730149a7e76f2964e5a5b466faf2633ec5d8e
  
https://github.com/WebKit/WebKit/commit/d63730149a7e76f2964e5a5b466faf2633ec5d8e
  Author: Wenson Hsieh 
  Date:   2024-06-06 (Thu, 06 Jun 2024)

  Changed paths:
M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm

  Log Message:
  ---
  Add a runtime setting to disable text autosizing at initial scale > 1
https://bugs.webkit.org/show_bug.cgi?id=275187
rdar://129310585

Reviewed by Aditya Keerthi.

Conditionally enable text autosizing, based on whether the initial scale.

* Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml:
* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::updateTextAutosizingEnablementFromInitialScale):

Disable text autosizing if and only if the initial scale is greater than 1 (and 
text is going to be
legible anyways).

(WebKit::WebPage::viewportConfigurationChanged):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 4c8600: Use `LayoutViewportHeightExpansionFactor` when ENA...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 4c8600f0fdb135278d00309feea871c0f78f3217
  
https://github.com/WebKit/WebKit/commit/4c8600f0fdb135278d00309feea871c0f78f3217
  Author: Wenson Hsieh 
  Date:   2024-06-05 (Wed, 05 Jun 2024)

  Changed paths:
M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml

  Log Message:
  ---
  Use `LayoutViewportHeightExpansionFactor` when 
ENABLE(FLEXIBLE_VIEW_SCALE_FACTOR) is set
https://bugs.webkit.org/show_bug.cgi?id=275159

Reviewed by Aditya Keerthi.

Just like on watchOS, allow the layout viewport to be taller than the visual 
viewport by default,
such that fixed-position elements that are docked to the top or bottom of the 
viewport can be
scrolled offscreen, even at initial scale.

* Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml:

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 657184: Add a setting to automatically adjust view scale w...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 6571847835626873b1c3defc28a7ae1c8166d128
  
https://github.com/WebKit/WebKit/commit/6571847835626873b1c3defc28a7ae1c8166d128
  Author: Wenson Hsieh 
  Date:   2024-06-04 (Tue, 04 Jun 2024)

  Changed paths:
M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
M Source/WebKit/Shared/WebPageCreationParameters.h
M Source/WebKit/Shared/WebPageCreationParameters.serialization.in
M Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm
M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm

  Log Message:
  ---
  Add a setting to automatically adjust view scale when min. effective device 
width < view width
https://bugs.webkit.org/show_bug.cgi?id=275125

Reviewed by Aditya Keerthi.

Add a runtime preference to control whether or not the view scale (i.e. layout 
size scale factor)
should automatically adjust to fit the minimum effective device width (mEDW) to 
the actual width of
the view, in the case where the mEDW is less than the view width.

* Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml:
* Source/WebKit/Shared/WebPageCreationParameters.h:
* Source/WebKit/Shared/WebPageCreationParameters.serialization.in:
* Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView _viewScale]):
(-[WKWebView _setViewScale:]):

Rename `layoutSizeScaleFactor` to `layoutSizeScaleFactorFromClient` in 
`WKWebView` / `WebPageProxy`,
to reflect the fact that the client-specified value may be different from the 
effective layout size
scale factor.

(-[WKWebView _setMinimumEffectiveDeviceWidth:]):
* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm:
(-[WKWebView _dispatchSetViewLayoutSize:]):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::creationParameters):
* Source/WebKit/UIProcess/WebPageProxy.h:
* Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm:
(WebKit::WebPageProxy::setViewportConfigurationViewLayoutSize):
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::m_unifiedTextReplacementController):
* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::setViewportConfigurationViewLayoutSize):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 2d687e: Enable support for safe area insets on tvOS

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 2d687e43911ada843add52481c99f8e7f18361da
  
https://github.com/WebKit/WebKit/commit/2d687e43911ada843add52481c99f8e7f18361da
  Author: Wenson Hsieh 
  Date:   2024-06-03 (Mon, 03 Jun 2024)

  Changed paths:
M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm
M Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.mm
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Source/WebKit/UIProcess/ios/WKScrollView.h
M Source/WebKit/UIProcess/ios/WKScrollView.mm
M Tools/TestWebKitAPI/Tests/ios/OverflowScrollViewTests.mm
M Tools/WebKitTestRunner/cocoa/TestRunnerWKWebView.mm

  Log Message:
  ---
  Enable support for safe area insets on tvOS
https://bugs.webkit.org/show_bug.cgi?id=275067

Reviewed by Abrar Rahman Protyasha.

Remove a handful of unnecessary `PLATFORM(APPLETV)` compile-time flags.

* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm:
(contentOffsetBoundedInValidRange):
(-[WKWebView _updateScrollViewInsetAdjustmentBehavior]):
* Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.mm:
(-[WKChildScrollView initWithFrame:]):
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
* Source/WebKit/UIProcess/ios/WKScrollView.h:
* Source/WebKit/UIProcess/ios/WKScrollView.mm:
(-[WKScrollView initWithFrame:]):
* Tools/TestWebKitAPI/Tests/ios/OverflowScrollViewTests.mm:
* Tools/WebKitTestRunner/cocoa/TestRunnerWKWebView.mm:
(-[TestRunnerWKWebView setOverrideSafeAreaInsets:]):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 6bcb6d: Unreviewed, fix the internal watchOS build after 2...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 6bcb6d9f4caa41ef32e7713a7c44887459aa6385
  
https://github.com/WebKit/WebKit/commit/6bcb6d9f4caa41ef32e7713a7c44887459aa6385
  Author: Wenson Hsieh 
  Date:   2024-06-03 (Mon, 03 Jun 2024)

  Changed paths:
M Tools/WebKitTestRunner/cocoa/TestRunnerWKWebView.mm

  Log Message:
  ---
  Unreviewed, fix the internal watchOS build after 279633@main

Add a missing `HAVE(UI_EDIT_MENU_INTERACTION)` compile-time guard.

* Tools/WebKitTestRunner/cocoa/TestRunnerWKWebView.mm:

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 487e2f: Enable `HAVE_UI_EDIT_MENU_INTERACTION` on tvOS

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 487e2f32fbc2e5661841ae6c365671ef96436158
  
https://github.com/WebKit/WebKit/commit/487e2f32fbc2e5661841ae6c365671ef96436158
  Author: Wenson Hsieh 
  Date:   2024-06-02 (Sun, 02 Jun 2024)

  Changed paths:
M Source/WTF/wtf/PlatformHave.h
M Source/WebKit/UIProcess/API/Cocoa/WKUIDelegate.h
M Tools/WebKitTestRunner/cocoa/TestRunnerWKWebView.mm

  Log Message:
  ---
  Enable `HAVE_UI_EDIT_MENU_INTERACTION` on tvOS
https://bugs.webkit.org/show_bug.cgi?id=275034

Reviewed by Richard Robinson and Aditya Keerthi.

Adjust this compile-time flag, to reflect the fact that the relevant system 
APIs exist on tvOS.

* Source/WTF/wtf/PlatformHave.h:

Also clean up a couple of now-unused feature flags.

* Source/WebKit/UIProcess/API/Cocoa/WKUIDelegate.h:
* Tools/WebKitTestRunner/cocoa/TestRunnerWKWebView.mm:
(-[TestRunnerWKWebView immediatelyDismissEditMenuInteractionIfNeeded]):

Soft-link `UIEditMenuInteraction` here to keep the non-internal build passing, 
since it's only
available as SPI on tvOS.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] f2b8d7: [Remote Inspection] Refactor some code for copying...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: f2b8d72e13c34c2d1c00d57ee729628a29dd440d
  
https://github.com/WebKit/WebKit/commit/f2b8d72e13c34c2d1c00d57ee729628a29dd440d
  Author: Wenson Hsieh 
  Date:   2024-05-31 (Fri, 31 May 2024)

  Changed paths:
M Source/WebCore/page/ElementTargetingController.cpp
M Source/WebCore/page/ElementTargetingTypes.h
M Source/WebCore/page/text-extraction/TextExtraction.cpp
M Source/WebCore/page/text-extraction/TextExtraction.h
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Source/WebKit/UIProcess/API/APITargetedElementInfo.h
M Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementInfo.h
M Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementInfo.mm
M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm
A Tools/TestWebKitAPI/Tests/WebKitCocoa/element-targeting-9.html

  Log Message:
  ---
  [Remote Inspection] Refactor some code for copying rendered text from 
selected elements
https://bugs.webkit.org/show_bug.cgi?id=274995
rdar://129079086

Reviewed by Richard Robinson.

Refactor some code for extracting rendered text from targeted elements, and 
expose a new property to
indicate that a targeted element contains a large replaced renderer. See below 
for more details.

* Source/WebCore/page/ElementTargetingController.cpp:
(WebCore::targetedElementInfo):
(WebCore::ElementTargetingController::snapshotIgnoringVisibilityAdjustment):

Drive-by fix: use `snapshotFrameRect()` here, passing in an element rect in 
absolute coordinates
that respects transforms.

* Source/WebCore/page/ElementTargetingTypes.h:
* Source/WebCore/page/text-extraction/TextExtraction.cpp:
(WebCore::TextExtraction::extractRenderedTokens):

Refactor this logic to return both the "rendered text" representation with and 
without `{W,H}` at
once, along with a flag indicating whether any individual replaced renderer was 
large enough to fill
most of the targeted element (90% of the width and height). This is an 
improvement over the current
code, which performs the entire render tree traversal twice to compute both 
versions of rendered
text.

This refactoring allows us to instead collect a series of "tokens" (either a 
rounded size
representing a replaced renderer or background image, or a piece of rendered 
text) with a single
traversal, and then produce both versions of the string while iterating once 
over all the tokens.

(WebCore::TextExtraction::extractRenderedText):
* Source/WebCore/page/text-extraction/TextExtraction.h:
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
* Source/WebKit/UIProcess/API/APITargetedElementInfo.h:
* Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementInfo.h:
* Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementInfo.mm:
(-[_WKTargetedElementInfo hasLargeReplacedDescendant]):
* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm:
(TestWebKitAPI::TEST(ElementTargeting, 
ReplacedRendererSizeIgnoresPageScaleAndZoom)):
(TestWebKitAPI::TEST(ElementTargeting, TargetedElementWithLargeImage)):
(TestWebKitAPI::TEST(ElementTargeting, TargetedElementScreenReaderText)): 
Deleted.
* Tools/TestWebKitAPI/Tests/WebKitCocoa/element-targeting-9.html: Added.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 90aaf2: Enable a couple of feature flags in PlatformHave.h...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 90aaf2621d41a0beef16f7f97efe8e8a74b058ed
  
https://github.com/WebKit/WebKit/commit/90aaf2621d41a0beef16f7f97efe8e8a74b058ed
  Author: Wenson Hsieh 
  Date:   2024-05-30 (Thu, 30 May 2024)

  Changed paths:
M Source/WTF/wtf/PlatformHave.h
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm

  Log Message:
  ---
  Enable a couple of feature flags in PlatformHave.h on tvOS
https://bugs.webkit.org/show_bug.cgi?id=274911

Reviewed by Abrar Rahman Protyasha.

Enable `HAVE_UI_TEXT_SELECTION_DISPLAY_INTERACTION` and remove 
`HAVE_CANCEL_WEB_TOUCH_EVENTS_GESTURE`
entirely, since we no longer depend on SPI for touch events on all iOS family 
ports.

* Source/WTF/wtf/PlatformHave.h:
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _cancelTouchEventGestureRecognizer]):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 34fbb9: NEW TEST (279267@main): [ MacOS iOS Debug ] TestWe...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 34fbb92a4327f71b18e359e11a89a114427f320e
  
https://github.com/WebKit/WebKit/commit/34fbb92a4327f71b18e359e11a89a114427f320e
  Author: Wenson Hsieh 
  Date:   2024-05-29 (Wed, 29 May 2024)

  Changed paths:
M Tools/TestWebKitAPI/Tests/WebKit/AdvancedPrivacyProtections.mm

  Log Message:
  ---
  NEW TEST (279267@main): [ MacOS iOS Debug ] 
TestWebKitAPI.AdvancedPrivacyProtections.NoiseInjectionForOffscreenCanvasInSharedWorker
 is a consistent crash
https://bugs.webkit.org/show_bug.cgi?id=274786
rdar://128876237

Reviewed by Abrar Rahman Protyasha and Chris Dumez.

`sharedWorkerBytes()` currently attempts to create an `ASCIILiteral` from a 
multiline string literal
that contains the  emoji; this results in a debug assertion (as expected). Fix 
this by simply
using `String::fromUTF8` instead.

* Tools/TestWebKitAPI/Tests/WebKit/AdvancedPrivacyProtections.mm:
(TestWebKitAPI::(AdvancedPrivacyProtections, 
NoiseInjectionForOffscreenCanvasInSharedWorker)): Deleted.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 3abd48: [Remote Inspection] Adjust the heuristic when comp...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 3abd48ae06eaeb85830aa83b2983cf0b80fefa15
  
https://github.com/WebKit/WebKit/commit/3abd48ae06eaeb85830aa83b2983cf0b80fefa15
  Author: Wenson Hsieh 
  Date:   2024-05-28 (Tue, 28 May 2024)

  Changed paths:
M Source/WebCore/page/ElementTargetingController.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm

  Log Message:
  ---
  [Remote Inspection] Adjust the heuristic when computing the adjustment rect 
count
https://bugs.webkit.org/show_bug.cgi?id=274810
rdar://128885913

Reviewed by Abrar Rahman Protyasha and Megan Gardner.

Make a minor adjustment to how we handle empty (or `display: none;`) elements 
when getting the total
adjustment rect count, so that they count towards the final result.

* Source/WebCore/page/ElementTargetingController.cpp:
(WebCore::ElementTargetingController::numberOfVisibilityAdjustmentRects const):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm:
(TestWebKitAPI::TEST(ElementTargeting, AdjustVisibilityFromSelectors)):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] ae3642: [Remote Inspection] Add the ability to snapshot a ...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: ae3642d0a5304c0cf0955fc51c32b5103ec06b78
  
https://github.com/WebKit/WebKit/commit/ae3642d0a5304c0cf0955fc51c32b5103ec06b78
  Author: Wenson Hsieh 
  Date:   2024-05-26 (Sun, 26 May 2024)

  Changed paths:
M Source/WebCore/page/ElementTargetingController.cpp
M Source/WebCore/page/ElementTargetingController.h
M Source/WebKit/UIProcess/API/APITargetedElementInfo.cpp
M Source/WebKit/UIProcess/API/APITargetedElementInfo.h
M Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementInfo.h
M Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementInfo.mm
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/WebPage.messages.in
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm

  Log Message:
  ---
  [Remote Inspection] Add the ability to snapshot a targeted element
https://bugs.webkit.org/show_bug.cgi?id=274718

Reviewed by Richard Robinson.

Add support for `-[_WKTargetedElementInfo takeSnapshotWithCompletionHandler:]`.
See below for more details.

Test: ElementTargeting.SnapshotElementWithVisibilityAdjustment

* Source/WebCore/page/ElementTargetingController.cpp:
(WebCore::ClearVisibilityAdjustmentForScope::ClearVisibilityAdjustmentForScope):
(WebCore::ClearVisibilityAdjustmentForScope::~ClearVisibilityAdjustmentForScope):

Add a RAII helper class to temporarily clear visibility adjustment flags from a 
given element.

(WebCore::ElementTargetingController::snapshotIgnoringVisibilityAdjustment):

Add a method to snapshot the element corresponding to the given identifiers, 
ignoring the effects of
visibility adjustment.

* Source/WebCore/page/ElementTargetingController.h:
* Source/WebKit/UIProcess/API/APITargetedElementInfo.cpp:
(API::TargetedElementInfo::takeSnapshot):
* Source/WebKit/UIProcess/API/APITargetedElementInfo.h:
* Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementInfo.h:
* Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementInfo.mm:
(-[_WKTargetedElementInfo takeSnapshotWithCompletionHandler:]):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::takeSnapshotForTargetedElement):
* Source/WebKit/UIProcess/WebPageProxy.h:
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::takeSnapshotForTargetedElement):
* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Source/WebKit/WebProcess/WebPage/WebPage.messages.in:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm:
(-[_WKTargetedElementInfo takeSnapshot]):
(TestWebKitAPI::TEST(ElementTargeting, 
SnapshotElementWithVisibilityAdjustment)):

Add an API test to exercise the change.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 6ddb74: [Remote Inspection] Right click > Toggle Visibilit...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 6ddb740bdea7c4f3d92623dea99d7771f79c5a21
  
https://github.com/WebKit/WebKit/commit/6ddb740bdea7c4f3d92623dea99d7771f79c5a21
  Author: Wenson Hsieh 
  Date:   2024-05-23 (Thu, 23 May 2024)

  Changed paths:
M Source/WebCore/page/ElementTargetingController.cpp
M Source/WebCore/page/ElementTargetingController.h
M Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementInfo.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm

  Log Message:
  ---
  [Remote Inspection] Right click > Toggle Visibility sometimes fails to reveal 
hidden elements
https://bugs.webkit.org/show_bug.cgi?id=274586

Reviewed by Aditya Keerthi.

Make a couple of minor adjustments to undo initial visibility adjustment rules 
when Web Inspector
resets "Toggle Visibility" state for targeted elements.

* Source/WebCore/page/ElementTargetingController.cpp:
(WebCore::ElementTargetingController::adjustVisibilityInRepeatedlyTargetedRegions):
(WebCore::ElementTargetingController::reset):
(WebCore::ElementTargetingController::resetVisibilityAdjustments):
* Source/WebCore/page/ElementTargetingController.h:
* Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementInfo.mm:
(-[_WKTargetedElementInfo debugDescription]):

Also, add a `-debugDescription` to make debug logging more useful.

* Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm:
(TestWebKitAPI::TEST(ElementTargeting, RequestElementsFromSelectors)):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 9b7b8d: [Remote Inspection] Add the ability to target elem...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 9b7b8ded8fa6f6aa85d72ec5f68bee3252c00a81
  
https://github.com/WebKit/WebKit/commit/9b7b8ded8fa6f6aa85d72ec5f68bee3252c00a81
  Author: Wenson Hsieh 
  Date:   2024-05-22 (Wed, 22 May 2024)

  Changed paths:
M Source/WebCore/page/ElementTargetingController.cpp
M Source/WebCore/page/ElementTargetingController.h
M Source/WebCore/page/ElementTargetingTypes.h
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Source/WebKit/UIProcess/API/APITargetedElementInfo.h
M Source/WebKit/UIProcess/API/APITargetedElementRequest.cpp
M Source/WebKit/UIProcess/API/APITargetedElementRequest.h
M Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementInfo.h
M Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementInfo.mm
M Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementRequest.h
M Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementRequest.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm

  Log Message:
  ---
  [Remote Inspection] Add the ability to target elements based on selector 
information
https://bugs.webkit.org/show_bug.cgi?id=274532

Reviewed by Aditya Keerthi.

Add the ability to target elements based on compound selectors (i.e. selectors 
including all shadow
hosts). Additionally, expose a new property on targeted element info to 
indicate whether or not the
element is inside of an adjustment subtree.

See below for more details.

Test: ElementTargeting.RequestElementsFromSelectors

* Source/WebCore/page/ElementTargetingController.cpp:
(WebCore::targetedElementInfo):
(WebCore::ElementTargetingController::findTargets):
(WebCore::ElementTargetingController::findNodes):

Add `WebCore::TargetedElementSelectors` as a new type of targeted element 
request data, alongside
a point in root view coordinates and a search string. Add a new `findNodes()` 
implementation for
this targeted element selectors list. Build on top of the 
`findElementFromSelectors` method (see
below for more details).

(WebCore::ElementTargetingController::extractTargets):

Drive-by adjustment: only target elements if they're non-empty. This can 
otherwise happen in the
case where the list of candidates was derived from ascending the DOM when 
performing a text search.

(WebCore::ElementTargetingController::adjustVisibilityInRepeatedlyTargetedRegions):
(WebCore::resolveSelectorToQuery):

Pull this out into a separate static helper function, so we can use it from 
both methods below.

(WebCore::ElementTargetingController::applyVisibilityAdjustmentFromSelectors):

Pull logic out of this method, and into `findElementFromSelectors`. Also, 
remove the document
argument (which was only ever the main document), and instead just retrieve the 
main document from
the `m_page` (or exit early if it's null).

(WebCore::ElementTargetingController::findElementFromSelectors):

Factor out logic for mapping a list of compound selectors (including all shadow 
hosts) into a
separate private method, so that it can be reused in multiple places in this 
class.

(WebCore::ElementTargetingController::mainDocument const):

Avoid some code duplication by adding a private helper method to return the 
main document, through
`m_page`.

(WebCore::ElementTargetingController::selectorBasedVisibilityAdjustmentTimerFired):
* Source/WebCore/page/ElementTargetingController.h:
* Source/WebCore/page/ElementTargetingTypes.h:
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:

Add the new IPC types.

* Source/WebKit/UIProcess/API/APITargetedElementInfo.h:
* Source/WebKit/UIProcess/API/APITargetedElementRequest.cpp:
(API::TargetedElementRequest::setSelectors):
(API::TargetedElementRequest::searchText const): Deleted.

Remove an unused getter for `-searchText`, along with support in the API object.

* Source/WebKit/UIProcess/API/APITargetedElementRequest.h:
* Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementInfo.h:
* Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementInfo.mm:
(-[_WKTargetedElementInfo isInVisibilityAdjustmentSubtree]):
* Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementRequest.h:
* Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementRequest.mm:
(-[_WKTargetedElementRequest initWithSelectors:]):

Add a new initializer that takes a compound selector representing the element 
to target.

(-[_WKTargetedElementRequest searchText]): Deleted.
(-[_WKTargetedElementRequest point]): Deleted.
* Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm:
(-[WKWebView targetedElementInfoWithSelectors:]):
(TestWebKitAPI::TEST(ElementTargeting, RequestElementsFromSelectors)):

Add a new API test to exercise the change.

(TestWebKitAPI::TEST(ElementTargeting, AdjustVisibilityFromPseudoSelectors)):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications

[webkit-changes] [WebKit/WebKit] 76a6ff: nonce hiding in SVG is buggy

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 76a6ff4a88da11885fb1c5b8af8b41bf0a7844b5
  
https://github.com/WebKit/WebKit/commit/76a6ff4a88da11885fb1c5b8af8b41bf0a7844b5
  Author: Ryosuke Niwa 
  Date:   2024-05-22 (Wed, 22 May 2024)

  Changed paths:
A 
LayoutTests/http/tests/security/contentSecurityPolicy/nonce-hiding-on-svg-script-expected.txt
A 
LayoutTests/http/tests/security/contentSecurityPolicy/nonce-hiding-on-svg-script.py
M Source/WebCore/dom/ScriptElement.cpp
M Source/WebCore/svg/SVGElement.cpp

  Log Message:
  ---
  nonce hiding in SVG is buggy
https://bugs.webkit.org/show_bug.cgi?id=268598
rdar://122151552

Reviewed by Chris Dumez.

The bug was caused by SVGElement::insertedIntoAncestor hiding nonce after it 
had an early exit for returning
InsertedIntoAncestorResult::NeedsPostInsertionCallback. Fixed the bug by hiding 
it before this early exit.

* 
LayoutTests/http/tests/security/contentSecurityPolicy/nonce-hiding-on-svg-script-expected.txt:
 Added.
* 
LayoutTests/http/tests/security/contentSecurityPolicy/nonce-hiding-on-svg-script.py:
 Added.
* Source/WebCore/dom/ScriptElement.cpp:
(WebCore::ScriptElement::didFinishInsertingNode):
* Source/WebCore/svg/SVGElement.cpp:
(WebCore::SVGElement::insertedIntoAncestor):

Originally-landed-as: 272448.567@safari-7618-branch (d915a3b6357c). 
rdar://128504044
Canonical link: https://commits.webkit.org/279131@main


  Commit: 9e5283739c9809f145488a20f8a52f09fd3a85f4
  
https://github.com/WebKit/WebKit/commit/9e5283739c9809f145488a20f8a52f09fd3a85f4
  Author: Chris Dumez 
  Date:   2024-05-22 (Wed, 22 May 2024)

  Changed paths:
M Source/WebCore/workers/WorkerOrWorkletThread.cpp

  Log Message:
  ---
  Flaky crash under WorkerDedicatedRunLoop::runCleanupTasks() during fuzzing
https://bugs.webkit.org/show_bug.cgi?id=269731
rdar://121961101

Reviewed by Brent Fulgham.

I haven't been able to reproduce but based on the ASAN report, it looks
like the WorkerOrWorkletGlobalScope is getting destroyed in the middle
of WorkerDedicatedRunLoop::runCleanupTasks(), causing a use-after free
of the context.

To make sure this can't happen, apply our smart pointer adoption rules
and make sure the WorkerOrWorkletGlobalScope is being protected on the
stack at the call site of WorkerDedicatedRunLoop::run() before passing
it in argument.

* Source/WebCore/workers/WorkerOrWorkletThread.cpp:
(WebCore::WorkerOrWorkletThread::runEventLoop):

Originally-landed-as: 272448.578@safari-7618-branch (459d377c63c2). 
rdar://128504577
Canonical link: https://commits.webkit.org/279132@main


  Commit: 5944980db644fb2ea879bf3e2d6e5efd47156cdc
  
https://github.com/WebKit/WebKit/commit/5944980db644fb2ea879bf3e2d6e5efd47156cdc
  Author: Wenson Hsieh 
  Date:   2024-05-22 (Wed, 22 May 2024)

  Changed paths:
M Source/WebCore/loader/EmptyClients.cpp
M Source/WebCore/page/EditorClient.h
M Source/WebCore/page/LocalFrame.cpp
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/UIProcess/WebPageProxy.messages.in
M Source/WebKit/WebProcess/WebCoreSupport/WebEditorClient.cpp
M Source/WebKit/WebProcess/WebCoreSupport/WebEditorClient.h
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKitLegacy/mac/WebCoreSupport/WebEditorClient.h

  Log Message:
  ---
  Compromised web process can grant pasteboard access by spamming 
WebPage::RequestDOMPasteAccess
https://bugs.webkit.org/show_bug.cgi?id=269769
rdar://97343267

Reviewed by Ryosuke Niwa and Richard Robinson.

It's currently possible for a compromised web process to send arbitrary 
`originIdentifiers` through
`requestDOMPasteAccess` to the UI process during programmatic paste. Since the 
UI process
automatically grants programmatic pasteboard access in the case where the 
incoming origin ID matches
the origin ID of the current pasteboard content, it's possible to send a large 
number of origins
through this IPC endpoint, with the end goal of discovering both (1) which 
website origin the user
last copied from, and (2) the contents of the pasteboard in the case where the 
pasteboard copied
from web content in WebKit.

To mitigate this attack vector, we add a `FrameIdentifier` in the IPC endpoint, 
which is used in the
UI process to verify that:

1.  The incoming frame ID corresponds to a frame underneath the destination 
page.
2.  The pasteboard origin matches the origin of the frame, unless the 
pasteboard origin is an opaque
(null) origin.

Additionally, we throttle pasteboard access requests to a maximum of 10 
different domains every 5
seconds, to mitigate another variation on this attack vector where the 
compromised web process loads
a large number of cross-origin frames and requests pasteboard access on behalf 
of those origins, in
an attempt to get around the limitations above.

With this change, a compromised

[webkit-changes] [WebKit/WebKit] c6a818: [macOS] WKTextFinderMatch should hold a weak point...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: c6a818caffef1a6f4ccc3d1ffcd573e4c8dc0fd3
  
https://github.com/WebKit/WebKit/commit/c6a818caffef1a6f4ccc3d1ffcd573e4c8dc0fd3
  Author: Wenson Hsieh 
  Date:   2024-05-21 (Tue, 21 May 2024)

  Changed paths:
M Source/WebKit/UIProcess/mac/WKTextFinderClient.mm

  Log Message:
  ---
  [macOS] WKTextFinderMatch should hold a weak pointer to its client
https://bugs.webkit.org/show_bug.cgi?id=274498

Reviewed by Aditya Keerthi and Abrar Protyasha.

Use a weak ObjC pointer for the `_client` ivar, instead of a raw pointer.

* Source/WebKit/UIProcess/mac/WKTextFinderClient.mm:
(-[WKTextFinderMatch generateTextImage:]):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 435af5: [Remote Inspection] Surface image, media and link ...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 435af5beb5ff9261093529de205c5d30d30d222a
  
https://github.com/WebKit/WebKit/commit/435af5beb5ff9261093529de205c5d30d30d222a
  Author: Wenson Hsieh 
  Date:   2024-05-21 (Tue, 21 May 2024)

  Changed paths:
M Source/WebCore/page/ElementTargetingController.cpp
M Source/WebCore/page/ElementTargetingTypes.h
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Source/WebKit/UIProcess/API/APITargetedElementInfo.h
M Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementInfo.h
M Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementInfo.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm

  Log Message:
  ---
  [Remote Inspection] Surface image, media and link URLs in selected element 
subtrees
https://bugs.webkit.org/show_bug.cgi?id=274476

Reviewed by Megan Gardner and Abrar Protyasha.

Add support for a `-mediaAndLinkURLs` property that exposes a set of `NSURL`s 
derived from scanning
the DOM subtree for targeted elements in search of:

- Media element source URLs
- Image source URLs
- Link HREFs
- CSS background image URLs

* Source/WebCore/page/ElementTargetingController.cpp:
(WebCore::urlForElement):
(WebCore::collectAllMediaAndLinkURLsRecursive):
(WebCore::collectUniqueMediaAndLinkURLs):
(WebCore::targetedElementInfo):
* Source/WebCore/page/ElementTargetingTypes.h:
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
* Source/WebKit/UIProcess/API/APITargetedElementInfo.h:
* Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementInfo.h:
* Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementInfo.mm:
(-[_WKTargetedElementInfo mediaAndLinkURLs]):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm:
(TestWebKitAPI::TEST(ElementTargeting, 
RequestTargetedElementsBySearchableText)):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] ea884a: [iOS] Enable automatic live resize on iPadOS at ru...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: ea884a9b50d637b50ca72d62c0813d555f94bc19
  
https://github.com/WebKit/WebKit/commit/ea884a9b50d637b50ca72d62c0813d555f94bc19
  Author: Wenson Hsieh 
  Date:   2024-05-20 (Mon, 20 May 2024)

  Changed paths:
M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
M Source/WebKit/Platform/spi/ios/UIKitSPI.h
M Source/WebKit/Shared/WebPreferencesDefaultValues.h
M Source/WebKit/Shared/ios/WebPreferencesDefaultValuesIOS.mm
M Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h
M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm

  Log Message:
  ---
  [iOS] Enable automatic live resize on iPadOS at runtime
https://bugs.webkit.org/show_bug.cgi?id=274410

Reviewed by Abrar Rahman Protyasha.

Enable automatic live resize on iPad, with runtime enablement guarded by a 
system feature flag.
Additionally, remove usage of two SPIs that currently support automatic live 
resize behaviors:

• `_UIWindowSceneDidEndLiveResizeNotification`
• `-[UIWindowScene _isInLiveResize]`

...by instead changing how automatic live resize works:

(a) Don't wait for the live resize gesture to end before allowing geometry 
updates to commence;
instead, use an arbitrary hysteresis of 500 ms to determine when the 
viewport dimensions have
stabilized, before ending live resize.

(b) Use automatic live resize whenever the window itself is changing size; to 
detect this, keep
track of the last known size of the window containing the web view, and 
only trigger live resize
when this size is changing.

* Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml:
* Source/WebKit/Platform/spi/ios/UIKitSPI.h:
* Source/WebKit/Shared/WebPreferencesDefaultValues.h:
* Source/WebKit/Shared/ios/WebPreferencesDefaultValuesIOS.mm:
(WebKit::defaultAutomaticLiveResizeEnabled):
* Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h:
* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm:
(-[WKWebView didMoveToWindow]):
(-[WKWebView _beginAutomaticLiveResizeIfNeeded]):

Refactor this so that we debounce the new "end live resize" timer instead of 
just early returning
when the size changes.

(-[WKWebView _rescheduleEndLiveResizeTimer]):
(-[WKWebView _acquireResizeAssertionForReason:]):

Remove unnecessary runtime staging, since support for this SPI has long shipped.

(-[WKWebView _endLiveResize]):
(-[WKWebView _destroyEndLiveResizeObserver]): Deleted.

Replace this notification observer with an `NSTimer` instead, which is 
debounced whenever the web
view size changes, and otherwise fires after a fixed delay of half a second.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 2713a2: Clean up some platform-specific feature flags

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 2713a25b31f311b045b19c0b026fb052fb99b79e
  
https://github.com/WebKit/WebKit/commit/2713a25b31f311b045b19c0b026fb052fb99b79e
  Author: Wenson Hsieh 
  Date:   2024-05-19 (Sun, 19 May 2024)

  Changed paths:
M Source/WTF/wtf/PlatformHave.h
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/DocumentEditingContext.mm

  Log Message:
  ---
  Clean up some platform-specific feature flags
https://bugs.webkit.org/show_bug.cgi?id=274369
rdar://128278820

Reviewed by Abrar Rahman Protyasha and Richard Robinson.

Turn `HAVE_UI_WK_DOCUMENT_CONTEXT` on when compiling for tvOS. Also, move the 
implementation of
`-requestDocumentContext:completionHandler:` (guarded by 
`HAVE(UI_WK_DOCUMENT_CONTEXT)`) and the
code behind `USE(UICONTEXTMENU)` out of the `ENABLE(DRAG_SUPPORT)` compile-time 
guards in
`WKContentViewInteraction.mm`.

* Source/WTF/wtf/PlatformHave.h:
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView insertTextPlaceholderWithSize:completionHandler:]):
(-[WKContentView removeTextPlaceholder:willInsertText:completionHandler:]):
(sizesOfPlaceholderElementsToInsertWhenDroppingItems):
(-[WKContentView _handleDropByInsertingImagePlaceholders:session:]):
(-[WKContentView _dragInteraction:shouldDelayCompetingGestureRecognizer:]):
(-[WKContentView _dragInteraction:dataOwnerForSession:]):
(-[WKContentView 
_dragInteraction:itemsForAddingToSession:withTouchAtPoint:completion:]):
(-[WKContentView _dragInteraction:prepareForSession:completion:]):
(-[WKContentView dragInteraction:itemsForBeginningSession:]):
(-[WKContentView dragInteraction:previewForLiftingItem:session:]):
(-[WKContentView dragInteraction:willAnimateLiftWithAnimator:session:]):
(-[WKContentView dragInteraction:sessionWillBegin:]):
(-[WKContentView dragInteraction:session:didEndWithOperation:]):
(-[WKContentView dragInteraction:previewForCancellingItem:withDefault:]):
(-[WKContentView dragInteraction:item:willAnimateCancelWithAnimator:]):
(-[WKContentView dragInteraction:sessionDidTransferItems:]):
(-[WKContentView dragInteraction:prepareDragSession:completion:]):
(-[WKContentView 
dragInteraction:itemsForAddingToSession:forTouchAtPoint:completion:]):
(-[WKContentView _dropInteraction:dataOwnerForSession:]):
(-[WKContentView dropInteraction:canHandleSession:]):
(-[WKContentView dropInteraction:sessionDidEnter:]):
(-[WKContentView dropInteraction:sessionDidUpdate:]):
(-[WKContentView dropInteraction:sessionDidExit:]):
(-[WKContentView dropInteraction:performDrop:]):
(-[WKContentView dropInteraction:item:willAnimateDropWithAnimator:]):
(-[WKContentView dropInteraction:concludeDrop:]):
(-[WKContentView dropInteraction:previewForDroppingItem:withDefault:]):
(-[WKContentView dropInteraction:sessionDidEnd:]):
(-[WKContentView cancelActiveTextInteractionGestures]):
(-[WKContentView textEffectsWindow]):
(-[WKContentView _autofillContext]):
(uiImageForImage):
(createTargetedPreview):
(createFallbackTargetedPreview):
(-[WKContentView _createTargetedContextMenuHintPreviewForFocusedElement:]):
(-[WKContentView positionInformationHasImageOverlayDataDetector]):
(-[WKContentView _createTargetedContextMenuHintPreviewIfPossible]):
(-[WKContentView _removeContextMenuHintContainerIfPossible]):
(toWebDocumentRequestOptions):
(toWebRequest):
(-[WKContentView adjustSelectionWithDelta:completionHandler:]):
(-[WKContentView requestDocumentContext:completionHandler:]):
(-[WKContentView selectPositionAtPoint:withContextRequest:completionHandler:]):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/DocumentEditingContext.mm:

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 098f67: Rendered text extraction should exclude Live Text

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 098f678e610d8fe1301289362d2b8a49eedaae2f
  
https://github.com/WebKit/WebKit/commit/098f678e610d8fe1301289362d2b8a49eedaae2f
  Author: Wenson Hsieh 
  Date:   2024-05-18 (Sat, 18 May 2024)

  Changed paths:
A 
LayoutTests/fast/element-targeting/target-rendered-text-excludes-live-text-expected.txt
A 
LayoutTests/fast/element-targeting/target-rendered-text-excludes-live-text.html
M Source/WebCore/page/text-extraction/TextExtraction.cpp

  Log Message:
  ---
  Rendered text extraction should exclude Live Text
https://bugs.webkit.org/show_bug.cgi?id=274355
rdar://128213708

Reviewed by Richard Robinson.

Exclude Live Text in UA shadow roots under image elements, for the purposes of 
extracting rendered
text.

* 
LayoutTests/fast/element-targeting/target-rendered-text-excludes-live-text-expected.txt:
 Added.
* 
LayoutTests/fast/element-targeting/target-rendered-text-excludes-live-text.html:
 Added.
* Source/WebCore/page/text-extraction/TextExtraction.cpp:
(WebCore::TextExtraction::extractRenderedText):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 1e5a82: REGRESSION (278815@main): [ MacOS iOS Debug ] Test...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 1e5a82de122e187fb66f39af69abc2a35557b72c
  
https://github.com/WebKit/WebKit/commit/1e5a82de122e187fb66f39af69abc2a35557b72c
  Author: Wenson Hsieh 
  Date:   2024-05-17 (Fri, 17 May 2024)

  Changed paths:
M Source/WebCore/platform/audio/AudioUtilities.cpp

  Log Message:
  ---
  REGRESSION (278815@main): [ MacOS iOS Debug ] 
TestWebKitAPI.AdvancedPrivacyProtections.AddNoiseToWebAudioAPIs is a consistent 
failure
https://bugs.webkit.org/show_bug.cgi?id=274266
rdar://128209071

Reviewed by Chris Dumez.

Allocations are forbidden here for performance reasons:

```
void AudioDestinationNode::renderQuantum(…)
{
…

// For performance reasons, we forbid heap allocations while doing 
rendering on the audio thread.
// Heap allocations that cannot be avoided or have not been fixed yet can 
be allowed using
// DisableMallocRestrictionsForCurrentThreadScope scope variables.
ForbidMallocUseForCurrentThreadScope forbidMallocUse;
```

When applying noise (in the case where Advanced Privacy Protections are 
enabled), honor this by
stack-allocating the noise multiplier buffer instead.

* Source/WebCore/platform/audio/AudioUtilities.cpp:
(WebCore::AudioUtilities::applyNoise):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 226a1a: Include elements with background images in `-[WKTa...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 226a1a0f209e945a3443dee265d44e28ba2810aa
  
https://github.com/WebKit/WebKit/commit/226a1a0f209e945a3443dee265d44e28ba2810aa
  Author: Wenson Hsieh 
  Date:   2024-05-17 (Fri, 17 May 2024)

  Changed paths:
A 
LayoutTests/fast/element-targeting/target-rendered-text-with-background-image-expected.txt
A 
LayoutTests/fast/element-targeting/target-rendered-text-with-background-image.html
M Source/WebCore/page/ElementTargetingController.cpp
M Source/WebCore/page/text-extraction/TextExtraction.cpp
M Source/WebCore/page/text-extraction/TextExtraction.h

  Log Message:
  ---
  Include elements with background images in `-[WKTargetedElementInfo 
renderedText]`
https://bugs.webkit.org/show_bug.cgi?id=274313
rdar://127515119

Reviewed by Aditya Keerthi.

Indicate CSS background images in rendered text strings for targeted elements, 
in the same way as
replaced renderers.

* 
LayoutTests/fast/element-targeting/target-rendered-text-with-background-image-expected.txt:
 Added.
* 
LayoutTests/fast/element-targeting/target-rendered-text-with-background-image.html:
 Added.

Add a new test to exercise the change.

* Source/WebCore/page/ElementTargetingController.cpp:
(WebCore::targetedElementInfo):

Also rename `IncludeGeometryText` to `OnlyIncludeTextContent` and flip values 
in each call site from
`Yes` ⇆ `No`, since "geometry text" is a somewhat-vague term.

* Source/WebCore/page/text-extraction/TextExtraction.cpp:
(WebCore::TextExtraction::extractRenderedText):
* Source/WebCore/page/text-extraction/TextExtraction.h:

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 24339c: REGRESSION (278484@main): [ iOS ] editing/selectio...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 24339c7cdb4184f03fceb677a8807f6f65c754ce
  
https://github.com/WebKit/WebKit/commit/24339c7cdb4184f03fceb677a8807f6f65c754ce
  Author: Wenson Hsieh 
  Date:   2024-05-16 (Thu, 16 May 2024)

  Changed paths:
M 
LayoutTests/editing/selection/ios/persist-selection-after-tapping-on-element-with-mousedown-handler.html
M LayoutTests/platform/ios/TestExpectations
M Source/WebKit/UIProcess/API/gtk/PageClientImpl.h
M Source/WebKit/UIProcess/API/wpe/PageClientImpl.h
M Source/WebKit/UIProcess/PageClient.h
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/ios/PageClientImplIOS.h
M Source/WebKit/UIProcess/ios/PageClientImplIOS.mm
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.h
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Source/WebKit/UIProcess/mac/PageClientImplMac.h
M Source/WebKit/UIProcess/playstation/PageClientImpl.h
M Source/WebKit/UIProcess/win/PageClientImpl.h

  Log Message:
  ---
  REGRESSION (278484@main): [ iOS ] 
editing/selection/ios/place-selection-in-overflow-area.html is a consistent 
timeout
https://bugs.webkit.org/show_bug.cgi?id=274180
rdar://128086114

Reviewed by Abrar Protyasha.

After the changes in 278484@main, this test began to intermittently fail, but 
only when run after
another layout test that ends with a selection rect over the tap location, 
`(25, 25)`. This is
because the new logic to clear out the UI-side cached editor state in 
`278484@main` leaves the
editor state without post-layout or visual data. This means that the 
`_lastSelectionDrawingInfo` on
`WKContentView` isn't updated to reflect the fact that there's no more 
selection after committing
the load.

Subsequently, `-_shouldToggleSelectionCommandsAfterTapAt:` returns `YES` since 
we (incorrectly)
think the user is still tapping a selection rect, which should toggle the edit 
menu instead of being
handled as a synthetic click.

To fix this, clear out the stale `_lastSelectionDrawingInfo` (along with 
`_cachedSelectedTextRange`)
from the previous page upon transitioning to a new page.

* 
LayoutTests/editing/selection/ios/persist-selection-after-tapping-on-element-with-mousedown-handler.html:

Drive-by fix: remove a redundant call to `testRunner.notifyDone()`. This test 
currently ends faster
than intended, since it doesn't wait for the keyboard to be dismissed.

* LayoutTests/platform/ios/TestExpectations:

Remove failing test expectations.

* Source/WebKit/UIProcess/API/gtk/PageClientImpl.h:
* Source/WebKit/UIProcess/API/wpe/PageClientImpl.h:
* Source/WebKit/UIProcess/PageClient.h:
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::clearEditorStateAfterPageTransition):

Add a separate client method to call out to `WKContentView` (on iOS) to 
invalidate selection drawing
info when transitioning to a new page.

* Source/WebKit/UIProcess/ios/PageClientImplIOS.h:
* Source/WebKit/UIProcess/ios/PageClientImplIOS.mm:
(WebKit::PageClientImpl::didClearEditorStateAfterPageTransition):
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.h:
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _didClearEditorStateAfterPageTransition]):
* Source/WebKit/UIProcess/mac/PageClientImplMac.h:
* Source/WebKit/UIProcess/playstation/PageClientImpl.h:
* Source/WebKit/UIProcess/win/PageClientImpl.h:

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 316776: [Writing Suggestions] Prediction sometimes appears...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 316776c063a7e94ad008c5c9db5fa78b801d7824
  
https://github.com/WebKit/WebKit/commit/316776c063a7e94ad008c5c9db5fa78b801d7824
  Author: Wenson Hsieh 
  Date:   2024-05-15 (Wed, 15 May 2024)

  Changed paths:
A 
LayoutTests/editing/input/mac/writing-suggestions-in-anonymous-renderer-expected.html
A 
LayoutTests/editing/input/mac/writing-suggestions-in-anonymous-renderer.html
M Source/WebCore/rendering/updating/RenderTreeUpdaterGeneratedContent.cpp

  Log Message:
  ---
  [Writing Suggestions] Prediction sometimes appears at the end of the document 
in Mail compose
https://bugs.webkit.org/show_bug.cgi?id=274223
rdar://128109513

Reviewed by Richard Robinson.

Writing suggestions are still sometimes inserted in the wrong place in the 
render tree. This happens
under these conditions:

1.  The text node before the caret selection is inside of an anonymous renderer.
2.  There are one or more renderers that come after the text node's renderer in 
tree order, that are
descendants of the element that contains the text node.

This is one concrete example, wherein an anonymous block-level renderer is 
added to contain a single
text node directly underneath the `body`:

```


 // this is the node before suggestions
* // writing suggestions are supposed to be inserted here

…
* // writing suggestions are inserted here instead
```

To fix this, we simply adjust the logic in `updateWritingSuggestionsRenderer` 
to insert the
generated writing suggestions renderer inside of the text node's parent, such 
that it's always
the next sibling of the text node.

* 
LayoutTests/editing/input/mac/writing-suggestions-in-anonymous-renderer-expected.html:
 Added.
* LayoutTests/editing/input/mac/writing-suggestions-in-anonymous-renderer.html: 
Added.

Add another layout test to exercise this change.

* Source/WebCore/rendering/updating/RenderTreeUpdaterGeneratedContent.cpp:
(WebCore::RenderTreeUpdater::GeneratedContent::updateWritingSuggestionsRenderer):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 5384ee: [iOS] -_dragInteraction:prepareForSession:completi...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 5384ee4f03d2e4233dba92579d53cf168bd97bba
  
https://github.com/WebKit/WebKit/commit/5384ee4f03d2e4233dba92579d53cf168bd97bba
  Author: Wenson Hsieh 
  Date:   2024-05-14 (Tue, 14 May 2024)

  Changed paths:
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm

  Log Message:
  ---
  [iOS] -_dragInteraction:prepareForSession:completion: doesn't call the 
completion block when selecting live text
https://bugs.webkit.org/show_bug.cgi?id=274183

Reviewed by Abrar Protyasha.

Make sure that this completion block is invoked when long pressing on Live Text 
in an image; this
doesn't cause issues in practice since `UIDragInteraction` / 
`BEDragInteraction` internally invokes
the underlying completion handler anyways after a short timeout (500 ms), but 
it's still not great
that we leave the callback dangling for that long.

* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _dragInteraction:prepareForSession:completion:]):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] fc751b: REGRESSION (278562@main): IPCTestingAPI.Serialized...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: fc751b8054efed74b0bb67e95430fc62c5bfd215
  
https://github.com/WebKit/WebKit/commit/fc751b8054efed74b0bb67e95430fc62c5bfd215
  Author: Wenson Hsieh 
  Date:   2024-05-13 (Mon, 13 May 2024)

  Changed paths:
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in

  Log Message:
  ---
  REGRESSION (278562@main): IPCTestingAPI.SerializedTypeInfo is a consistent 
failure
https://bugs.webkit.org/show_bug.cgi?id=274133
rdar://128026967

Reviewed by Aditya Keerthi, Abrar Rahman Protyasha and Tim Horton.

Add `using WebCore::TargetedElementSelectors = …;` to the IPC serialization 
file, so that the
generated IPC testing code treats `TargetedElementSelectors` as a type alias 
instead of a separate
type that requires its own serializer.

Currently, this causes the API test `IPCTestingAPI.SerializedTypeInfo` to fail.

* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:

Drive-by refactoring: also add an alias for `TargetedElementIdentifiers`, and 
use it below for
consistency (and readability).

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 7ee2bb: REGRESSION (268971@main): [ iOS ] TestWebKitAPI.iO...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 7ee2bbe31b7ff81eb609d85ae5030cd12fcd4514
  
https://github.com/WebKit/WebKit/commit/7ee2bbe31b7ff81eb609d85ae5030cd12fcd4514
  Author: Wenson Hsieh 
  Date:   2024-05-11 (Sat, 11 May 2024)

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

  Log Message:
  ---
  REGRESSION (268971@main): [ iOS ] 
TestWebKitAPI.iOSMouseSupport.MouseDidMoveOverElement is a consistent timeout
https://bugs.webkit.org/show_bug.cgi?id=273839
rdar://127691561

Reviewed by Megan Gardner and Richard Robinson.

The changes to `MouseEventTestHarness` in 268971@main made this API test time 
out, but only on iPad.
That's because UIKit adds its own `UIHoverGestureRecognizer` subclasses to 
`WKContentView` on iPad,
which causes the logic in the constructor of `MouseEventTestHarness` to 
initialize
`m_hoverGestureRecognizer` to the wrong gesture. Subsequently, attempts to 
simulate mouse movement
using this gesture recognizer fails to call into `WKMouseInteraction` delegate 
methods.

To fix this, simply adjust this logic to check the name of the gesture 
recognizer (`"WKMouseHover"`)
instead of relying on the class and `allowedTouchTypes`.

* Tools/TestWebKitAPI/Tests/WebKitCocoa/iOSMouseSupport.mm:
(TestWebKitAPI::MouseEventTestHarness::MouseEventTestHarness):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 5e8cbc: [Remote Inspection] Redundant nearby targets shoul...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 5e8cbc9e70f01a95d48990d9328ca7f167714e41
  
https://github.com/WebKit/WebKit/commit/5e8cbc9e70f01a95d48990d9328ca7f167714e41
  Author: Wenson Hsieh 
  Date:   2024-05-09 (Thu, 09 May 2024)

  Changed paths:
M Source/WebCore/page/ElementTargetingController.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/element-targeting-2.html

  Log Message:
  ---
  [Remote Inspection] Redundant nearby targets should not be surfaced to Web 
Inspector
https://bugs.webkit.org/show_bug.cgi?id=273953

Reviewed by Abrar Rahman Protyasha.

Currently, it's possible for the "nearby targets" heuristic to discover 
redundant elements, in the
case where a nearby target is a parent of another. In this case, it makes sense 
to only surface the
parent target. Fix this by implementing an algorithm to filter out such 
elements from the final list
of nearby targets, such that the final list does not contain any target that is 
a child of another
target.

Changes covered by augmenting the API test 
ElementTargeting.NearbyOutOfFlowElements.

* Source/WebCore/page/ElementTargetingController.cpp:
(WebCore::filterRedundantNearbyTargets):
(WebCore::ElementTargetingController::extractTargets):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/element-targeting-2.html:

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] df5bab: [Remote Inspection] Refactor some element selectio...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: df5bab1b42ace04ea660b238da931ea0d75723c5
  
https://github.com/WebKit/WebKit/commit/df5bab1b42ace04ea660b238da931ea0d75723c5
  Author: Wenson Hsieh 
  Date:   2024-05-09 (Thu, 09 May 2024)

  Changed paths:
M Source/WebCore/loader/DocumentLoader.h
M Source/WebCore/page/ElementTargetingController.cpp
M Source/WebCore/page/ElementTargetingController.h
M Source/WebCore/page/ElementTargetingTypes.h
M Source/WebKit/Scripts/webkit/messages.py
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Source/WebKit/Shared/WebsitePoliciesData.h
M Source/WebKit/Shared/WebsitePoliciesData.serialization.in
M Source/WebKit/UIProcess/API/Cocoa/WKWebpagePreferences.mm
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/WebPage.messages.in
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/element-targeting-7.html

  Log Message:
  ---
  [Remote Inspection] Refactor some element selection heuristics
https://bugs.webkit.org/show_bug.cgi?id=273914
rdar://127633767

Reviewed by Aditya Keerthi.

Refactor some logic for finding elements in Web Inspector using Develop > Start 
Element Selection,
and when right clicking on an element in the tree view and selecting `Toggle 
Visibility`.

* Source/WebCore/loader/DocumentLoader.h:
(WebCore::DocumentLoader::visibilityAdjustmentSelectors const):
(WebCore::DocumentLoader::setVisibilityAdjustmentSelectors):
* Source/WebCore/page/ElementTargetingController.cpp:
(WebCore::ElementTargetingController::extractTargets):

Adjust this to avoid surfacing nearby elements that are already children of a 
targeted element,
since they're redundant.

(WebCore::ElementTargetingController::adjustVisibility):

Make this take a list of `TargetedElementAdjustment` structs, each of which 
contains a pair of IDs
that represents the targeted element, as well as selectors corresponding to 
that element.

(WebCore::ElementTargetingController::adjustVisibilityInRepeatedlyTargetedRegions):

Hoist code to initialize `m_visibilityAdjustmentSelectors` into the call site 
here, and also add
logic to schedule a timer to periodically check the list of selectors ~once per 
second, 10 seconds
after page load.

(WebCore::ElementTargetingController::applyVisibilityAdjustmentFromSelectors):

Rename `m_remainingVisibilityAdjustmentSelectors` to just 
`m_visibilityAdjustmentSelectors`, and
change how it works. Instead of removing matched elements from this set and 
clearing the whole set
after a 30 seconds, keep the members of this set intact over the course of page 
load. Accumulate
more entries in this list when toggling element visibility using 
`adjustVisibility` below.

(WebCore::ElementTargetingController::reset):
(WebCore::ElementTargetingController::resetVisibilityAdjustments):
(WebCore::ElementTargetingController::selectorBasedVisibilityAdjustmentTimerFired):
* Source/WebCore/page/ElementTargetingController.h:
* Source/WebCore/page/ElementTargetingTypes.h:

Add and deploy some type aliases to make these nested templated types easier to 
read.

* Source/WebKit/Scripts/webkit/messages.py:
(headers_for_type):
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
* Source/WebKit/Shared/WebsitePoliciesData.h:
* Source/WebKit/Shared/WebsitePoliciesData.serialization.in:
* Source/WebKit/UIProcess/API/Cocoa/WKWebpagePreferences.mm:
(-[WKWebpagePreferences 
_setVisibilityAdjustmentSelectorsIncludingShadowHosts:]):

Deploy the type aliases above in more places.

* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::resetVisibilityAdjustmentsForTargetedElements):
(WebKit::WebPageProxy::adjustVisibilityForTargetedElements):
(WebKit::extractIdentifiers): Deleted.
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::adjustVisibilityForTargetedElements):
(WebKit::WebPage::resetVisibilityAdjustmentsForTargetedElements):
* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Source/WebKit/WebProcess/WebPage/WebPage.messages.in:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm:
(TestWebKitAPI::TEST(ElementTargeting, AdjustVisibilityAfterRecreatingElement)):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/element-targeting-7.html:

Add an API test to exercise the change.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 98754f: [Quirk] iPadOS: Unable to enter PIN in account lin...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 98754fdd832d03f1de253d1372d1f1963704473a
  
https://github.com/WebKit/WebKit/commit/98754fdd832d03f1de253d1372d1f1963704473a
  Author: Wenson Hsieh 
  Date:   2024-05-07 (Tue, 07 May 2024)

  Changed paths:
M Source/WebCore/page/Quirks.cpp
M Source/WebCore/page/Quirks.h
M Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm

  Log Message:
  ---
  [Quirk] iPadOS: Unable to enter PIN in account linking flow on shopee.sg
https://bugs.webkit.org/show_bug.cgi?id=273864
rdar://127031587

Reviewed by Tim Horton.

Add a quirk to use an *iPhone* user agent on 
`shopee.sg/payment/account-linking/landing`. Currently,
sending either macOS or (non-desktop-class) iPad user agents cause Shopee to 
load content that
doesn't work unless the user has a hardware keyboard; namely, the PIN input 
elements don't actually
use focusable elements at all, and instead rely on receiving hardware keyboard 
events.

Work around this for now with a site-specific quirk to load an iPhone user 
agent in this specific
landing page; while the layout doesn't fit very well for an iPad screen, it's 
at least functional.

* Source/WebCore/page/Quirks.cpp:
(WebCore::Quirks::needsIPadMiniUserAgent):
(WebCore::Quirks::needsIPhoneUserAgent):
(WebCore::Quirks::needsIpadMiniUserAgent): Deleted.
* Source/WebCore/page/Quirks.h:
* Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm:
(WebKit::desktopClassBrowsingRecommendedForRequest):
(WebKit::WebPageProxy::effectiveContentModeAfterAdjustingPolicies):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] d11015: [iOS] ElementTargeting.ReplacedRendererSizeIgnores...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: d110152c9e76310103dc843da0fdd5b892f19080
  
https://github.com/WebKit/WebKit/commit/d110152c9e76310103dc843da0fdd5b892f19080
  Author: Wenson Hsieh 
  Date:   2024-05-07 (Tue, 07 May 2024)

  Changed paths:
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm
M Tools/TestWebKitAPI/cocoa/TestWKWebView.h
M Tools/TestWebKitAPI/cocoa/TestWKWebView.mm

  Log Message:
  ---
  [iOS] ElementTargeting.ReplacedRendererSizeIgnoresPageScaleAndZoom is a flaky 
failure
https://bugs.webkit.org/show_bug.cgi?id=273856

Reviewed by Aditya Keerthi.

This test was previously relying on the fact that `-setZoomScale:animated:` 
after navigation would
(usually) not actually result in a scale change, after the next rendering 
update. As such, this test
only passes because the point `(100, 100)` ends up hit-testing to the same 
inspected element.

This bug was fixed in 278484@main, but as a result, it exposes a bug in the 
test, since
`-setZoomScale:animated:` uses the center of the scroll view as the anchor 
point (rather than the
origin), which means that hit-testing `(100, 100)` now misses and hits text 
instead.

Address this by using `-setZoomScale:animated:` and `-setContentOffset:` to 
zoom to scale 3 and
scroll to the origin, and then carry out the hit-test.

* Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm:
(TestWebKitAPI::TEST(ElementTargeting, 
ReplacedRendererSizeIgnoresPageScaleAndZoom)):
* Tools/TestWebKitAPI/cocoa/TestWKWebView.h:
* Tools/TestWebKitAPI/cocoa/TestWKWebView.mm:
(-[TestWKWebView waitForNextPresentationUpdate]):
(-[TestWKWebView waitForNextVisibleContentRectUpdate]):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 753422: TestWebKitAPI.ScrollViewScrollabilityTests.Scrolla...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 7534227e0513ca35a96d0667791cdc70eb5b4751
  
https://github.com/WebKit/WebKit/commit/7534227e0513ca35a96d0667791cdc70eb5b4751
  Author: Wenson Hsieh 
  Date:   2024-05-07 (Tue, 07 May 2024)

  Changed paths:
M Source/WebKit/Scripts/webkit/messages.py
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/UIProcess/WebPageProxy.messages.in
M Source/WebKit/WebProcess/WebCoreSupport/WebLocalFrameLoaderClient.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h

  Log Message:
  ---
  
TestWebKitAPI.ScrollViewScrollabilityTests.ScrollableWithOverflowHiddenWhenZoomed
 fails on iOS Simulator
https://bugs.webkit.org/show_bug.cgi?id=273738
rdar://127547621

Reviewed by Simon Fraser and Abrar Protyasha.

After the changes in 276962@main, this iOS API test began failing. This test 
works by setting the
`WKScrollView`'s `zoomScale` immediately after page load to 1.5, and verifying 
that the scroll view
is scrollable, on account of the scale being greater than 1.

Since we now schedule a full rendering update when completing a page transition 
after document load,
this now introduces a race. Consider the following sequence of events:

1. (UI) Scroll view zoom scale is set to 1.5, which schedules a visible 
content rect update.

2. (WEB)Remote layer tree commit (triggered by completing page transition) 
is sent, as a result
of scheduling an editor state update. The `pageScaleFactor` in the 
transaction is 1.0.

3. (WEB)Visible content rect update arrives, setting the page scale factor 
to 1.5.

4. (UI) Remote layer tree commit arrives, updating the scroll view's zoom 
scale to 1.0. This
schedules another visible content rect update, with a zoom scale of 
1.0.

5. (WEB)Second visible content rect update arrives, reverting page scale 
factor to 1.0.

This leaves us in a state where calling `-setZoomScale:animated:` was 
essentially a no-op. To avoid
this race, we replace the scheduled editor state update (which triggers a layer 
flush) with a
separate, dedicated IPC message to clear out the `EditorState` during page 
transition. This also
helps prevent an otherwise-unnecessary layer tree flush immediately after page 
load.

* Source/WebKit/Scripts/webkit/messages.py:
(types_that_cannot_be_forward_declared):
(headers_for_type):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::clearEditorStateAfterPageTransition):
* Source/WebKit/UIProcess/WebPageProxy.h:
* Source/WebKit/UIProcess/WebPageProxy.messages.in:

Add a new IPC message to clear the editor state. Note that this only needs to 
propagate a single
`EditorState` ID, to ensure deterministic ordering in the case where:

1.  A remote layer tree commit containing an `EditorState` is computed (but not 
yet sent, since that
happens on a background thread).

2.  Page transition completes, which now sends a message to clear out the 
`EditorState`.

3.  The commit in (1) is sent.

...in this case, the updated editor state in the UI process should actually be 
empty (none),
reflecting the chronological order in which the `EditorState` was computed in 
the web process.

* Source/WebKit/WebProcess/WebCoreSupport/WebLocalFrameLoaderClient.cpp:
(WebKit::WebLocalFrameLoaderClient::transitionToCommittedForNewPage):
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::clearEditorStateAfterPageTransition):
* Source/WebKit/WebProcess/WebPage/WebPage.h:

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] c3c0e1: TestWebKitAPI.SelectionTests.SelectedTextAfterSele...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: c3c0e1ac6fcd3cba58290cc52688b4ac0dedc098
  
https://github.com/WebKit/WebKit/commit/c3c0e1ac6fcd3cba58290cc52688b4ac0dedc098
  Author: Wenson Hsieh 
  Date:   2024-05-06 (Mon, 06 May 2024)

  Changed paths:
M Tools/TestWebKitAPI/Tests/ios/SelectionByWord.mm

  Log Message:
  ---
  TestWebKitAPI.SelectionTests.SelectedTextAfterSelectingWordForReplacement 
times out on iPhone Simulator
https://bugs.webkit.org/show_bug.cgi?id=273736
rdar://127547635

Reviewed by Abrar Rahman Protyasha.

Augment the `SelectionChangeListener` helper class to be compatible with the 
case where WebKit uses
BrowserEngineKit's `BETextInput`. Instead of calling directly into 
`-selection(Will|Did)Change:`,
we now call into `-[BETextInputDelegate 
selection(Will|Did)ChangeForTextInput:]`.

* Tools/TestWebKitAPI/Tests/ios/SelectionByWord.mm:
(-[SelectionChangeListener selectionWillChangeForTextInput:]):
(-[SelectionChangeListener selectionDidChangeForTextInput:]):
(-[SelectionChangeListener 
shouldDeferEventHandlingToSystemForTextInput:context:]):
(-[SelectionChangeListener textInput:setCandidateSuggestions:]):
(-[SelectionChangeListener textInput:deferReplaceTextActionToSystem:]):
(-[SelectionChangeListener invalidateTextEntryContextForTextInput:]):
(TEST(SelectionTests, SelectedTextAfterSelectingWordForReplacement)):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] a03f43: TestWebKitAPI.KeyboardInputTests.EditableWebViewRe...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: a03f439c11675760e68b40b59fabfd4be3727c37
  
https://github.com/WebKit/WebKit/commit/a03f439c11675760e68b40b59fabfd4be3727c37
  Author: Wenson Hsieh 
  Date:   2024-05-06 (Mon, 06 May 2024)

  Changed paths:
M Tools/TestRunnerShared/spi/UIKitSPIForTesting.h
M Tools/TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm

  Log Message:
  ---
  
TestWebKitAPI.KeyboardInputTests.EditableWebViewRequiresKeyboardWhenFirstResponder
 fails on iPhone Simulator
https://bugs.webkit.org/show_bug.cgi?id=273737
rdar://127547640

Reviewed by Abrar Rahman Protyasha and Megan Gardner.

Prior to BrowserEngineKit adoption, WebKit would use UIKit SPI 
(`-[UIPressesEvent _hidEvent]`) to
keep track of when a hardware keyboard key is pressed; when observed, we'd then 
set a boolean flag,
`_seenHardwareKeyDownInNonEditableElement`, which allows us to then return YES 
from
`-_requiresKeyboardWhenFirstResponder`. This is crucial for key event 
compatibility, in the case
where the web page listens for key events outside of the context of editing, 
and the user is using a
hardware keyboard on iOS (and can therefore dispatch keyboard events without 
the help of a software
keyboard).

With BrowserEngineKit adoption, we no longer rely on the aforementioned SPI; 
UIKit instead
automatically returns `YES`, as long as `-hardwareKeyboardAttached` is set. 
However, because this is
set by default when running tests in the iOS simulator, 
`-_requiresKeyboardWhenFirstResponder` now
returns `YES` right after loading the test markup.

Account for this change in the test by swizzling out 
`-hardwareKeyboardAttached` to simulate the
keyboard being detached, when running this test.

* Tools/TestRunnerShared/spi/UIKitSPIForTesting.h:
* Tools/TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm:
(TestWebKitAPI::overrideHardwareKeyboardAttached):
(TestWebKitAPI::TEST(KeyboardInputTests, 
EditableWebViewRequiresKeyboardWhenFirstResponder)):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 5d8844: TestWebKitAPI.WKScrollViewTests.AsynchronousWheelE...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 5d8844437faecf993b1c4e0e9ebd4413a20f71ea
  
https://github.com/WebKit/WebKit/commit/5d8844437faecf993b1c4e0e9ebd4413a20f71ea
  Author: Wenson Hsieh 
  Date:   2024-05-06 (Mon, 06 May 2024)

  Changed paths:
M Tools/TestRunnerShared/spi/UIKitSPIForTesting.h
M Tools/TestWebKitAPI/Tests/ios/WKScrollViewTests.mm

  Log Message:
  ---
  TestWebKitAPI.WKScrollViewTests.AsynchronousWheelEventHandling fails on iOS 
Simulator
https://bugs.webkit.org/show_bug.cgi?id=273739
rdar://127547694

Reviewed by Abrar Rahman Protyasha and Aditya Keerthi.

The initializer `-[BEScrollViewScrollUpdate initWithScrollEvent:phase:]` is 
marked `NS_DIRECT` in
BrowserEngineKit, so attempts to initialize a scroll update for testing fail 
due to invoking an
unrecognized selector (in 273582@main, I'd previously been testing against a 
local debug build of
BrowserEngineKit that did not inline this initializer, so the test was passing 
as expected).

Fix this by adjusting the testing strategy, so that we instead initialize a 
mock Objective-C object
(`WKTestScrollViewScrollUpdate`) which implements identical functionality.

* Tools/TestWebKitAPI/Tests/ios/WKScrollViewTests.mm:
(-[WKTestScrollViewScrollUpdate initWithScrollEvent:phase:]):
(-[WKTestScrollViewScrollUpdate phase]):
(-[WKTestScrollViewScrollUpdate timestamp]):
(-[WKTestScrollViewScrollUpdate locationInView:]):
(-[WKTestScrollViewScrollUpdate translationInView:]):
(createScrollUpdate):
(TEST(WKScrollViewTests, AsynchronousWheelEventHandling)):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 6cd1f4: Letters disappear randomly while typing in Stash w...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 6cd1f4e75e31195246920f7fba52d3003fe08e9d
  
https://github.com/WebKit/WebKit/commit/6cd1f4e75e31195246920f7fba52d3003fe08e9d
  Author: Wenson Hsieh 
  Date:   2024-05-06 (Mon, 06 May 2024)

  Changed paths:
A 
LayoutTests/editing/input/mac/do-not-allow-inline-predictions-if-text-changes-expected-mismatch.html
A 
LayoutTests/editing/input/mac/do-not-allow-inline-predictions-if-text-changes.html
M LayoutTests/platform/mac-wk2/TestExpectations
M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
M Source/WebCore/editing/Editor.h
M Source/WebCore/editing/VisibleSelection.cpp
M Source/WebKit/UIProcess/API/mac/WKWebViewPrivateForTestingMac.h
M Source/WebKit/UIProcess/API/mac/WKWebViewTestingMac.mm
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Source/WebKit/UIProcess/mac/WebViewImpl.h
M Source/WebKit/UIProcess/mac/WebViewImpl.mm
M Source/WebKit/WebProcess/WebPage/Cocoa/WebPageCocoa.mm
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm
M Source/WebKit/WebProcess/WebPage/mac/WebPageMac.mm
M Tools/WebKitTestRunner/mac/UIScriptControllerMac.mm

  Log Message:
  ---
  Letters disappear randomly while typing in Stash when writing suggestions are 
enabled
https://bugs.webkit.org/show_bug.cgi?id=273748
rdar://127392270

Reviewed by Richard Robinson.

Stash's JavaScript listens for `keydown` events and, in response, replaces text 
nodes right before
the selection in the editable container when writing comments. This interferes 
with both current
implementations of writing suggestions (i.e. inline predictions), which depend 
on the text node
before the user's selection being the same, as the user types.

We can detect this case by computing and remembering the last node before the 
user's selection after
each editing keyboard event (where writing suggestions would normally be 
inserted). If this text
node changes in between the last key event and when sending the next editor 
state after changing the
selection, then don't allow writing suggestions.

* 
LayoutTests/editing/input/mac/do-not-allow-inline-predictions-if-text-changes-expected-mismatch.html:
 Added.
* 
LayoutTests/editing/input/mac/do-not-allow-inline-predictions-if-text-changes.html:
 Added.

Add a layout test to exercise the new heuristic.

* LayoutTests/platform/mac-wk2/TestExpectations:
* Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml:

Remove the internal `InlinePredictionsInAllEditableElementsEnabled` setting. 
This was only used to
test writing suggestions on the web, before enabling it by default.

* Source/WebCore/editing/Editor.h:
* Source/WebCore/editing/VisibleSelection.cpp:
(WebCore::VisibleSelection::canEnableWritingSuggestions const):

Make the `writingsuggestions` state in editable elements follow the enclosing 
text form control, if
applicable. This is needed to keep 
`WritingSuggestionsWebAPI.DefaultStateWithDisabledAutocomplete`
passing after the change to consult `EditorState` in `-[WKContentView 
_updateTextInputTraits:]`, now
that we don't solely depend on the initial focused element information.

* Source/WebKit/UIProcess/API/mac/WKWebViewPrivateForTestingMac.h:
* Source/WebKit/UIProcess/API/mac/WKWebViewTestingMac.mm:
(-[WKWebView _allowsInlinePredictions]):
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _updateTextInputTraits:]):

Make the iOS codepath honor editor state's writing suggestions enablement flag 
(which may change on
the fly, unlike focused element information).

* Source/WebKit/UIProcess/mac/WebViewImpl.h:
* Source/WebKit/UIProcess/mac/WebViewImpl.mm:
(WebKit::WebViewImpl::allowsInlinePredictions const):

Remove logic to honor the (now-removed) internal feature flag, and simplify the 
logic a bit.

* Source/WebKit/WebProcess/WebPage/Cocoa/WebPageCocoa.mm:
(WebKit::WebPage::getPlatformEditorStateCommon const):

Consult `m_lastNodeBeforeWritingSuggestions` when computing 
`canEnableWritingSuggestions` on the
`EditorState`'s post-layout data. If the current node has changed since the 
last key event, avoid
trying to compute and inject writing suggestions.

* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::didCommitLoad):

Reset `m_lastNodeBeforeWritingSuggestions`.

(WebKit::WebPage::updateLastNodeBeforeWritingSuggestions):

Add a helper method to update `m_lastNodeBeforeWritingSuggestions` after a 
`keydown`.

* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::handleEditingKeyboardEvent):
* Source/WebKit/WebProcess/WebPage/mac/WebPageMac.mm:
(WebKit::WebPage::handleEditingKeyboardEvent):

Call the helper method above when handling keyboard editing.

* Tools/WebKitTestRunner/mac/UIScriptControllerMac.mm:
(WTR::UIScriptControllerMac

[webkit-changes] [WebKit/WebKit] 04fce8: Refactor logic for muting autoplaying video elemen...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 04fce867503f4cab34c98b03c5b5c117dd914767
  
https://github.com/WebKit/WebKit/commit/04fce867503f4cab34c98b03c5b5c117dd914767
  Author: Wenson Hsieh 
  Date:   2024-05-03 (Fri, 03 May 2024)

  Changed paths:
A LayoutTests/fast/element-targeting/target-video-in-subframe-expected.txt
A LayoutTests/fast/element-targeting/target-video-in-subframe.html
M LayoutTests/resources/ui-helper.js
M Source/WebCore/dom/Document.cpp
M Source/WebCore/dom/Document.h
M Source/WebCore/dom/Element.cpp
M Source/WebCore/dom/Element.h
M Source/WebCore/html/HTMLMediaElement.cpp
M Source/WebCore/html/HTMLMediaElement.h
M Source/WebCore/page/ElementTargetingController.cpp
M Source/WebCore/page/ElementTargetingController.h
M Source/WebCore/page/ElementTargetingTypes.h
M Source/WebCore/page/MediaProducer.h
M Source/WebCore/page/Page.cpp
M Source/WebCore/page/Page.h
M Source/WebCore/testing/Internals.cpp
M Source/WebCore/testing/Internals.h
M Source/WebCore/testing/Internals.idl
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Source/WebKit/UIProcess/API/APITargetedElementInfo.h
M Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementInfo.h
M Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementInfo.mm
M Tools/TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl
M Tools/TestRunnerShared/UIScriptContext/UIScriptController.h
M Tools/WebKitTestRunner/cocoa/UIScriptControllerCocoa.h
M Tools/WebKitTestRunner/cocoa/UIScriptControllerCocoa.mm

  Log Message:
  ---
  Refactor logic for muting autoplaying video elements in background tabs
https://bugs.webkit.org/show_bug.cgi?id=273633
rdar://125859510

Reviewed by Aditya Keerthi.

Refactor some logic related to muting media elements. See below for more 
details.

* LayoutTests/fast/element-targeting/target-video-in-subframe-expected.txt: 
Added.
* LayoutTests/fast/element-targeting/target-video-in-subframe.html: Added.
* LayoutTests/resources/ui-helper.js:
(window.UIHelper.resetVisibilityAdjustments):
(window.UIHelper):

Add a new layout test (and testing hooks) to exercise the change.

* Source/WebCore/dom/Document.cpp:
(WebCore::Document::visibilityAdjustmentStateDidChange):

Add plumbing to propagate visibility state change to all audio producers.

* Source/WebCore/dom/Document.h:
* Source/WebCore/dom/Element.cpp:
(WebCore::Element::setVisibilityAdjustment):

Set a flag on `Page` to indicate that we've applied visibility adjustment to at 
least one element
before. Used in `isInVisibilityAdjustmentSubtree()` below to exit right away, 
in the common case
where there has never been visibility adjustment.

(WebCore::Element::isInVisibilityAdjustmentSubtree const):

Add a helper method to compute whether or not the element is inside of a 
visibility adjustment
subtree, by traversing ancestors in the DOM.

* Source/WebCore/dom/Element.h:
* Source/WebCore/html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::didFinishInsertingNode):
(WebCore::HTMLMediaElement::removedFromAncestor):
(WebCore::HTMLMediaElement::visibilityAdjustmentStateDidChange):

Recompute and cache the visibility adjustment subtree state whenever the media 
element is
unparented, re-parented, or visibility state otherwise changes.

(WebCore::HTMLMediaElement::effectiveMuted const):

Consult the cached state flag that's updated above when determining whether the 
media element should
be `effectivelyMuted()`.

* Source/WebCore/html/HTMLMediaElement.h:
* Source/WebCore/page/ElementTargetingController.cpp:
(WebCore::hasAudibleMedia):
(WebCore::targetedElementInfo):

Add support for a `hasAudibleMedia` flag on targeted element info.

(WebCore::findOnlyMainElement):
(WebCore::isNavigationalElement):
(WebCore::containsNavigationalElement):

Drive-by fix: mark the arguments to a few helper functions as `const`.

(WebCore::ElementTargetingController::adjustVisibility):
(WebCore::ElementTargetingController::adjustVisibilityInRepeatedlyTargetedRegions):
(WebCore::ElementTargetingController::resetVisibilityAdjustments):
(WebCore::ElementTargetingController::dispatchVisibilityAdjustmentStateDidChange):
* Source/WebCore/page/ElementTargetingController.h:
* Source/WebCore/page/ElementTargetingTypes.h:
* Source/WebCore/page/MediaProducer.h:
(WebCore::MediaProducer::visibilityAdjustmentStateDidChange):

Add a new delegate hook to inform media producers when visibility state 
changes. Currently, this is
only implemented by `HTMLMediaElement`, which allows it to adjust whether or 
not the underlying
media player should be muted, through `effectiveMuted()`.

* Source/WebCore/page/Page.cpp:
(WebCore::Page::didCommitLoad):
* Source/WebCore/page/Page.h:

Add a boolean flag to track whether or not there has ever been any visibility 
adjustment in the
page (this bit is cleared out in `didCommitLoad` above).

(WebCore::Page

[webkit-changes] [WebKit/WebKit] 57c030: [Remote Inspection] Add a way for clients to contr...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 57c0300c572968342e81b3aeea68b98462b0315a
  
https://github.com/WebKit/WebKit/commit/57c0300c572968342e81b3aeea68b98462b0315a
  Author: Wenson Hsieh 
  Date:   2024-04-30 (Tue, 30 Apr 2024)

  Changed paths:
M Source/WebCore/page/ElementTargetingController.cpp
M Source/WebCore/page/ElementTargetingController.h
M Source/WebCore/page/ElementTargetingTypes.h
M Source/WebKit/CMakeLists.txt
M Source/WebKit/DerivedSources-input.xcfilelist
M Source/WebKit/DerivedSources.make
M Source/WebKit/Shared/API/APIObject.h
M Source/WebKit/Shared/Cocoa/APIObject.mm
R Source/WebKit/Shared/FontInfo.h
R Source/WebKit/Shared/FontInfo.serialization.in
A Source/WebKit/Shared/PlatformFontInfo.h
A Source/WebKit/Shared/PlatformFontInfo.serialization.in
M Source/WebKit/Shared/PlatformPopupMenuData.h
M Source/WebKit/Shared/PlatformPopupMenuData.serialization.in
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Source/WebKit/Sources.txt
A Source/WebKit/UIProcess/API/APITargetedElementRequest.cpp
A Source/WebKit/UIProcess/API/APITargetedElementRequest.h
M Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm
M Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementRequest.h
M Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementRequest.mm
A Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementRequestInternal.h
M Source/WebKit/UIProcess/PageClient.h
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/UIProcess/ios/PageClientImplIOS.h
M Source/WebKit/UIProcess/ios/PageClientImplIOS.mm
M Source/WebKit/UIProcess/mac/WebPageProxyMac.mm
M Source/WebKit/UIProcess/mac/WebViewImpl.mm
M Source/WebKit/WebKit.xcodeproj/project.pbxproj
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/mac/WebPageMac.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm

  Log Message:
  ---
  [Remote Inspection] Add a way for clients to control whether to ignore or 
honor pointer-events: none;
https://bugs.webkit.org/show_bug.cgi?id=273458
rdar://126302333

Reviewed by Tim Horton.

Add support for a `-[_WKTargetedElementRequest shouldIgnorePointerEventsNone]` 
property that can be
used by clients to determine whether or not `pointer-events: none;` should be 
accounted for, when
hit-testing to find targets.

This PR also refactors `_WKTargetedElementRequest` so that it's built on top of 
a proper WebKit API
object (instead of bridging directly into the WebCore struct in ObjC code). I 
originally just kept
the bridging between `_WKTargetedElementRequest` and 
`WebCore::TargetedElementRequest` in platform
code because it was just a trivial wrapper around a single `FloatPoint`. 
However, since it is
beginning to accumulate more complexity, it makes more sense to pull it out 
into its own
`API::Object` type so that the platform-specific code is kept to a minimum (and 
other ports could
more easily take advantage of this infrastructure in the future).

See below for more details.

Test: ElementTargeting.DoNotIgnorePointerEventsNone

* Source/WebCore/page/ElementTargetingController.cpp:
(WebCore::ElementTargetingController::findTargets):
(WebCore::ElementTargetingController::findNodes):

Add support for the new boolean option by adding (or omitting) the 
corresponding hit-test type.

* Source/WebCore/page/ElementTargetingController.h:
* Source/WebCore/page/ElementTargetingTypes.h:
* Source/WebKit/CMakeLists.txt:
* Source/WebKit/DerivedSources-input.xcfilelist:
* Source/WebKit/DerivedSources.make:
* Source/WebKit/Shared/API/APIObject.h:
* Source/WebKit/Shared/Cocoa/APIObject.mm:

Add the new API object type, and related boilerplate.

(API::Object::newObject):
* Source/WebKit/Shared/PlatformFontInfo.h: Copied from 
Source/WebKit/Shared/FontInfo.h.
* Source/WebKit/Shared/PlatformFontInfo.serialization.in: Renamed from 
Source/WebKit/Shared/FontInfo.serialization.in.

Rename the `FontInfo` struct to `PlatformFontInfo`, to avoid a name collision 
between our struct and
the name of a struct in the global namespace, in `QuickDraw.h`:

```
/Users/whsieh/Build/Release/DerivedSources/WebKit/GeneratedSerializers.h:2198:8:
 note: candidate found by name lookup is 'WebKit::FontInfo'
 2198 | struct FontInfo;
```

vs:

```
In file included from 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/…/System/Library/Frameworks/ApplicationServices.framework/Frameworks/HIServices.framework/Headers/HIServices.h:26:
In file included from 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/…/System/Library/Frameworks/ApplicationServices.framework/Frameworks/HIServices.framework/Headers/HIShape.h:22:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/…/System/Library/Frameworks

[webkit-changes] [WebKit/WebKit] ebc755: [iOS] Rebaseline several pasteboard-related layout...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: ebc755bc85449255bef9b771927f073adb8eac9f
  
https://github.com/WebKit/WebKit/commit/ebc755bc85449255bef9b771927f073adb8eac9f
  Author: Wenson Hsieh 
  Date:   2024-04-28 (Sun, 28 Apr 2024)

  Changed paths:
M LayoutTests/editing/async-clipboard/clipboard-write-basic-expected.txt
M LayoutTests/editing/async-clipboard/clipboard-write-basic.html
M 
LayoutTests/editing/async-clipboard/sanitize-when-reading-markup-expected.txt
M LayoutTests/editing/async-clipboard/sanitize-when-reading-markup.html
M 
LayoutTests/editing/pasteboard/data-transfer-set-data-sanitize-url-when-copying-in-null-origin-expected.txt
M 
LayoutTests/editing/pasteboard/data-transfer-set-data-sanitize-url-when-copying-in-null-origin.html
M 
LayoutTests/editing/pasteboard/data-transfer-set-data-sanitizes-html-when-copying-expected.txt
M 
LayoutTests/editing/pasteboard/data-transfer-set-data-sanitizes-html-when-copying-in-null-origin-expected.txt
M 
LayoutTests/editing/pasteboard/data-transfer-set-data-sanitizes-html-when-copying-in-null-origin.html
M 
LayoutTests/editing/pasteboard/data-transfer-set-data-sanitizes-html-when-copying.html
M LayoutTests/platform/ios/TestExpectations

  Log Message:
  ---
  [iOS] Rebaseline several pasteboard-related layout tests
https://bugs.webkit.org/show_bug.cgi?id=273378
rdar://12441

Reviewed by Richard Robinson.

Rebaseline several layout tests in `editing/async-clipboard` and 
`editing/pasteboard` after system
changes (in UIKit). In iOS 17.4+, UIKit now automatically publishes 
`public.utf8-plain-text` on the
pasteboard as long as `public.html` is written.

The value of the plain text type is either a value explicitly written to the 
pasteboard, or (if no
value was specified) the text content of a document derived from loading the 
HTML data (by using
UIFoundation). As such, we make these tests pass in both cases where the system 
does (or doesn't)
automatically write plain text on behalf of the pasteboard client when HTML 
data is written.

* LayoutTests/editing/async-clipboard/clipboard-write-basic-expected.txt:
* LayoutTests/editing/async-clipboard/clipboard-write-basic.html:
* LayoutTests/editing/async-clipboard/sanitize-when-reading-markup-expected.txt:
* LayoutTests/editing/async-clipboard/sanitize-when-reading-markup.html:
* 
LayoutTests/editing/pasteboard/data-transfer-set-data-sanitize-url-when-copying-in-null-origin-expected.txt:
* 
LayoutTests/editing/pasteboard/data-transfer-set-data-sanitize-url-when-copying-in-null-origin.html:
* 
LayoutTests/editing/pasteboard/data-transfer-set-data-sanitizes-html-when-copying-expected.txt:
* 
LayoutTests/editing/pasteboard/data-transfer-set-data-sanitizes-html-when-copying-in-null-origin-expected.txt:
* 
LayoutTests/editing/pasteboard/data-transfer-set-data-sanitizes-html-when-copying-in-null-origin.html:
* 
LayoutTests/editing/pasteboard/data-transfer-set-data-sanitizes-html-when-copying.html:
* LayoutTests/platform/ios/TestExpectations:

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] edca53: [Remote Inspection] Add the ability to search for ...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: edca530205c5e76991b0cf709322fb121f8b575d
  
https://github.com/WebKit/WebKit/commit/edca530205c5e76991b0cf709322fb121f8b575d
  Author: Wenson Hsieh 
  Date:   2024-04-25 (Thu, 25 Apr 2024)

  Changed paths:
M Source/WebCore/page/ElementTargetingController.cpp
M Source/WebCore/page/ElementTargetingController.h
M Source/WebCore/page/ElementTargetingTypes.h
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Source/WebKit/UIProcess/API/APITargetedElementInfo.h
M Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm
M Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementInfo.h
M Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementInfo.mm
M Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementRequest.h
M Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementRequest.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/element-targeting-7.html
M Tools/WebKitTestRunner/cocoa/UIScriptControllerCocoa.mm

  Log Message:
  ---
  [Remote Inspection] Add the ability to search for target elements by text
https://bugs.webkit.org/show_bug.cgi?id=273222
rdar://126991300

Reviewed by Abrar Protyasha and Aditya Keerthi.

Add support for:

1.  A `-searchableText` property on `_WKTargetedElementInfo`, which exposes the 
first 100 characters
of the longest contiguous text run in the targeted element.

2.  A way to initialize `_WKTargetedElementRequest` with a `searchText` string 
instead of a `point`,
which retrieves a targeted element by searching in the document (and 
recursively in any
subframes) for the first range that matches the text.

See below for more details.

* Source/WebCore/page/ElementTargetingController.cpp:
(WebCore::collectDocumentElementsFromChildFrames):
(WebCore::searchableTextForTarget):
(WebCore::targetedElementInfo):
(WebCore::ElementTargetingController::findTargets):
(WebCore::ElementTargetingController::findNodes):

Refactor the element targeting logic to work with both hit-testing (based on a 
point in root view
space) or text search (based on a search string). To do this, we split the 
logic out into two parts:

1.  The first part computes a list of potential candidates 
(`Vector>`), using one of two
strategies: hit-testing or text search.

2.  The second part takes the list of potential candiates from (1) and resolves 
the final list of
targeted elements.

The new text search codepath hooks into the existing targeting code by 
searching the DOM for ranges
that match the given text and surfacing the ancestor chain as potential 
candidates, which the rest
of the targeting heuristic pipeline consumes.

(WebCore::searchForElementContainingText):
(WebCore::ElementTargetingController::extractTargets):
* Source/WebCore/page/ElementTargetingController.h:
* Source/WebCore/page/ElementTargetingTypes.h:
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:

Back `TargetedElementRequest` with a variant of `FloatPoint, String` instead of 
just a `FloatPoint`.
The `FloatPoint` represents a hit-testing location in root view coordinates, 
while the `String`
represents a search string.

* Source/WebKit/UIProcess/API/APITargetedElementInfo.h:
* Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView _requestTargetedElementInfo:completionHandler:]):
* Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementInfo.h:
* Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementInfo.mm:
(-[_WKTargetedElementInfo searchableText]):
(-[_WKTargetedElementInfo isNearbyTarget]):
(-[_WKTargetedElementInfo isUnderPoint]): Deleted.

Rename this property to `isNearbyTarget`, since `isUnderPoint` doesn't make 
sense in the case where
the targeted element was requested via text search.

* Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementRequest.h:
* Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementRequest.mm:
(-[_WKTargetedElementRequest initWithSearchText:]):
(-[_WKTargetedElementRequest initWithPoint:]):
(-[_WKTargetedElementRequest searchText]):
(-[_WKTargetedElementRequest init]): Deleted.

Instead of having clients use `-init` and then set a point on the request, we 
add initializer
methods to take either a string (for the search text) or a point in web view 
coordinates, and then
expose the point or search text as readonly properties only. (For now, we need 
to keep exposing
`-setPoint:` for source compatibility, but this should become readonly shortly).

* Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm:
(-[WKWebView _targetedElementInfo:]):
(-[WKWebView targetedElementInfoAt:]):
(-[WKWebView targetedElementInfoWithText:]):
(TestWebKitAPI::TEST(ElementTargeting, NearbyOutOfFlowElements)):
(TestWebKitAPI::TEST(ElementTargeting, 
RequestTargetedElementsBySearchableText)):

Add a new API test to exercise both SPIs.

* Tools/TestWebKitAPI/Tests/WebKitCocoa/element-targeting-7.html:
* To

[webkit-changes] [WebKit/WebKit] 048d68: [Remote Inspection] Element targeting should try :...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 048d68a2ee2a1517b2f8bc4006b5d73ebb22c159
  
https://github.com/WebKit/WebKit/commit/048d68a2ee2a1517b2f8bc4006b5d73ebb22c159
  Author: Wenson Hsieh 
  Date:   2024-04-25 (Thu, 25 Apr 2024)

  Changed paths:
A LayoutTests/fast/element-targeting/target-container-with-link-expected.txt
A LayoutTests/fast/element-targeting/target-container-with-link.html
M Source/WebCore/page/ElementTargetingController.cpp

  Log Message:
  ---
  [Remote Inspection] Element targeting should try :has() before falling back 
to relative selectors
https://bugs.webkit.org/show_bug.cgi?id=273265
rdar://127065936

Reviewed by Abrar Protyasha.

Currently, when finding suitable selectors for a given target element, we first 
check the target's
class, ID, and other DOM attributes to see if we can find anything unique. 
Failing this, we then
fall back to a recursive selector, assembled using either `nth-child` (if 
relative to the parent) or
`+` (if relative to a sibling). This can lead to unstable targeting behaviors 
in some cases.

Instead, implement another strategy based around using `:has(…)` on any child 
element with unique
attributes, and add ancestor selectors (`… > …`) until the selector uniquely 
identifies the target.
Prefer this strategy, before falling back to parent or sibling selectors.

* LayoutTests/fast/element-targeting/target-container-with-link-expected.txt: 
Added.
* LayoutTests/fast/element-targeting/target-container-with-link.html: Added.

Add a layout test to exercise the change.

* Source/WebCore/page/ElementTargetingController.cpp:
(WebCore::computeTagAndAttributeSelector):
(WebCore::computeHasChildSelector):
(WebCore::selectorsForTarget):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] c318bf: [Remote Inspection] Add support for targets in nes...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: c318bffec39ae54ee6bcfefaf129d1ab52790bde
  
https://github.com/WebKit/WebKit/commit/c318bffec39ae54ee6bcfefaf129d1ab52790bde
  Author: Wenson Hsieh 
  Date:   2024-04-23 (Tue, 23 Apr 2024)

  Changed paths:
M Source/WebCore/loader/DocumentLoader.h
M Source/WebCore/page/ElementTargetingController.cpp
M Source/WebCore/page/ElementTargetingController.h
M Source/WebCore/page/ElementTargetingTypes.h
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Source/WebKit/Shared/WebsitePoliciesData.h
M Source/WebKit/Shared/WebsitePoliciesData.serialization.in
M Source/WebKit/UIProcess/API/APITargetedElementInfo.h
M Source/WebKit/UIProcess/API/APIWebsitePolicies.h
M Source/WebKit/UIProcess/API/Cocoa/WKWebpagePreferences.mm
M Source/WebKit/UIProcess/API/Cocoa/WKWebpagePreferencesPrivate.h
M Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementInfo.h
M Source/WebKit/UIProcess/API/Cocoa/_WKTargetedElementInfo.mm
M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm
A Tools/TestWebKitAPI/Tests/WebKitCocoa/element-targeting-8.html

  Log Message:
  ---
  [Remote Inspection] Add support for targets in nested shadow roots
https://bugs.webkit.org/show_bug.cgi?id=273076
rdar://123160948

Reviewed by Tim Horton, Abrar Protyasha and Aditya Keerthi.

Currently, `visibilityAdjustmentSelectors` is a flattened list of CSS 
selectors, which correspond to
an arbitrary number of targeted elements. This has a couple of drawbacks:

1.  We might resolve more targets than there originally were (in the case where 
a targeted element
had multiple potential selectors, but one of them now maps to something 
else).

2.  It's unable to resolve targeted elements inside of shadow roots.

I previously worked around this in 277171@main by just returning an empty list 
in the case where the
element is inside of a shadow tree, but that only fixed the case where the 
targeted element itself
contained a shadow root (rather than being inside of the shadow DOM). This 
patch actually fixes this
issue, by revamping how we both surface and ingest CSS selectors corresponding 
to targeted elements:

•   `TargetedElementInfo` now contains a array of array of selectors. Each 
element in the outer
array corresponds to an enclosing shadow host element that contains the 
targeted element (such
that the final array maps to the targeted element itself). For targets that 
are not inside
shadow roots, this simply means that there's a single outer array. The 
inner array, like before,
represents a array of selectors (sorted by length) that can be used to 
resolve the target (or
shadow host containing the target) within its tree scope.

•   `WKWebpagePreferences` now has a 
`_visibilityAdjustmentSelectorsIncludingShadowHosts` property,
which consists of an array of array of sets of strings. To unpack this:

1.  Each array in the outermost (first) array represents a single targeted 
element.

2.  Each set in the second array represents a targeted element or shadow 
host containing the
targeted element. The last element is the targeted element itself, and 
the first element (if
the targeted element is inside of a shadow root) is the outermost 
shadow host element in the
document.

3.  Each string in the set represents a CSS selector that can potentially 
be used to resolve the
targeted element or one of its hosts, within its tree scope.

To make this work, we:

(a) Make `TargetedElementController` recursively ascend the DOM by shadow host, 
to construct a
`Vector>` for each targeted element.

(b) Teach `TargetedElementController` to ingest the array of array of sets 
described above to
resolve targeted elements that reside inside shadow trees.

There is no change in behavior for the case where targeted elements aren't 
inside the shadow DOM.

Test: ElementTargeting.AdjustVisibilityForTargetsInShadowRoot

* Source/WebCore/loader/DocumentLoader.h:
(WebCore::DocumentLoader::visibilityAdjustmentSelectors const):
(WebCore::DocumentLoader::setVisibilityAdjustmentSelectors):
* Source/WebCore/page/ElementTargetingController.cpp:
(WebCore::querySelectorMatchesOneElement):
(WebCore::computeIDSelector):
(WebCore::selectorsForTarget):

For elements inside of shadow roots, teach this to recursively find selectors 
that resolve to shadow
hosts, and return a list of lists of selectors.

(WebCore::targetedElementInfo):
(WebCore::ElementTargetingController::applyVisibilityAdjustmentFromSelectors):

Teach this to apply visibility adjustment to content inside of shadow roots.

* Source/WebCore/page/ElementTargetingController.h:
* Source/WebCore/page/ElementTargetingTypes.h:
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:

Turn the list of selectors for e

[webkit-changes] [WebKit/WebKit] 8824ae: [Remote Inspection] Adjust targeting to skip non-i...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 8824aec206772ee607381b372c9da62892f501e4
  
https://github.com/WebKit/WebKit/commit/8824aec206772ee607381b372c9da62892f501e4
  Author: Wenson Hsieh 
  Date:   2024-04-23 (Tue, 23 Apr 2024)

  Changed paths:
A 
LayoutTests/fast/element-targeting/targeted-element-ignores-pointer-events-none-overlay-expected.txt
A 
LayoutTests/fast/element-targeting/targeted-element-ignores-pointer-events-none-overlay.html
M Source/WebCore/page/ElementTargetingController.cpp

  Log Message:
  ---
  [Remote Inspection] Adjust targeting to skip non-interactable containers that 
cover the viewport
https://bugs.webkit.org/show_bug.cgi?id=273124
rdar://126818923

Reviewed by Megan Gardner.

Fine-tune the targeting heuristic further, by adding logic to skip over 
full-viewport-sized elements
that are either z-ordered below the rest of the content, or out-of-flow and 
non-interactable (i.e.
`pointer-events: none;`) with no visible background either.

* 
LayoutTests/fast/element-targeting/targeted-element-ignores-pointer-events-none-overlay-expected.txt:
 Added.
* 
LayoutTests/fast/element-targeting/targeted-element-ignores-pointer-events-none-overlay.html:
 Added.
* Source/WebCore/page/ElementTargetingController.cpp:
(WebCore::ElementTargetingController::findTargets):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] b7d3d4: [Remote Inspection] Selector-based element targeti...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: b7d3d40b4f0b12769021f7403a22a788669a1fc5
  
https://github.com/WebKit/WebKit/commit/b7d3d40b4f0b12769021f7403a22a788669a1fc5
  Author: Wenson Hsieh 
  Date:   2024-04-20 (Sat, 20 Apr 2024)

  Changed paths:
M LayoutTests/fast/element-targeting/prefer-succinct-selectors-expected.txt
M LayoutTests/fast/element-targeting/prefer-succinct-selectors.html
A 
LayoutTests/fast/element-targeting/target-element-selectors-using-attributes-expected.txt
A 
LayoutTests/fast/element-targeting/target-element-selectors-using-attributes.html
M 
LayoutTests/fast/element-targeting/target-iframe-above-nav-bar-expected.txt
M LayoutTests/fast/element-targeting/target-iframe-above-nav-bar.html
M Source/WebCore/page/ElementTargetingController.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm

  Log Message:
  ---
  [Remote Inspection] Selector-based element targeting heuristic should include 
custom DOM attributes
https://bugs.webkit.org/show_bug.cgi?id=273038
rdar://126633838

Reviewed by Richard Robinson.

Make a couple more adjustments to the targeting heuristic, to make matching 
more robust (and to
avoid falling back to n-th child selectors in more cases):

-   Additionally surface unique selectors based on element attributes.
-   Return early if we've already found unique selectors based on attributes 
solely based on the
targeted element, to avoid the more expensive (and less stable) process of 
recursively finding
parent- or child-relative selectors.

* LayoutTests/fast/element-targeting/prefer-succinct-selectors-expected.txt:
* LayoutTests/fast/element-targeting/prefer-succinct-selectors.html:

Rebaseline an existing layout test.

* 
LayoutTests/fast/element-targeting/target-element-selectors-using-attributes-expected.txt:
 Added.
* 
LayoutTests/fast/element-targeting/target-element-selectors-using-attributes.html:
 Added.

Add a new layout test to exercise the enhancements.

* LayoutTests/fast/element-targeting/target-iframe-above-nav-bar-expected.txt:
* LayoutTests/fast/element-targeting/target-iframe-above-nav-bar.html:

More rebaselining.

* Source/WebCore/page/ElementTargetingController.cpp:
(WebCore::querySelectorMatchesOneElement):
(WebCore::computeTagAndAttributeSelector):
(WebCore::computeTagAndClassSelector):
(WebCore::selectorForElementRecursive):
(WebCore::selectorsForTarget):
(WebCore::computeClassSelector): Deleted.

See above for more details.

* Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm:
(TestWebKitAPI::TEST(ElementTargeting, BasicElementTargeting)):
(TestWebKitAPI::TEST(ElementTargeting, NearbyOutOfFlowElements)):
(TestWebKitAPI::TEST(ElementTargeting, TargetInFlowElements)):

Rebaseline existing API tests.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] b4d744: REGRESSION (277282@main): [macOS] Writing suggesti...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: b4d7445ce5f49f51d491b03d64e83a235949a28b
  
https://github.com/WebKit/WebKit/commit/b4d7445ce5f49f51d491b03d64e83a235949a28b
  Author: Wenson Hsieh 
  Date:   2024-04-19 (Fri, 19 Apr 2024)

  Changed paths:
M LayoutTests/TestExpectations
A 
LayoutTests/editing/input/mac/show-inline-prediction-with-adjacent-text-expected-mismatch.html
A 
LayoutTests/editing/input/mac/show-inline-prediction-with-adjacent-text.html
M LayoutTests/platform/mac-wk2/TestExpectations
M LayoutTests/resources/ui-helper.js
M Source/WebCore/editing/Editor.cpp
M Source/WebCore/editing/Editor.h
M Source/WebCore/rendering/updating/RenderTreeUpdaterGeneratedContent.cpp
M Tools/TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl
M Tools/TestRunnerShared/UIScriptContext/UIScriptController.h
M Tools/WebKitTestRunner/ios/UIScriptControllerIOS.h
M Tools/WebKitTestRunner/ios/UIScriptControllerIOS.mm
M Tools/WebKitTestRunner/mac/UIScriptControllerMac.h
M Tools/WebKitTestRunner/mac/UIScriptControllerMac.mm

  Log Message:
  ---
  REGRESSION (277282@main): [macOS] Writing suggestions may incorrectly render 
at the end of an editable element
https://bugs.webkit.org/show_bug.cgi?id=272898
rdar://126493252

Reviewed by Richard Robinson.

After the changes in 277282@main, inline writing suggestions use generated 
`RenderText` to render
the suggested text content after the current selection. To identify where to 
insert this generated
renderer, we currently walk up from the caret selection's container node until 
we encounter an
`Element`; this element's renderer then acts as the parent for this generated 
text renderer.

While this seems to work in most cases, it fails in the scenario where a single 
element contains
multiple text nodes underneath it, and the user is typing before a newline. 
Since we're only capable
of inserting the generated content at the end of an element renderer, it 
appears in the wrong place
(at the end of the contaiing element), rather than where the user is actually 
typing.

```
DIV // parent element
  "Foo" // user is typing here
  "\n"  // newline
  "Bar" // writing suggestion renderer is inserted here
```

To fix this, we refactor some of this logic around managing the writing 
suggestions renderer:

1.  Instead of trying to keep track of the containing element enclosing the 
writing suggestions,
just keep track of the node *before which* we expect writing suggestions to 
be inserted.
Importantly, this is robust in the case described above, where we return 
`"Foo"` instead of the
element containing all three nodes.

2.  When updating the render tree to add generated content for writing 
suggestions, use the optional
`beforeChild` argument of `RenderTreeBuilder::attach` to ensure that the 
writing suggestions
renderer is inserted in the right place, relative to the renderer of the 
node found in (1).

Test: editing/input/mac/show-inline-prediction-with-adjacent-text.html

* LayoutTests/TestExpectations:
* 
LayoutTests/editing/input/mac/show-inline-prediction-with-adjacent-text-expected-mismatch.html:
 Added.
* LayoutTests/editing/input/mac/show-inline-prediction-with-adjacent-text.html: 
Added.

Add a layout test to exercise the fix by verifying that the writing suggestion 
is not rendered at
the end of the editable container, in the case where the suggested text is 
being inserted before the
newline.

* LayoutTests/platform/mac-wk2/TestExpectations:
* LayoutTests/resources/ui-helper.js:
(window.UIHelper.async setInlinePrediction):

Augment an existing testing hook to insert inline predictions, so that it works 
on macOS as well.
To facilitate this, we introduce a second parameter (optional on iOS) to 
indicating the start index
of the predicted text, relative to the full text. This defaults to 0, which 
simply inserts the
inline prediction at the caret position (regardless of whether the text before 
the caret matches the
expected text).

* Source/WebCore/editing/Editor.cpp:
(WebCore::Editor::nodeBeforeWritingSuggestions const):
(WebCore::Editor::writingSuggestionsContainerElement const):

Reimplement this in terms of `nodeBeforeWritingSuggestions`; see above for more 
details.

(WebCore::Editor::removeWritingSuggestionIfNeeded):
(WebCore::Editor::setWritingSuggestion):
(WebCore::Editor::writingSuggestionsContainerElement): Deleted.
* Source/WebCore/editing/Editor.h:
* Source/WebCore/rendering/updating/RenderTreeUpdaterGeneratedContent.cpp:
(WebCore::RenderTreeUpdater::GeneratedContent::updateWritingSuggestionsRenderer):

See comments above for more details. Drive-by fix: also avoid adding extra 
renderers for empty text
nodes, in the case where there is no suffix text.

* Tools/TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl:

Add test support for simulating inline predictions (w

[webkit-changes] [WebKit/WebKit] 6178c5: [Remote Inspection] Replaced object sizes in rende...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 6178c52c2c0709883139911f57d95f05aaf019d0
  
https://github.com/WebKit/WebKit/commit/6178c52c2c0709883139911f57d95f05aaf019d0
  Author: Wenson Hsieh 
  Date:   2024-04-19 (Fri, 19 Apr 2024)

  Changed paths:
M Source/WebCore/page/text-extraction/TextExtraction.cpp
M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm
A Tools/TestWebKitAPI/Tests/WebKitCocoa/element-targeting-7.html

  Log Message:
  ---
  [Remote Inspection] Replaced object sizes in rendered text string should not 
change with page zoom/scale
https://bugs.webkit.org/show_bug.cgi?id=272492
rdar://126652273

Reviewed by Abrar Rahman Protyasha.

Instead of surfacing the size of each replaced renderer in root view 
coordinates, use the size of
the replaced content rect instead, adjusted to ignore page zoom and rounded to 
the nearest 10px to
reduce resolution.

* Source/WebCore/page/text-extraction/TextExtraction.cpp:
(WebCore::TextExtraction::reducePrecision):
(WebCore::TextExtraction::extractRenderedText):
* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm:
(TestWebKitAPI::TEST(ElementTargeting, 
ReplacedRendererSizeIgnoresPageScaleAndZoom)):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/element-targeting-7.html: Added.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 4bd9d2: [iOS] Augment editing/selection/ios/extend-selecti...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 4bd9d212a66f4cbeec0eca36128f800273c3b295
  
https://github.com/WebKit/WebKit/commit/4bd9d212a66f4cbeec0eca36128f800273c3b295
  Author: Wenson Hsieh 
  Date:   2024-04-19 (Fri, 19 Apr 2024)

  Changed paths:
A 
LayoutTests/editing/selection/ios/extend-selection-with-inline-predictions-expected.txt
A 
LayoutTests/editing/selection/ios/extend-selection-with-inline-predictions.html
R 
LayoutTests/editing/selection/ios/select-backwards-with-inline-predictions-expected.txt
R 
LayoutTests/editing/selection/ios/select-backwards-with-inline-predictions.html

  Log Message:
  ---
  [iOS] Augment 
editing/selection/ios/extend-selection-with-inline-predictions.html to test 
additional arrow keys
https://bugs.webkit.org/show_bug.cgi?id=272953

Reviewed by Aditya Keerthi and Ryosuke Niwa.

Augment an existing test to cover some other minor variations of the original 
radar by attempting to
extend the selection in all directions.

* 
LayoutTests/editing/selection/ios/extend-selection-with-inline-predictions-expected.txt:
 Renamed from 
LayoutTests/editing/selection/ios/select-backwards-with-inline-predictions-expected.txt.
* 
LayoutTests/editing/selection/ios/extend-selection-with-inline-predictions.html:
 Renamed from 
LayoutTests/editing/selection/ios/select-backwards-with-inline-predictions.html.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] dfe10e: NEW TEST(277656@main): [ MacOS ] TestWebKitAPI.Uni...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: dfe10e0b9b0dc81eb4edb73f7da8992e767bbc43
  
https://github.com/WebKit/WebKit/commit/dfe10e0b9b0dc81eb4edb73f7da8992e767bbc43
  Author: Wenson Hsieh 
  Date:   2024-04-18 (Thu, 18 Apr 2024)

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

  Log Message:
  ---
  NEW TEST(277656@main): [ MacOS ] 
TestWebKitAPI.UnifiedPDF.KeyboardScrollingInSinglePageMode is a consistent 
timeout
https://bugs.webkit.org/show_bug.cgi?id=272900
rdar://126695619

Reviewed by Abrar Rahman Protyasha.

Limit this test to run only when the unified PDF plugin is used by default.

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

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] b32dad: [Unified PDF] [macOS] Can't use the arrow keys to ...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: b32dad0669e5ac9124d50dfe8036704e0f6c6aea
  
https://github.com/WebKit/WebKit/commit/b32dad0669e5ac9124d50dfe8036704e0f6c6aea
  Author: Wenson Hsieh 
  Date:   2024-04-18 (Thu, 18 Apr 2024)

  Changed paths:
M Source/WebCore/platform/KeyboardScrollingAnimator.h
M Source/WebCore/platform/ScrollAnimator.h
M Source/WebCore/plugins/PluginViewBase.h
M Source/WebCore/testing/Internals.cpp
M Source/WebCore/testing/Internals.h
M Source/WebCore/testing/Internals.idl
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h
M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm
M Source/WebKit/WebProcess/Plugins/PluginView.cpp
M Source/WebKit/WebProcess/Plugins/PluginView.h
M Tools/TestWebKitAPI/SourcesCocoa.txt
M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
A Tools/TestWebKitAPI/Tests/WebKitCocoa/UnifiedPDFTests.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPIAction.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPIMenus.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPIWebRequest.mm
A Tools/TestWebKitAPI/Tests/WebKitCocoa/multiple-pages.pdf
M Tools/TestWebKitAPI/cocoa/TestWKWebView.h
M Tools/TestWebKitAPI/cocoa/TestWKWebView.mm

  Log Message:
  ---
  [Unified PDF] [macOS] Can't use the arrow keys to navigate between pages in 
Single page mode
https://bugs.webkit.org/show_bug.cgi?id=272828
rdar://123193004

Reviewed by Abrar Protyasha.

Implement keyboard scrolling when viewing PDFs in Single Page mode. The 
behavior (mostly) matches
that in prior macOS versions, but with the added nicety that keyboard scrolling 
is now smoothly
animated (rather than discrete).

Test: UnifiedPDF.KeyboardScrollingInSinglePageMode

* Source/WebCore/platform/KeyboardScrollingAnimator.h:
* Source/WebCore/platform/ScrollAnimator.h:

`WEBCORE_EXPORT` several helper methods, so we can use them to service keyboard 
scrolling in
`UnifiedPDFPlugin`.

* Source/WebCore/plugins/PluginViewBase.h:
(WebCore::PluginViewBase::setPDFDisplayModeForTesting):
* Source/WebCore/testing/Internals.cpp:
(WebCore::Internals::setPDFDisplayModeForTesting const):
* Source/WebCore/testing/Internals.h:
* Source/WebCore/testing/Internals.idl:

Add an `internals` testing hook to set the current PDF display mode. The 
arguments are strings that
match the internal `enum class` names:

```
SinglePageDiscrete
SinglePageContinuous
TwoUpDiscrete
TwoUpContinuous
```

* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h:
(WebKit::PDFPluginBase::annotationRectsForTesting const):
(WebKit::PDFPluginBase::setPDFDisplayModeForTesting):
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h:
* Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
(WebKit::UnifiedPDFPlugin::didChangeScrollOffset):

See comments in `handleKeyboardEventForDiscreteDisplayMode` below.

(WebKit::UnifiedPDFPlugin::isInDiscreteDisplayMode const):

Rename this to `isInDiscreteDisplayMode`, since it's now used to guard keyboard 
scrolling behaviors
that are specific to discrete display modes (both two-up and single).

(WebKit::UnifiedPDFPlugin::isShowingTwoPages const):

Add a helper method that returns whether or not we're in two-up mode. 
Currently, only used in a
couple places to determine the offset of the next set of pages when scrolling 
with arrow keys, if
the page is (/pages are) shorter than the viewport.

(WebKit::UnifiedPDFPlugin::pageBoundsInContentsSpace const):

Pull this out into a helper method, so we can use it from multiple places.

(WebKit::UnifiedPDFPlugin::updateSnapOffsets):

Make a slight adjustment here to snap to the *closest* snap offset rather than 
the first offset past
the current scroll position. This ensures that the `m_currentlySnappedPage` 
doesn't prematurely jump
to the previous page in `handleKeyboardEventForDiscreteDisplayMode` when 
determining whether we're
near a snap point.

(WebKit::UnifiedPDFPlugin::determineCurrentlySnappedPage):
(WebKit::UnifiedPDFPlugin::shouldDisplayPage):
(WebKit::UnifiedPDFPlugin::checkedKeyboardScrollingAnimator const):
(WebKit::UnifiedPDFPlugin::handleKeyboardCommand):

Factor this out into a separate method to make the code easier to follow.

(WebKit::UnifiedPDFPlugin::handleKeyboardEventForDiscreteDisplayMode):

Implement the main keyboard scrolling logic here — if the page is shorter than 
the viewport, we want
to instantly jump to the next or previous page (or set of 2 pages). If the page 
is taller than the
viewport (e.g. when zooming within a page in Single Page mode), we want to 
allow the user to scroll
within the page, and clamp scrolling to the edges of the page.

To achieve this, we detect when the user is about to scroll near either the top 
or bottom page
extent — in this case, we:

1. Stop animated

[webkit-changes] [WebKit/WebKit] a65c65: [Remote Inspection] Make it easier to inspect only...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: a65c65a9ee61610307216fd8dda89d6ff89b441e
  
https://github.com/WebKit/WebKit/commit/a65c65a9ee61610307216fd8dda89d6ff89b441e
  Author: Wenson Hsieh 
  Date:   2024-04-16 (Tue, 16 Apr 2024)

  Changed paths:
A 
LayoutTests/fast/element-targeting/target-iframe-above-nav-bar-expected.txt
A LayoutTests/fast/element-targeting/target-iframe-above-nav-bar.html
M Source/WebCore/page/ElementTargetingController.cpp

  Log Message:
  ---
  [Remote Inspection] Make it easier to inspect only iframes with nearby 
navigational elements
https://bugs.webkit.org/show_bug.cgi?id=272765
rdar://123279263

Reviewed by Megan Gardner.

Adjust the targeting heuristic to make it easier to inspect `iframe`s without 
targeting enclosing
container elements that contain navigational elements (e.g. nav bars). If 
needed, we can expand this
"narrowing heuristic" to care about more than just navigational elements.

* LayoutTests/fast/element-targeting/target-iframe-above-nav-bar-expected.txt: 
Added.
* LayoutTests/fast/element-targeting/target-iframe-above-nav-bar.html: Added.
* Source/WebCore/page/ElementTargetingController.cpp:
(WebCore::isNavigationalElement):
(WebCore::containsNavigationalElement):
(WebCore::isTargetCandidate):
(WebCore::ElementTargetingController::findTargets):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 866b41: [Remote Inspection] Tune viewport area ratio size ...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 866b410bceb84beb179dff08a712f1c00c962ecd
  
https://github.com/WebKit/WebKit/commit/866b410bceb84beb179dff08a712f1c00c962ecd
  Author: Wenson Hsieh 
  Date:   2024-04-15 (Mon, 15 Apr 2024)

  Changed paths:
M Source/WebCore/page/ElementTargetingController.cpp
M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm
A Tools/TestWebKitAPI/Tests/WebKitCocoa/element-targeting-6.html

  Log Message:
  ---
  [Remote Inspection] Tune viewport area ratio size thresholds to be less 
restrictive on mobile sites
https://bugs.webkit.org/show_bug.cgi?id=272654
rdar://126271452

Reviewed by Abrar Rahman Protyasha.

Currently, the constants used to identify absolutely-positioned or in-flow 
candidates when finding
targets have been (for the most part) tested against desktop content on macOS. 
However, these
thresholds are slightly too restrictive on mobile, where potential targets tend 
to fill a larger
portion of the viewport.

To account for this, this patch turns the 5 constant values below into 
linearly-interpolated values,
depending on the viewport area. At roughly desktop-class viewport areas, these 
are equivalent to
their current values; on mobile, these are tuned to be relatively larger.

```
Form FactorArea   Max AbsPos  Max In-FlowMin In-FlowMax 
NearbyMax Adj. Area
---
Desktop80 0.750   0.500  0.005  0.250   
  0.250
Mobile 20 1.000   1.000  0.010  0.500   
  0.300
```

* Source/WebCore/page/ElementTargetingController.cpp:
(WebCore::linearlyInterpolatedViewportRatio):
(WebCore::maximumAreaRatioForAbsolutelyPositionedContent):
(WebCore::maximumAreaRatioForInFlowContent):
(WebCore::maximumAreaRatioForNearbyTargets):
(WebCore::minimumAreaRatioForInFlowContent):
(WebCore::maximumAreaRatioForTrackingAdjustmentAreas):

Turn all of these hard-coded constants into helper functions that take the 
current viewport size as
input, and return linearly-interpolated values, clamped to the given 
minimum/maximum values.

(WebCore::inflatedClientRectForAdjustmentRegionTracking):
(WebCore::ElementTargetingController::findTargets):

Make an additional adjustment: treat candidates with no children as targets, 
even if they're above
size thresholds.

* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm:
(-[WKWebView expectSingleTargetedSelector:at:]):

Pull this testing helper out of `ElementTargeting.ParentRelativeSelectors` and 
into a helper method
in a testing category on `TestWKWebView`, so that we can use it from both of 
the below tests.

(TestWebKitAPI::TEST(ElementTargeting, ParentRelativeSelectors)):
(TestWebKitAPI::TEST(ElementTargeting, TargetInFlowElements)):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/element-targeting-6.html: Added.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 52af77: [Remote Inspection] Targeting incorrectly prefers ...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 52af773ed3aebb787b7471e81634d5d68d2f7923
  
https://github.com/WebKit/WebKit/commit/52af773ed3aebb787b7471e81634d5d68d2f7923
  Author: Wenson Hsieh 
  Date:   2024-04-14 (Sun, 14 Apr 2024)

  Changed paths:
A 
LayoutTests/fast/element-targeting/target-container-with-pseudo-elements-expected.txt
A 
LayoutTests/fast/element-targeting/target-container-with-pseudo-elements.html
M Source/WebCore/page/ElementTargetingController.cpp

  Log Message:
  ---
  [Remote Inspection] Targeting incorrectly prefers pseudos over targets that 
contain their hosts
https://bugs.webkit.org/show_bug.cgi?id=272647
rdar://126299041

Reviewed by Abrar Rahman Protyasha.

When a candidate is chosen as a target, logic in the while loop in 
`findTargets` filters out other
candidate elements that are redundant, due to being contained within the newly 
chosen target.
However, this logic doesn't currently handle pseudo elements correctly, which 
means that front-most
pseudo elements are surfaced as higher-priority targets, even though another 
container element
enclosing them has already been chosen.

Fix this by augmenting the check to omit pseudo element candidates if their 
host element is
contained within the newly chosen target.

* 
LayoutTests/fast/element-targeting/target-container-with-pseudo-elements-expected.txt:
 Added.
* 
LayoutTests/fast/element-targeting/target-container-with-pseudo-elements.html: 
Added.
* Source/WebCore/page/ElementTargetingController.cpp:
(WebCore::ElementTargetingController::findTargets):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] aebf3a: [Remote Inspection] nth-child selectors may target...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: aebf3a2151c5d375c404747ae5090e255984cae5
  
https://github.com/WebKit/WebKit/commit/aebf3a2151c5d375c404747ae5090e255984cae5
  Author: Wenson Hsieh 
  Date:   2024-04-12 (Fri, 12 Apr 2024)

  Changed paths:
M Source/WebCore/page/ElementTargetingController.cpp
M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm
A Tools/TestWebKitAPI/Tests/WebKitCocoa/element-targeting-5.html

  Log Message:
  ---
  [Remote Inspection] nth-child selectors may target the wrong element
https://bugs.webkit.org/show_bug.cgi?id=272612
rdar://126362427

Reviewed by Megan Gardner and Abrar Protyasha.

Currently, the `N` used for `nth-child(N)` selectors when extracting targeted 
elements represents
the Nth index of that element type; instead, it should represent the Nth 
element child relative to
the parent (regardless of type). Fix this bug by adjusting 
`parentRelativeSelectorRecursive`, and
add an API test to cover these cases.

* Source/WebCore/page/ElementTargetingController.cpp:
(WebCore::findChild):
(WebCore::parentRelativeSelectorRecursive):
(WebCore::childIndexByType): Deleted.
* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm:
(TestWebKitAPI::TEST(ElementTargeting, ParentRelativeSelectors)):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/element-targeting-5.html: Added.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 06512b: [Remote Inspection] Add a delegate method to notif...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 06512bae0bd8f4c4cf65a959938eac4bb7290898
  
https://github.com/WebKit/WebKit/commit/06512bae0bd8f4c4cf65a959938eac4bb7290898
  Author: Wenson Hsieh 
  Date:   2024-04-10 (Wed, 10 Apr 2024)

  Changed paths:
M Source/WebCore/page/ChromeClient.h
M Source/WebCore/page/ElementTargetingController.cpp
M Source/WebKit/UIProcess/API/APIUIClient.h
M Source/WebKit/UIProcess/API/Cocoa/WKUIDelegatePrivate.h
M Source/WebKit/UIProcess/Cocoa/UIDelegate.h
M Source/WebKit/UIProcess/Cocoa/UIDelegate.mm
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/UIProcess/WebPageProxy.messages.in
M Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.cpp
M Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.h
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm
M Tools/TestWebKitAPI/cocoa/TestUIDelegate.h
M Tools/TestWebKitAPI/cocoa/TestUIDelegate.mm

  Log Message:
  ---
  [Remote Inspection] Add a delegate method to notify clients of selector-based 
visibility adjustment
https://bugs.webkit.org/show_bug.cgi?id=272482

Reviewed by Aditya Keerthi.

Add a new UI delegate method to notify clients when selector-based visibility 
adjustment occurs. See
below for more details.

* Source/WebCore/page/ChromeClient.h:
(WebCore::ChromeClient::didAdjustVisibilityWithSelectors):

Add a new `ChromeClient` method that eventually makes an IPC call out to the 
application process,
where it invokes the new UI delegate method.

* Source/WebCore/page/ElementTargetingController.cpp:
(WebCore::ElementTargetingController::applyVisibilityAdjustmentFromSelectors):

Call into the chrome client method here; also, make a couple of minor tweaks to 
ensure that we only
apply adjustment to content that is actually rendered (with a non-empty client 
rect).

* Source/WebKit/UIProcess/API/APIUIClient.h:
(API::UIClient::didAdjustVisibilityWithSelectors):
* Source/WebKit/UIProcess/API/Cocoa/WKUIDelegatePrivate.h:
* Source/WebKit/UIProcess/Cocoa/UIDelegate.h:
* Source/WebKit/UIProcess/Cocoa/UIDelegate.mm:
(WebKit::UIDelegate::setDelegate):
(WebKit::UIDelegate::UIClient::didAdjustVisibilityWithSelectors):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::didAdjustVisibilityWithSelectors):
* Source/WebKit/UIProcess/WebPageProxy.h:
* Source/WebKit/UIProcess/WebPageProxy.messages.in:
* Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.cpp:
(WebKit::WebChromeClient::didAdjustVisibilityWithSelectors):
* Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.h:
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::didAdjustVisibilityWithSelectors):
* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/ElementTargetingTests.mm:
(TestWebKitAPI::TEST(ElementTargeting, AdjustVisibilityFromSelectors)):
(TestWebKitAPI::TEST(ElementTargeting, AdjustVisibilityFromPseudoSelectors)):
* Tools/TestWebKitAPI/cocoa/TestUIDelegate.h:
* Tools/TestWebKitAPI/cocoa/TestUIDelegate.mm:
(-[TestUIDelegate _webView:didAdjustVisibilityWithSelectors:]):

Add test coverage by augmenting two existing API tests to also check that the 
new delegate method is
called, with the right selector strings.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 87b57e: [Remote Inspection] Improve the heuristic for extr...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 87b57ed36164d494c13f5dfec8e6701115a8b8dd
  
https://github.com/WebKit/WebKit/commit/87b57ed36164d494c13f5dfec8e6701115a8b8dd
  Author: Wenson Hsieh 
  Date:   2024-04-09 (Tue, 09 Apr 2024)

  Changed paths:
A LayoutTests/fast/element-targeting/prefer-succinct-selectors-expected.txt
A LayoutTests/fast/element-targeting/prefer-succinct-selectors.html
M Source/WebCore/page/ElementTargetingController.cpp

  Log Message:
  ---
  [Remote Inspection] Improve the heuristic for extracting CSS selectors for 
targeted elements
https://bugs.webkit.org/show_bug.cgi?id=272413
rdar://123615458

Reviewed by Megan Gardner.

Refactor some of the logic around finding CSS selectors for targeted elements, 
such that we:

1.  Prefers shorter selector strings over longer ones.
2.  Prefers selectors that reference the target's class, ID or tag name over 
selectors that are
relative to other elements.
3.  Allow for sibling-relative selectors as well as parent-relative ones.

This also sorts the returned selector strings, in order from most preferred to 
least preferred
selector. To avoid exponential runtime in this new algorithm (since we're now 
collecting both
sibling-relative and parent-relative selectors), we also plumb a `HashMap` as 
we're recursively
walking up the tree for each element, which we use to memoize 
`selectorForElementRecursive`. This
ensures `O(n^2)` performance in the worst case, where `n` is the number of 
nodes in the DOM (since
each visit could potentially trigger a `querySelector(…)` with class or tag 
names), but in practice,
means we'll typically get away with `O(n)`, since we'll stop after hitting the 
first ancestor or
sibling element with unique classes or IDs per target, and are typically a 
small number of targets.

* LayoutTests/fast/element-targeting/prefer-succinct-selectors-expected.txt: 
Added.
* LayoutTests/fast/element-targeting/prefer-succinct-selectors.html: Added.

Add a new layout test to exercise the "prefers conciseness" part of selector 
finding.

* Source/WebCore/page/ElementTargetingController.cpp:
(WebCore::computeIDSelector):
(WebCore::computeClassSelector):
(WebCore::shortestSelector):
(WebCore::selectorForElementRecursive):
(WebCore::siblingRelativeSelectorRecursive):
(WebCore::parentRelativeSelectorRecursive):

See above for more details.

(WebCore::selectorsForTarget):
(WebCore::targetedElementInfo):
(WebCore::ElementTargetingController::findTargets):

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] ef7c99: [iOS] fast/writing-mode/english-bt-text-with-spell...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: ef7c999e5c101b9113bb61a3002942f86f99f089
  
https://github.com/WebKit/WebKit/commit/ef7c999e5c101b9113bb61a3002942f86f99f089
  Author: Wenson Hsieh 
  Date:   2024-04-09 (Tue, 09 Apr 2024)

  Changed paths:
M 
LayoutTests/fast/writing-mode/english-bt-text-with-spelling-marker-expected.html
M LayoutTests/fast/writing-mode/english-bt-text-with-spelling-marker.html

  Log Message:
  ---
  [iOS] fast/writing-mode/english-bt-text-with-spelling-marker.html is a flaky 
failure after 277233@main
https://bugs.webkit.org/show_bug.cgi?id=272395

Reviewed by Aditya Keerthi.

After the changes in 277233@main, spelling dots are now showing up on iOS, in 
this test; this causes
a very slight image diff, as the direction of the gradient differs slightly 
between the reference
and test.

Fix this by adjusting the `maxDifference` to accommodate iOS 17, and also 
adjust the test itself to
reliably show spelling dots by adding `spellCheckingDots=true` as a test 
option, and also use
`UIHelper.setSpellCheckerResults` to force spellchecking to detect 
`"mispelled"` as a misspelled
word.

* 
LayoutTests/fast/writing-mode/english-bt-text-with-spelling-marker-expected.html:
* LayoutTests/fast/writing-mode/english-bt-text-with-spelling-marker.html:

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [WebKit/WebKit] 697b1a: [ iOS ] 3x editing/spelling/* (layout-tests) are c...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 697b1a86cea65c70aa013ce7402a16a516181baf
  
https://github.com/WebKit/WebKit/commit/697b1a86cea65c70aa013ce7402a16a516181baf
  Author: Wenson Hsieh 
  Date:   2024-04-08 (Mon, 08 Apr 2024)

  Changed paths:
M LayoutTests/platform/ios/TestExpectations
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Source/WebKit/UIProcess/ios/WKExtendedTextInputTraits.h
M Source/WebKit/UIProcess/ios/WKExtendedTextInputTraits.mm

  Log Message:
  ---
  [ iOS ] 3x editing/spelling/* (layout-tests) are constant failures
https://bugs.webkit.org/show_bug.cgi?id=271864
rdar://125585822

Reviewed by Aditya Keerthi.

Among the many other changes to adopt `BETextInput`, iOS 17.4 refactored 
`WKContentView` to stop
relying on the UIKit internal method `-_requiresKeyboardWhenFirstResponder`. 
Instead, UIKit now
returns `YES` when the delegate is a `BETextInput`, as long as either of the 
following are true:

1. The hardware keyboard is connected.
2. An editable element is focused.

However, a consequence of this refactoring is that `WKContentView` now vends 
text input traits to
keyboard code in UIKit when a hardware keyboard is attached, even in the case 
where there is no
focused element. In practice, this doesn't really matter, since these text 
input traits (which
contain `UITextAutocorrectionTypeNo`) are effectively unused. However, in the 
case of these three
layout tests that programmatically focus text inputs, insert text, and expect 
spellchecking to
occur outside of the context of any input session, we end up failing because 
the spelling
corrections are disabled by the traits.

To fix this, restore pre-iOS 17.4 behavior by reverting to 
`WKExtendedTextInputTraits`'s default
values when no element is focused (or being focused). Namely, this ensures that 
the autocorrection
type is set to `UITextAutocorrectionTypeDefault`, which matches shipping 
behavior in the case when
the user isn't focusing anything editable, but still enables continuous 
spellchecking when
programmatically inserting text.

* LayoutTests/platform/ios/TestExpectations:

Mark these layout test as passing again.

* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _updateTextInputTraits:]):
(-[WKContentView extendedTraitsDelegate]):

See above for more details.

* Source/WebKit/UIProcess/ios/WKExtendedTextInputTraits.h:
* Source/WebKit/UIProcess/ios/WKExtendedTextInputTraits.mm:
(-[WKExtendedTextInputTraits init]):
(-[WKExtendedTextInputTraits setSelectionColorsToMatchTintColor:]):
(-[WKExtendedTextInputTraits restoreDefaultValues]):

Add a new method to restore all default text input traits.

(-[WKExtendedTextInputTraits setSelectionBarColor:]): Deleted.
(-[WKExtendedTextInputTraits selectionBarColor]): Deleted.

Remove some old versions of the `UIAsyncTextInput` implementation that are no 
longer necessary,
since they've all been superceded by `BETextInput`.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes