New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 879261 link

Starred by 1 user
Status: Fixed
Owner:
rbpotter@chromium.org
Closed: Oct 31
Cc:
█ kschaaf@chromium.org
dpa...@chromium.org
hayato@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 2
Type: Bug

Blocking:
issue 738611
issue 896580



Sign in to add a comment

Input event composed flag not set correctly

Project Member Reported by rbpotter@chromium.org, Aug 30 
The composed flag for input events should be set to true by default (see https://github.com/w3c/webcomponents/issues/513). However, this is not the case for some input events fired from number inputs. The flag is set to true when the value is changed by typing a new value with the keyboard, but if it is changed by clicking on the up/down buttons or by pressing the up/down arrow keys, the composed flag is set to false.

A test case demonstrating this issue can be found at: http://jsfiddle.net/umxtkdah/ 
To test, change the value using the arrow keys, up/down buttons, or by typing a new value. The composed: value for the event that is printed out changes based on how the value is modified.

Tested in 68.0.3440.106 Stable on Linux.

This impacts Polymer 2 migration for Web UI, since in web components v1 events without composed: true are not observable outside the shadow root they are fired in.

Comment 1 by dpa...@chromium.org, Sep 6

Components: Blink>DOM>ShadowDOM
Labels: OS-Chrome OS-Linux OS-Mac OS-Windows
Found the two different codepaths in Blink that cause the difference in behavior.

When the arrow buttons are clicked, or the up/down keys are pressed, Node::DispatchInputEvent at [1] executes, which does not set the "composed" flag.

When the user actually types some text in the input, InputEvent::CreateInput at [2] executes, which always sets the flag to true. 

[1] https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/dom/node.cc?l=2404
[2] https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/events/input_event.cc?l=148,164

Adding the ShadowDOM component, since this affects code that uses it.

Comment 2 by dpa...@chromium.org, Sep 6 

FYI, a naive fix is at https://chromium-review.googlesource.com/c/chromium/src/+/1211669. This fixes the issue depicted in the provided minimal examples, but unclear yet if it creates any other issues.

Comment 3 by dpa...@chromium.org, Sep 6

Blocking: 738611

Comment 4 by tkent@chromium.org, Sep 12

Components: -Blink>Input Blink>Forms>Number
Status: Available (was: Untriaged)

Comment 5 by rbpotter@chromium.org, Oct 18

Blocking: 896580
Project Member

Comment 6 by bugdroid1@chromium.org, Oct 30 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/146a312eb07698ae580ddfa07a640ba24ead58f4

commit 146a312eb07698ae580ddfa07a640ba24ead58f4
Author: rbpotter <rbpotter@chromium.org>
Date: Tue Oct 30 18:41:53 2018

Ensure 'input' event always fires with the 'composed' flag true.

Bug:  879261 
Change-Id: I5513a889df874bef4157245d7ad7454e79777cfa
Reviewed-on: https://chromium-review.googlesource.com/c/1211669
Reviewed-by: Hayato Ito <hayato@chromium.org>
Reviewed-by: Kent Tamura <tkent@chromium.org>
Commit-Queue: Rebekah Potter <rbpotter@chromium.org>
Cr-Commit-Position: refs/heads/master@{#603973}
[add] https://crrev.com/146a312eb07698ae580ddfa07a640ba24ead58f4/third_party/WebKit/LayoutTests/fast/forms/number/number-input-event-composed.html
[modify] https://crrev.com/146a312eb07698ae580ddfa07a640ba24ead58f4/third_party/blink/renderer/core/dom/node.cc

Comment 7 by dpa...@chromium.org, Oct 31

Owner: rbpotter@chromium.org
Status: Fixed (was: Available)

Comment 8 by tkent@chromium.org, Oct 31

Labels: Target-72
►

Sign in to add a comment