Fixes https://github.com/w3c/selection-api/issues/170. #172
Conversation
rniwa
force-pushed
the
schedule-selectionchange-once
branch
from
985c48d
to
c3903d0
Compare
| abort these steps. | ||
| </li> | ||
| <li> | ||
| <a>Queue a task</a> on the <a>user interaction task source</a> to |
There was a problem hiding this comment.
Instead of queue a task, you want https://html.spec.whatwg.org/#queue-an-element-task and also pass that target. This way some aspects of the task get better initialized.
(We want to eventually remove "queue a task".)
There was a problem hiding this comment.
I don't think that'll work because target can be a document, which isn't an element.
There was a problem hiding this comment.
Oh yeah, I guess we can invoke https://html.spec.whatwg.org/#queue-a-global-task instead and obtain the global ourselves, but it seems there should be a helper for that. Maybe the primitive should be "queue an object task" where "object" has to be a "platform object". @domenic what do you think about that?
I also wonder if someone moves an element from one document to another, should we really have the global from the former document or should we use the element's node document's global object?
rniwa
force-pushed
the
schedule-selectionchange-once
branch
from
c3903d0
to
8c2bbd9
Compare
rniwa
force-pushed
the
schedule-selectionchange-once
branch
from
8c2bbd9
to
237fc5c
Compare
|
So currently we don't do this for the only focused element, right? For example, for several input elements on the same page, every input has its own has_scheduled_selectionchange_event, and we will do same things for every input or text area . |
Right. Boolean is per element. |
https://bugs.webkit.org/show_bug.cgi?id=271117 Reviewed by Chris Dumez. Implement the spec change to avoid queuing a task to fire a selectionchange event when there is already a task scheduled to do that for the target: w3c/selection-api#172 Also update the relevant web platform tests: web-platform-tests/wpt#45145 * LayoutTests/fast/events/selectionchange-iframe-expected.txt: * LayoutTests/fast/events/selectionchange-user-initiated-expected.txt: * LayoutTests/imported/w3c/web-platform-tests/selection/onselectionchange-on-distinct-text-controls-expected.txt: Added. * LayoutTests/imported/w3c/web-platform-tests/selection/onselectionchange-on-distinct-text-controls.html: Added. * LayoutTests/imported/w3c/web-platform-tests/selection/onselectionchange-on-document-expected.txt: Added. * LayoutTests/imported/w3c/web-platform-tests/selection/onselectionchange-on-document.html: Added. * LayoutTests/imported/w3c/web-platform-tests/selection/textcontrols/selectionchange.html: * Source/WebCore/editing/FrameSelection.cpp: (WebCore::FrameSelection::setSelectionWithoutUpdatingAppearance): * Source/WebCore/editing/FrameSelection.h: * Source/WebCore/html/HTMLTextFormControlElement.cpp: (WebCore::HTMLTextFormControlElement::HTMLTextFormControlElement): (WebCore::HTMLTextFormControlElement::scheduleSelectionChangeEvent): (WebCore::HTMLTextFormControlElement::scheduleSelectEvent): * Source/WebCore/html/HTMLTextFormControlElement.h: (WebCore::HTMLTextFormControlElement::hasScheduledSelectionChangeEvent const): (WebCore::HTMLTextFormControlElement::setHasScheduledSelectionChangeEvent): Canonical link: https://commits.webkit.org/276388@main
|
WebKit has implemented this new behavior as of https://commits.webkit.org/276388@main. |
According to the new spec[1], we need enqueue selectionchange event per element. WebKit also updated the implementation of selectionchange event in webcore[2]. [1] w3c/selection-api#172 [2] https://commits.webkit.org/276238@main Change-Id: If2020febecdf32d6165023712442f16c6e91bd4c
According to the new spec[1], we need enqueue selectionchange event per element. WebKit also updated the implementation of selectionchange event in webcore[2]. [1] w3c/selection-api#172 [2] https://commits.webkit.org/276238@main Change-Id: If2020febecdf32d6165023712442f16c6e91bd4c
According to the new spec[1], we need enqueue selectionchange event per element. WebKit also updated the implementation of selectionchange event in webcore[2]. [1] w3c/selection-api#172 [2] https://commits.webkit.org/276238@main Bug: 330766600 Change-Id: If2020febecdf32d6165023712442f16c6e91bd4c Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5393615 Reviewed-by: Koji Ishii <kojii@chromium.org> Reviewed-by: Kent Tamura <tkent@chromium.org> Commit-Queue: Shuangshuang Zhou <shuangshuang.zhou@intel.com> Cr-Commit-Position: refs/heads/main@{#1291702}
|
Curious, is this (possibly breaking) change already in the shipping version of Safari? (I don't have a Mac around atm). I'm changing the behavior in Gecko. Test runs are still pending. |
|
No, it hasn't shipped yet. |
Add a boolean flag "has scheduled selectionchange event" to selection, and check it before queuing a task to fire a
selectionchangeevent.Preview | Diff