Status Update
Comments
mu...@chromium.org <mu...@chromium.org> #2
mu...@chromium.org <mu...@chromium.org> #3
mu...@chromium.org <mu...@chromium.org> #4
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #6
commit 48b195e0fea6a731941c399a034ac6bb7b472f10
Author: Mustaq Ahmed <mustaq@google.com>
Date: Fri Aug 26 22:38:01 2022
[CodeHealth] Remove obsolete MouseEventManager state and related UMA
MouseEventManager::mouse_down_element_ is effectively useless today:
- It was added in [1] to gather UMA data about a bug [2]. The bug is
now obsolete, and the UMA data has expired a while ago.
- Then another UMA related to `mouse_down_element_` was added in [3]
which has also expired.
[1]
[2]
[3]
Bug: 1220669, 1342209
Change-Id: Ida6137d27c9494ce4f66052490febbf745c9e0f2
Reviewed-on:
Commit-Queue: Mustaq Ahmed <mustaq@chromium.org>
Reviewed-by: Robert Flack <flackr@chromium.org>
Reviewed-by: Jonathan Ross <jonross@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1040007}
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
mu...@chromium.org <mu...@chromium.org> #7
mu...@chromium.org <mu...@chromium.org> #8
gi...@appspot.gserviceaccount.com <gi...@appspot.gserviceaccount.com> #9
commit 7fffc04de2fdba9c7be9aa29aa0e09790dba77fe
Author: Mustaq Ahmed <mustaq@google.com>
Date: Wed Aug 31 21:16:56 2022
Switch mouse click target to captured element.
Bug: 1342209
Change-Id: I3e2069f8fac9c92fb96d984d9871d0a120803029
Reviewed-on:
Commit-Queue: Mustaq Ahmed <mustaq@chromium.org>
Reviewed-by: Robert Flack <flackr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1041732}
[modify]
[modify]
[modify]
[modify]
[modify]
mu...@chromium.org <mu...@chromium.org> #10
mu...@chromium.org <mu...@chromium.org> #11
is...@google.com <is...@google.com> #12
ap...@google.com <ap...@google.com> #13
Branch: main
commit fb330ffd9ed650352855d909bd5bba0b39eb13df
Author: Mustaq Ahmed <mustaq@google.com>
Date: Fri Feb 23 20:16:58 2024
[CodeHealth] Rewrite an old-style WPT using promises.
This CL rewrites pointerevent_click_during_capture.html to:
- replace a complicated state-machine logic with 4 independent
promise_tests that are easier to reason about and debug,
- renames all targets for better readablity, and
- adds a new "symmetrical" test (the 4th promise_test) that captures
the pointer to the `pointerdown` target, for completeness.
This is a no-op change.
For a captured pointer, the WPT wrongly assumes that the click event
is dispatched before the lostpointercapture event. This gap will be
fixed in the follow-up CL.
Bug: 40851596
Change-Id: I52c32afccba1faa5475ab5f5ff7d4132232ddeee
Reviewed-on:
Commit-Queue: Mustaq Ahmed <mustaq@chromium.org>
Commit-Queue: Robert Flack <flackr@chromium.org>
Reviewed-by: Robert Flack <flackr@chromium.org>
Auto-Submit: Mustaq Ahmed <mustaq@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1264710}
M third_party/blink/web_tests/external/wpt/pointerevents/pointerevent_click_during_capture.html
el...@chromium.org <el...@chromium.org> #14
Hi mustaq@! Trunk gardener here :) The test involved here (pointerevent_click_during_capture.html) is very flaky:
I'm going to disable the test.
mu...@chromium.org <mu...@chromium.org> #15
ap...@google.com <ap...@google.com> #16
Branch: main
commit f1daa0a4c1340d2b9dd102613de4993b378ded9a
Author: Elly <ellyjones@chromium.org>
Date: Wed May 01 19:01:28 2024
gardener: disable 3 pointer-related webtests
Bug: 40181907, 40851618, 40851596, 40286318
Change-Id: I26a02662ae3977ef5c4fe047e91761d55d26f92c
Reviewed-on:
Owners-Override: Elly FJ <ellyjones@chromium.org>
Commit-Queue: Ian Clelland <iclelland@chromium.org>
Auto-Submit: Elly FJ <ellyjones@chromium.org>
Reviewed-by: Ian Clelland <iclelland@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1294984}
M third_party/blink/web_tests/TestExpectations
ma...@chromium.org <ma...@chromium.org> #17
Chrome's current score in this area is 90.4%, which is the third-worst score of all of the Interop 2023 focus areas.
I've raised the priority to at least P2, but is there any chance we could prioritize fixing these three bugs within Q3? That would allow Chrome's score to get up to 100% in this area before the final stable release of 2023.
ja...@chromium.org <ja...@chromium.org> #18
I think you mean 2024 instead of 2023? But yes, this is tracked for interop 2024 so it should be fixed.
The link does say 2023 in it, but if you go to the current interop dashboard for 2024 it does in fact link to the "interop-2023-events" page:
mu...@chromium.org <mu...@chromium.org> #19
Out of the 3 issues mentioned in #17, this one is a bit risky because we think the compat implications are unknown. Mozilla seems to have the same understanding, see the relevant
mu...@chromium.org <mu...@chromium.org>
mu...@chromium.org <mu...@chromium.org>
ap...@google.com <ap...@google.com> #20
Branch: main
commit 3ee35d072331bd2b391c2eb443256f504919ad31
Author: Mustaq Ahmed <mustaq@google.com>
Date: Mon Sep 16 18:31:38 2024
[CodeHealth] Remove old runtime flag for drag on cancelled mousedown
Removing obsolete code to ease reasoning about captured click target
logic in the bug.
The flag MouseDragFromIframeOnCancelledMouseDown was enabled on
2024-01-11:
Bug: 40851596
Change-Id: Ie6d5e548bd3f29fa55a59b3bd18f1262a57b6d37
Reviewed-on:
Commit-Queue: Mustaq Ahmed <mustaq@chromium.org>
Reviewed-by: Kevin Ellis <kevers@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1355990}
M third_party/blink/renderer/core/input/event_handler.cc
M third_party/blink/renderer/core/input/mouse_event_manager.cc
M third_party/blink/renderer/core/input/mouse_event_manager.h
M third_party/blink/renderer/platform/runtime_enabled_features.json5
mu...@chromium.org <mu...@chromium.org> #21
mu...@chromium.org <mu...@chromium.org> #22
Removing the blocker issue above, a full cleanup there will affect legacy scrolling which is not in scope for Interop 2024.
ap...@google.com <ap...@google.com> #23
Branch: main
commit 6c6dda251f7ec2eb3f8734abecf42e6167421210
Author: Mustaq Ahmed <mustaq@google.com>
Date: Tue Sep 17 20:17:19 2024
[CodeHealth] Rename SetClickElement to SetMouseDownElement
MouseEventManager::SetClickElement was a misleading name: this is the
element that receives mousedown, and the click is sent to the common
ancestor of mousedown and mouseup.
Bug: 40870245, 40851596
Change-Id: Id6e53f8dc80c9f54ae0b49b120a3d6b900cd56cd
Reviewed-on:
Reviewed-by: Steve Kobes <skobes@chromium.org>
Commit-Queue: Mustaq Ahmed <mustaq@chromium.org>
Auto-Submit: Mustaq Ahmed <mustaq@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1356693}
M third_party/blink/renderer/core/input/event_handler.cc
M third_party/blink/renderer/core/input/gesture_manager.cc
M third_party/blink/renderer/core/input/mouse_event_manager.cc
M third_party/blink/renderer/core/input/mouse_event_manager.h
ap...@google.com <ap...@google.com> #24
Branch: main
commit 68e90ddc7ad2ad80fbbf442d9576e34f78081686
Author: Mustaq Ahmed <mustaq@google.com>
Date: Wed Sep 18 14:20:01 2024
[CodeHealth] Remove old flag for capture change by gotpointercapture
Removing obsolete code to ease reasoning about captured click target
logic in the bug.
The flag PointerCaptureLostOnRemovalDuringCapture was enabled on
2023-12-20:
Bug: 40851596, 40942362
Change-Id: I680165381852dc88738d416e17e803dcfc44d8bd
Reviewed-on:
Commit-Queue: Kevin Ellis <kevers@chromium.org>
Auto-Submit: Mustaq Ahmed <mustaq@chromium.org>
Reviewed-by: Kevin Ellis <kevers@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1357067}
M third_party/blink/renderer/core/input/pointer_event_manager.cc
M third_party/blink/renderer/platform/runtime_enabled_features.json5
ap...@google.com <ap...@google.com> #25
Branch: main
commit 43ee5dbb06891cd713664c7d994db58b78d8ea4e
Author: Mustaq Ahmed <mustaq@google.com>
Date: Thu Sep 19 19:20:36 2024
[CodeHealth] Simplify PEM code around compat-mouse & click dispatch
This is a no-op change to flatten the logical structure in
PointerEventManager::SendMousePointerEvent around the dispatch of
compabilibility-mouse and click-like events.
This cleanup significantly simplifies the follow-up CL which fixes the
bug by "moving" the click-like event dispatch under a flag.
Bug: 40851596
Change-Id: Ib3867a8a180256394de8d1b78e39e31a104be48d
Reviewed-on:
Reviewed-by: Kevin Ellis <kevers@chromium.org>
Commit-Queue: Mustaq Ahmed <mustaq@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1357789}
M third_party/blink/renderer/core/input/pointer_event_manager.cc
ap...@google.com <ap...@google.com> #26
Branch: main
commit 891f3707adf7b772ce5bc49b3d8978530e18e753
Author: Mustaq Ahmed <mustaq@google.com>
Date: Mon Sep 23 19:30:03 2024
[Interop] Deflake pointerevent_click_during_capture.html
The test has been flaking for the auxclick action where the
middle-click drag is probably causing autoscroll in some platforms.
This CL changes the action to use the right mouse button instead, after
suppressing any context menu invocation.
Bug: 40851596
Change-Id: I4e36b3aceb75d5edcbd0c9599ada9f7af9ef7b78
Reviewed-on:
Commit-Queue: Mustaq Ahmed <mustaq@chromium.org>
Reviewed-by: Kevin Ellis <kevers@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1358971}
M third_party/blink/web_tests/TestExpectations
M third_party/blink/web_tests/external/wpt/pointerevents/pointerevent_click_during_capture.html
ap...@google.com <ap...@google.com> #27
Project: chromium/src
Branch: main
Author: Mustaq Ahmed <
Link:
[Interop] Fix user-counter for changed click target under capture.
Expand for full commit details
[Interop] Fix user-counter for changed click target under capture.
We landed the counter for click events a while ago, then realized this
is not very precise. This CL correctly updates the count only when
there is an affected event listener and excludes auxclick events.
Bug: 40851596
Change-Id: I10e55ccbcb13ab25f710ea9edaa66bca419f2ec9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5873530
Reviewed-by: Robert Flack <flackr@chromium.org>
Commit-Queue: Mustaq Ahmed <mustaq@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1363690}
Files:
- M
third_party/blink/renderer/core/input/mouse_event_manager.cc
Hash: 49bfab42eb2c95adee4f2e718a0ebbcbe90d028d
Date: Thu Oct 03 16:31:22 2024
ap...@google.com <ap...@google.com> #28
Project: chromium/src
Branch: main
Author: Mustaq Ahmed <
Link:
Fix inspector-protocol test with middle button click.
Expand for full commit details
Fix inspector-protocol test with middle button click.
The test wrongly set `buttons = 2` on middle mouse button press event,
which was interpreted in `PointerEventManager` as "a middle button
press while right button is already down". Chrome DevTools protocol
`dispatchMouseEvent()` defines [1] the `buttons` value for middle
mouse button to be 4, matching the PointerEvent spec [2].
[1] https://chromedevtools.github.io/devtools-protocol/tot/Input/#method-dispatchMouseEvent
[2] https://w3c.github.io/pointerevents/#the-buttons-property
Bug: 40851596
Change-Id: I70433c19da0dba19e13f067419522dc7478d792d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5908229
Reviewed-by: Kevin Ellis <kevers@chromium.org>
Commit-Queue: Mustaq Ahmed <mustaq@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1363789}
Files:
- M
third_party/blink/web_tests/http/tests/inspector-protocol/page/frame-requested-navigation-disposition.js
Hash: b9667d9127442816b2031cd1ecd40ef36b8c56d2
Date: Thu Oct 03 19:31:23 2024
ap...@google.com <ap...@google.com> #29
Project: chromium/src
Branch: main
Author: Mustaq Ahmed <
Link:
[Interop] Defer PEM click dispatch to fix lostpointercapture order.
Expand for full commit details
[Interop] Defer PEM click dispatch to fix lostpointercapture order.
This CL fixes the bug by "moving" the click-like event dispatch in
PointerEventManager::SendMousePointerEvent to after processing pending
pointer capture.
Bug: 40851596
Change-Id: Iac8148d52f80bba4b727e1470e114d33bc8b2335
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5872667
Commit-Queue: Mustaq Ahmed <mustaq@chromium.org>
Reviewed-by: Robert Flack <flackr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1363830}
Files:
- M
third_party/blink/renderer/core/input/pointer_event_manager.cc
- D
third_party/blink/web_tests/external/wpt/pointerevents/pointerevent_click_during_capture_mouse-auxclick-expected.txt
- D
third_party/blink/web_tests/external/wpt/pointerevents/pointerevent_click_during_capture_mouse-click-expected.txt
- M
third_party/blink/web_tests/external/wpt/pointerevents/pointerevent_pointer_boundary_events_after_removing_last_over_element-expected.txt
Hash: af98e568bf4a2813bda3ebca7ace5498d101cd78
Date: Thu Oct 03 20:33:20 2024
mu...@chromium.org <mu...@chromium.org> #30
We are done with Interop for this.
We still need to ship to Stable, and we will wait for risk-assessment data from the UseCounter in #27.
ch...@google.com <ch...@google.com> #31
mu...@chromium.org <mu...@chromium.org> #32
mu...@chromium.org <mu...@chromium.org> #33
While working on a regression (ClickToCapturedPointer
enabled, the corresponding call
ap...@google.com <ap...@google.com> #34
Project: chromium/src
Branch: main
Author: Mustaq Ahmed <
Link:
Fix noisy event modifiers when UI events are converted to Blink events
Expand for full commit details
Fix noisy event modifiers when UI events are converted to Blink events
Certain mouse-input devices are known to send mouse events whose
modifiers don't always match the state implied by the changed
(pressed/released) buttons. While the bad modifiers are not
exposed to JS event's button/buttons fields, internal Blink
plumbing may behave erratically with this state.
This CL:
- adds a fix where Blink WebInputEvents are first created from UI
events (for events seen in production), and
- completes an existing fix "in the middle" of Blink event path
(for events injected in testing).
Fixed: 378451943
Bug: 40851596
Change-Id: I0d7a496d0ab76089d68b653daaebd41dfae11fc9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6049401
Reviewed-by: Robert Flack <flackr@chromium.org>
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Auto-Submit: Mustaq Ahmed <mustaq@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1391250}
Files:
- M
third_party/blink/common/input/web_mouse_event.cc
- M
third_party/blink/public/common/input/web_mouse_event.h
- M
third_party/blink/renderer/core/events/web_input_event_conversion.cc
- M
third_party/blink/renderer/platform/runtime_enabled_features.json5
- M
ui/events/blink/web_input_event.cc
- M
ui/events/blink/web_input_event_unittest.cc
Hash: c64a28550d1db731800235aaa3cc884f0dad8d01
Date: Tue Dec 03 21:35:15 2024
pe...@google.com <pe...@google.com> #35
The NextAction date has arrived: 2024-12-09 To opt-out from this automation rule, please add Optout-Blintz-Nextaction-Alert to the "Chromium Labels" custom field.
ap...@google.com <ap...@google.com> #36
Project: chromium/src
Branch: main
Author: Mustaq Ahmed <
Link:
[Interop] WPT and fix for click dispatch with chorded buttons.
Expand for full commit details
[Interop] WPT and fix for click dispatch with chorded buttons.
This CL adds a WPT for click-like events from chorded buttons, which
is currently being discussed in PEWG as an Interop problem:
https://github.com/w3c/pointerevents/issues/530
The CL also fixes a behind-a-flag crack in Chromium. The crack
prevented firing of click-like events with the chorded buttons when
ClickToCapturedPointer is enabled. This is because the call to
`DispatchMouseClickIfNeeded` is wrongly skipped in this case since
the `pointer_event->type()` is `kPointermove` not `kPointerup`.
Bug: 40851596
Change-Id: I11606ed8f709f08aaa2d8aba3ebaeb07f26bbc1f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6059955
Reviewed-by: Robert Flack <flackr@chromium.org>
Auto-Submit: Mustaq Ahmed <mustaq@chromium.org>
Commit-Queue: Robert Flack <flackr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1395404}
Files:
- M
third_party/blink/renderer/core/input/pointer_event_manager.cc
- A
third_party/blink/web_tests/external/wpt/pointerevents/pointerevent_click_on_chorded_mouse_button.tentative-expected.txt
- A
third_party/blink/web_tests/external/wpt/pointerevents/pointerevent_click_on_chorded_mouse_button.tentative.html
Hash: 3ea0fd9f4dc5db87d3491422f968c4d331bbc002
Date: Thu Dec 12 07:18:08 2024
mu...@chromium.org <mu...@chromium.org> #37
While we don't anticipate any compat problem, the use-counter for possible regressions came out a bit too high and it is not easy to eliminate the false positives there.
The use-counter seems to suggest that at most 0.16%~0.23% page loads are affected (
We decided to go with field trials for risk assessment. We are hoping to kick off a Canary+Dev trial soon and gradually ramp it up over the next few months.
ap...@google.com <ap...@google.com> #38
Project: chromium/src
Branch: main
Author: Mustaq Ahmed <
Link:
Interop: fieldtrial_testing_config for ClickToCapturedPointer
Expand for full commit details
Interop: fieldtrial_testing_config for ClickToCapturedPointer
We want to assess the compat risk for this feature through a field
trial. We are hoping to kick off a Canary+Dev trial soon.
While we don't anticipate any compat problem, the use-counter for
possible regressions came out a bit too high and it is not easy to
eliminate the false positives there.
Bug: 40851596
Change-Id: Ifb285c5527aa6e9fd417dea012360d4f2b948386
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6105932
Commit-Queue: Vladimir Levin <vmpstr@chromium.org>
Commit-Queue: Mustaq Ahmed <mustaq@chromium.org>
Auto-Submit: Mustaq Ahmed <mustaq@chromium.org>
Reviewed-by: Vladimir Levin <vmpstr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1397947}
Files:
- M
testing/variations/fieldtrial_testing_config.json
Hash: 52a3f6422be4a6a78dcd401a8f58627f72601f32
Date: Wed Dec 18 07:46:19 2024
pe...@google.com <pe...@google.com> #39
The NextAction date has arrived: 2025-01-08 To opt-out from this automation rule, please add Optout-Blintz-Nextaction-Alert to the "Chromium Labels" custom field.
mu...@chromium.org <mu...@chromium.org> #40
The feature has been active as a 50% Canary+Beta trial for 2 weeks and we haven't seen any bug reports. We are watching
We are planning to expand the trial to include 1% stable soon.
mu...@chromium.org <mu...@chromium.org> #41
mu...@chromium.org <mu...@chromium.org> #42
The intent to ship got approved today. We are enabling it for 1% Stable in a day or two.
mu...@chromium.org <mu...@chromium.org> #43
No bug reports yet, ramping this up to 10% Stable today.
mu...@chromium.org <mu...@chromium.org> #44
Without any bug reports in a week of 10% Stable, we are enabling it on ToT today.
ap...@google.com <ap...@google.com> #45
Project: chromium/src
Branch: main
Author: Mustaq Ahmed <
Link:
[Interop] Enable ClickToCapturedPointer on ToT
Expand for full commit details
[Interop] Enable ClickToCapturedPointer on ToT
The feature dispatches a click to the captured pointer target, instead
of the common ancestor of pointerdown and pointerup targets.
We didn't see any compat report while we gradually expanded the finch
coverage.
Intent to Ship: https://groups.google.com/a/chromium.org/g/blink-dev/c/o1fXBdt94iA/m/NzBAK2o_AAAJ
Bug: 40851596
Change-Id: I41056cd0067139af4b796c0d5a50e55964d6ad44
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6336606
Auto-Submit: Mustaq Ahmed <mustaq@chromium.org>
Reviewed-by: Vladimir Levin <vmpstr@chromium.org>
Commit-Queue: Vladimir Levin <vmpstr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1430345}
Files:
- M
third_party/blink/renderer/platform/runtime_enabled_features.json5
Hash: 76aefeea1c2c6fe07cfb43228415314031f0a034
Date: Mon Mar 10 10:45:25 2025
Description
This is the correct order by PEWG consensus, but the target for the click is wrong. See Case2 and Case4 in [1].
More details: Chrome dispatches the click event to the nearest common ancestor of pointerdown and pointerup events which follows the old UI Event spec behavior (defined before the pointer capture concept was spec-ed). In this spec discussion, PEWG agreed that the click dispatched to the pointer-capture target is the right solution from web developers' perspective.
[1]