Thanks Gaurang for reporting this. We're now looking into this issue. It seems that the fired selectionchange event on the shadow node cannot propagate across the shadow DOM boundary into the standard DOM. We'll update directlty in the attached issue.
Thanks! On Friday, June 14, 2024 at 1:25:05 AM UTC+8 gau...@blaze.today wrote: > Hi all! I believe this CL has an unintentional behavior change for <input> > elements inside shadow roots (open/closed). I have filed a detailed bug > report here https://issues.chromium.org/issues/346898523 In brief, the > issue is: when an <input> element is inside a shadow root, then its > selectionchange event does not reach the top-level document. It stops at > the shadow root itself. This is a new change in Chrome 127 (it worked fine > in Chrome 126). > > This behavior change is an issue for existing Chrome extensions that > depend on this behavior. Considering the urgency of this issue, I thought > its best to email the group directly to ask if this change is intentional. > I hope this is the right place to highlight this issue. > > Thanks, > Gaurang > On Tuesday 4 June, 2024 at 12:41:11 pm UTC+5:30 shuangsh...@intel.com > wrote: > >> Hi all, thanks for all the comments and LGTMs. >> >> Let's moving on to the second CL. >> >> Thanks! >> >> On Saturday, June 1, 2024 at 3:46:08 AM UTC+8 Chris Harrelson wrote: >> >>> LGTM3 for the first CL >>> >>> On Thu, May 30, 2024 at 6:22 PM Domenic Denicola <dom...@chromium.org> >>> wrote: >>> >>>> LGTM2, to land the first CL. >>>> >>>> Thanks for explaining. It sounds like the first CL, which this Intent >>>> is covering, is purely additive and should not have significant >>>> compatibility risk. It also brings us in line with the behavior Firefox >>>> has >>>> had for a long time, and the behavior that WebKit has recently adopted. >>>> >>>> I look forward to your second Intent to Ship for the second CL, which >>>> will require more caution. >>>> >>>> On Thursday, May 30, 2024 at 4:52:23 PM UTC+9 shuangsh...@intel.com >>>> wrote: >>>> >>>>> Hi Yoav&Alex, thanks for the feedback. I'll make it more clear. >>>>> >>>>> Generally speaking, the final goal is that, we want to avoid queuing a >>>>> task to dispatch a selectionchange event when there is already a task >>>>> scheduled to do that. This is to catch up the latest spec: >>>>> https://w3c.github.io/selection-api/#scheduling-selectionhange-event. >>>>> Currently we divide this into 2 steps with one CL for each step to >>>>> impelment this goal. >>>>> >>>>> In this issue, we'd like to land *the first CL* that updates the >>>>> implementation of selectionchange event to be fired on input element and >>>>> textarea element instead of document. So the difference in the first CL >>>>> is: >>>>> >>>>> 1. The old behaviour: When the element(input/textarea) provides a >>>>> text selectionchange or its selection changes, we dispatch a >>>>> selectionchange event on the document directly. >>>>> 2. The new behaviour: The new codes goes to that, in the same >>>>> situations, if the selection changes, we fire this event first on the >>>>> element(input/textarea) itself, and then it would be bubbled to the >>>>> doument. >>>>> >>>>> >>>>> So, the final results are the same that, we finally get a >>>>> selectionchange event on the document. *The feature in this issue* is >>>>> mainly to do this change. After the first CL is landed, then we come to >>>>> the >>>>> second CL. The main change of the behaviour would be in the second CL. >>>>> >>>>> In *the second CL*, we will change the behaviour: >>>>> >>>>> 1. The old behaviour: When the element(input/textarea) provides a >>>>> text selectionchange or its selection changes, we dispatch a >>>>> selectionchange event on the element. We don't care whether this event >>>>> is >>>>> executed, and we just dipatch it. >>>>> 2. The new behaviour: Now based on the new spec( >>>>> https://w3c.github.io/selection-api/#scheduling-selectionhange-event), >>>>> we dispatch this event only when there is no scheduled one in the >>>>> queue. If >>>>> we have already scheduled one but not get callbacked, we would skip to >>>>> dispatch this event. >>>>> >>>>> To sum up, in this issue or mail thread, we only focus on what we did >>>>> in the first CL. So previouly we think this is low-risk because we don't >>>>> change anything at all. The real impact would happen in the second CL. So >>>>> for the compat risk or maybe the potential for site breakage, maybe we >>>>> could collect these data in the second CL. >>>>> >>>>> These are the main difference between the first CL and the second CL. >>>>> If you have any other concerns, feel free to ping me! >>>>> >>>>> Thanks! >>>>> >>>>> On Wednesday, May 29, 2024 at 11:52:57 PM UTC+8 sligh...@chromium.org >>>>> wrote: >>>>> >>>>>> hey folks, >>>>>> >>>>>> We spent a lot of time in API OWNERs today trying to understand this >>>>>> change, and we couldn't crisply describe: >>>>>> >>>>>> >>>>>> - What the old behaviour was >>>>>> - What the new behaviour is going to be >>>>>> - If we've analysed the potential for site breakage, and if not, >>>>>> if we should be adding usecounters ahead of the change >>>>>> >>>>>> Most of this is stuff we'd expect to see in an Explainer. Is it >>>>>> possible to produce one? Seeing example code for whatw this improves >>>>>> would >>>>>> be helpful. >>>>>> >>>>>> Best, >>>>>> >>>>>> Alex >>>>>> >>>>>> On Wednesday, May 29, 2024 at 1:43:00 AM UTC-7 Yoav Weiss wrote: >>>>>> >>>>>>> I'm sorry, but re-reading this, I realized that I don't fully >>>>>>> understand this change and the plan here. >>>>>>> Can you elaborate on: >>>>>>> * What is the behavior change that we want to drive here? >>>>>>> * Which part of that would be covered by the first CL? which by the >>>>>>> second? >>>>>>> * Where do we predict compat risk here? How can we estimate it? >>>>>>> >>>>>>> Thanks! :) >>>>>>> >>>>>>> >>>>>>> On Tue, May 28, 2024 at 1:54 AM Shuangshuang Zhou < >>>>>>> shuangsh...@intel.com> wrote: >>>>>>> >>>>>>>> Hi Yoav, thanks for the question! From chromium's side, currently I >>>>>>>> don't have any usecounters to trace how many sites would be impacted. >>>>>>>> I >>>>>>>> checked WebKit' status, seems they don't have any data. Maybe Olli >>>>>>>> could >>>>>>>> comment this from Gecko's side. >>>>>>>> >>>>>>>> Since the first CL doesn't change the original logic, we might >>>>>>>> collect some data in the second CL(avoid to dispatch events that are >>>>>>>> already scheduled but not executed). >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> On Monday, May 27, 2024 at 3:08:29 PM UTC+8 yoav...@chromium.org >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Given Olli's comments on this change being backwards-incompatible, >>>>>>>>> do we have any data on how many sites would be impacted? Any >>>>>>>>> usecounters to >>>>>>>>> that effect? >>>>>>>>> >>>>>>>>> On Mon, May 27, 2024 at 2:19 AM Shuangshuang Zhou < >>>>>>>>> shuangsh...@intel.com> wrote: >>>>>>>>> >>>>>>>>>> Thanks Olli for the implement in Gecko side, and also Dan's >>>>>>>>>> comment! >>>>>>>>>> >>>>>>>>>> Hi Mike, would you please take a look and give some suggestion? >>>>>>>>>> Also, seems we need 3 LGTMs, Kent or Mike, would you add another >>>>>>>>>> reviewer >>>>>>>>>> to to take a review? >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> On Saturday, May 25, 2024 at 1:05:59 AM UTC+8 Olli Pettay wrote: >>>>>>>>>> >>>>>>>>>>> I am trying to land the change, so it should be in FF 128 >>>>>>>>>>> Nightly soon, next week at latest. So hopefully we'll get feedback >>>>>>>>>>> if it >>>>>>>>>>> breaks something. >>>>>>>>>>> I don't think there is need for a standards-position for this >>>>>>>>>>> particular small tweak. >>>>>>>>>>> (But the process of making this kind of breaking spec change was >>>>>>>>>>> rather unusual.) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -Olli >>>>>>>>>>> >>>>>>>>>>> On Friday, May 24, 2024 at 7:55:44 PM UTC+3 Daniel Clark wrote: >>>>>>>>>>> >>>>>>>>>>>> Thanks Shuangshuang for clarifying what’s going on with these >>>>>>>>>>>> two separate but related changes, and Olli for the update on >>>>>>>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1898343. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Since Gecko already implements the behavior of firing >>>>>>>>>>>> selectionchange on input/textarea (confirmed here >>>>>>>>>>>> <https://glow-curvy-cerise.glitch.me/>), sounds good to me to >>>>>>>>>>>> go ahead with shipping this change in Chromium (I’m not an API >>>>>>>>>>>> owner >>>>>>>>>>>> though). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Separately, for the behavior of not firing duplicate >>>>>>>>>>>> selectionchange, it might not hurt to go ahead and request an >>>>>>>>>>>> official >>>>>>>>>>>> Mozilla position on that since it sounds like there’s still a bit >>>>>>>>>>>> of >>>>>>>>>>>> uncertainty about landing that change given back compat concerns, >>>>>>>>>>>> unless >>>>>>>>>>>> Olli confirms here that the plan is to go ahead and ship it. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- Dan >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *From:* Olli Pettay <ope...@mozilla.com> >>>>>>>>>>>> *Sent:* Friday, May 24, 2024 12:26 AM >>>>>>>>>>>> *To:* blink-dev <blin...@chromium.org> >>>>>>>>>>>> *Cc:* Shuangshuang Zhou <shuangsh...@intel.com>; >>>>>>>>>>>> tk...@chromium.org <tk...@chromium.org>; mike...@chromium.org < >>>>>>>>>>>> mike...@chromium.org>; Daniel Clark <dan...@microsoft.com>; >>>>>>>>>>>> Olli Pettay <ope...@mozilla.com> >>>>>>>>>>>> *Subject:* Re: [blink-dev] Intent to Ship: Dispatch >>>>>>>>>>>> selectionchange event per element >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> You don't often get email from ope...@mozilla.com. Learn why >>>>>>>>>>>> this is important >>>>>>>>>>>> <https://aka.ms/LearnAboutSenderIdentification> >>>>>>>>>>>> >>>>>>>>>>>> FWIW, I'm implementing the change in >>>>>>>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1898343 >>>>>>>>>>>> >>>>>>>>>>>> Need to still fix some tests, which do reveal how the spec >>>>>>>>>>>> change indeed isn't fully backwards compatible. >>>>>>>>>>>> >>>>>>>>>>>> Hopefully it doesn't break any real web sites. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -Olli >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Friday, May 24, 2024 at 10:05:47 AM UTC+3 Shuangshuang Zhou >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Dan&Mike, I think we could submit a standard-position issue >>>>>>>>>>>> to Mozilla for reducing duplicated events in our second >>>>>>>>>>>> CL(mentioned in my >>>>>>>>>>>> last comment) for this feature. Because in the second CL, we might >>>>>>>>>>>> change >>>>>>>>>>>> the current logic of dispatching selectionchange event. For this >>>>>>>>>>>> time, we >>>>>>>>>>>> might just do it in chromium. WDYT? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks! >>>>>>>>>>>> >>>>>>>>>>>> On Friday, May 24, 2024 at 9:20:33 AM UTC+8 tk...@chromium.org >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> LGTM1. >>>>>>>>>>>> >>>>>>>>>>>> Firefox and Safari statuses are strong signals, and the >>>>>>>>>>>> compatibility risk looks very low. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, May 23, 2024 at 11:07 AM Shuangshuang Zhou < >>>>>>>>>>>> shuangsh...@intel.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Dan&Mike, for your concern that Firefox is still failing >>>>>>>>>>>> the WPTs at >>>>>>>>>>>> https://wpt.fyi/results/selection/onselectionchange-on-distinct-text-controls.html, >>>>>>>>>>>> >>>>>>>>>>>> that might be another issue. Let me make more explanation. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Actually, the final goal of w3c modifys the spec of >>>>>>>>>>>> selectionchange event is to avoid firing duplicated >>>>>>>>>>>> selectionchange event >>>>>>>>>>>> which are not executed yet on the same element(as Rniwa commented >>>>>>>>>>>> in his >>>>>>>>>>>> comment >>>>>>>>>>>> <https://github.com/w3c/selection-api/issues/170#issuecomment-1956096554>). >>>>>>>>>>>> >>>>>>>>>>>> Then in WebKit/WebCore, Rniwa submitted 2 CLs to achieve this >>>>>>>>>>>> ieda. The >>>>>>>>>>>> first CL in WebKit is 276238@main >>>>>>>>>>>> <https://commits.webkit.org/276238@main>, and in this CL they >>>>>>>>>>>> just modified the logic to fire selectionchange event on >>>>>>>>>>>> input/textarea for >>>>>>>>>>>> the first step. Then the second CL in WebKit is 276388@main >>>>>>>>>>>> <https://commits.webkit.org/276388@main>, which finally >>>>>>>>>>>> avoided to fire duplicated selectionchange events according to the >>>>>>>>>>>> latest >>>>>>>>>>>> spec on firing selectionchange event >>>>>>>>>>>> <https://w3c.github.io/selection-api/#firing-selectionhange-event> >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> So for this feature in Blink here , we also want to take 2 >>>>>>>>>>>> steps like WebKit does that in the first CL we change to fire on >>>>>>>>>>>> input/textarea and then sovle the duplicated events in the second >>>>>>>>>>>> CL. And >>>>>>>>>>>> those tests are already modified to what both CLs are merged. So >>>>>>>>>>>> in the >>>>>>>>>>>> above test of onselectionchange-on-distinct-text-controls.html, >>>>>>>>>>>> chrome and >>>>>>>>>>>> firefox should be failed because only Safari has landed 2 CLs to >>>>>>>>>>>> avoid >>>>>>>>>>>> duplicated selectionchange events. Or in other words, firefox >>>>>>>>>>>> might already >>>>>>>>>>>> dispatch selectionchange event on elements but doesn't have the >>>>>>>>>>>> logic to >>>>>>>>>>>> avoid to fire scheduled-but-not-executed events. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> For WebKit, currently the two CLs are both landed in Safari >>>>>>>>>>>> Technology Preview 192(link >>>>>>>>>>>> <https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-192>), >>>>>>>>>>>> >>>>>>>>>>>> but it might need some time to ship in Safari because Safari is >>>>>>>>>>>> updated >>>>>>>>>>>> within OS updates. >>>>>>>>>>>> >>>>>>>>>>>> For the status in FireFox, I'll double-check and confirm with >>>>>>>>>>>> Tkent(one reviewer of my first CL). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Shuangshuang >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thursday, May 23, 2024 at 9:29:59 AM UTC+8 >>>>>>>>>>>> mike...@chromium.org wrote: >>>>>>>>>>>> >>>>>>>>>>>> Yes, agree. Can we please request a position from Mozilla at >>>>>>>>>>>> https://github.com/mozilla/standards-positions/issues/new? >>>>>>>>>>>> >>>>>>>>>>>> On 5/22/24 6:43 PM, 'Daniel Clark' via blink-dev wrote: >>>>>>>>>>>> >>>>>>>>>>>> Yeah, that’s what I was trying to get at – the Intent implies >>>>>>>>>>>> that Gecko has also shipped the breaking change but it seems that >>>>>>>>>>>> might not >>>>>>>>>>>> be the case. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> If not, we should send a Request for Position to figure out >>>>>>>>>>>> whether there would be cross-browser alignment on shipping this. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- Dan >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *From:* Olli Pettay <ope...@mozilla.com> >>>>>>>>>>>> *Sent:* Wednesday, May 22, 2024 9:53 AM >>>>>>>>>>>> *To:* blink-dev <blin...@chromium.org> >>>>>>>>>>>> *Cc:* Daniel Clark <dan...@microsoft.com>; Shuangshuang Zhou < >>>>>>>>>>>> shuangsh...@intel.com> >>>>>>>>>>>> *Subject:* Re: [blink-dev] Intent to Ship: Dispatch >>>>>>>>>>>> selectionchange event per element >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> You don't often get email from ope...@mozilla.com. Learn why >>>>>>>>>>>> this is important >>>>>>>>>>>> <https://aka.ms/LearnAboutSenderIdentification> >>>>>>>>>>>> >>>>>>>>>>>> I think it is because of this rather surprising non-backwards >>>>>>>>>>>> compatible recent change. >>>>>>>>>>>> >>>>>>>>>>>> On Wednesday, May 22, 2024 at 7:28:45 PM UTC+3 Daniel Clark >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> The Gecko status is marked as Shipped/Shipping and the >>>>>>>>>>>> Interop/Compat section mentions Firefox having shipped this, but >>>>>>>>>>>> Firefox is >>>>>>>>>>>> still failing the WPTs at >>>>>>>>>>>> https://wpt.fyi/results/selection/onselectionchange-on-distinct-text-controls.html >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>>> Can you help me understand the discrepancy there? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Dan >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *From:* blin...@chromium.org <blin...@chromium.org> *On Behalf >>>>>>>>>>>> Of *Shuangshuang Zhou >>>>>>>>>>>> *Sent:* Tuesday, May 21, 2024 10:24 PM >>>>>>>>>>>> *To:* blink-dev <blin...@chromium.org> >>>>>>>>>>>> *Subject:* [blink-dev] Intent to Ship: Dispatch >>>>>>>>>>>> selectionchange event per element >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> You don't often get email from shuangsh...@intel.com. Learn >>>>>>>>>>>> why this is important >>>>>>>>>>>> <https://aka.ms/LearnAboutSenderIdentification> >>>>>>>>>>>> >>>>>>>>>>>> *Contact **emails*shuangsh...@intel.com >>>>>>>>>>>> >>>>>>>>>>>> *Explainer*None >>>>>>>>>>>> >>>>>>>>>>>> *Specification* >>>>>>>>>>>> https://w3c.github.io/selection-api/#selectionchange-event >>>>>>>>>>>> >>>>>>>>>>>> *Summary* >>>>>>>>>>>> >>>>>>>>>>>> Dispatches selectionchange event per element when this >>>>>>>>>>>> element(input/textarea) provides a text selection or its selection >>>>>>>>>>>> changes. >>>>>>>>>>>> This is to match the latest specification of selectionchange >>>>>>>>>>>> event. This >>>>>>>>>>>> also matches Safari behavior. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *Blink component*Blink>Editing>Selection >>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EEditing%3ESelection> >>>>>>>>>>>> >>>>>>>>>>>> *TAG review*None >>>>>>>>>>>> >>>>>>>>>>>> *TAG review status*Issues addressed >>>>>>>>>>>> >>>>>>>>>>>> *Risks* >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *Interoperability and Compatibility* >>>>>>>>>>>> >>>>>>>>>>>> Interoperability risk is low because Firefox and Safari have >>>>>>>>>>>> shipped this according to the specification. Compatibility risk is >>>>>>>>>>>> low >>>>>>>>>>>> because the selectionchange event targeting input/textarea would >>>>>>>>>>>> bubble up, >>>>>>>>>>>> and existing codes listening on Document will work well as ever. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *Gecko*: Shipped/Shipping >>>>>>>>>>>> >>>>>>>>>>>> *WebKit*: Shipped/Shipping ( >>>>>>>>>>>> https://commits.webkit.org/276238@main) >>>>>>>>>>>> >>>>>>>>>>>> *Web developers*: No signals >>>>>>>>>>>> >>>>>>>>>>>> *Other signals*: >>>>>>>>>>>> >>>>>>>>>>>> *WebView application risks* >>>>>>>>>>>> >>>>>>>>>>>> *Does this intent deprecate or change behavior of existing >>>>>>>>>>>> APIs, such that it has potentially high risk for Android >>>>>>>>>>>> WebView-based >>>>>>>>>>>> applications?* >>>>>>>>>>>> >>>>>>>>>>>> Low WebView application risks. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *Debuggability* >>>>>>>>>>>> >>>>>>>>>>>> None >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *Will this feature be supported on all six Blink platforms >>>>>>>>>>>> (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?* >>>>>>>>>>>> Yes >>>>>>>>>>>> >>>>>>>>>>>> *Is this feature fully tested by **web-platform-tests* >>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>>>>> *?*Yes >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> https://wpt.fyi/results/selection/onselectionchange-on-distinct-text-controls.html >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *Flag name on chrome://flags*None >>>>>>>>>>>> >>>>>>>>>>>> *Finch feature name*DispatchSelectionchangeEventPerElement >>>>>>>>>>>> >>>>>>>>>>>> *Requires code in //chrome?*False >>>>>>>>>>>> >>>>>>>>>>>> *Tracking bug*https://issues.chromium.org/issues/330766600 >>>>>>>>>>>> >>>>>>>>>>>> *Estimated milestones* >>>>>>>>>>>> Shipping on desktop >>>>>>>>>>>> 127 >>>>>>>>>>>> >>>>>>>>>>>> *Anticipated spec changes* >>>>>>>>>>>> >>>>>>>>>>>> *Open questions about a feature may be a source of future web >>>>>>>>>>>> compat or interop issues. Please list open issues (e.g. links to >>>>>>>>>>>> known >>>>>>>>>>>> github issues in the project for the feature specification) whose >>>>>>>>>>>> resolution may introduce web compat/interop risk (e.g., changing >>>>>>>>>>>> to naming >>>>>>>>>>>> or structure of the API in a non-backward-compatible way).* >>>>>>>>>>>> >>>>>>>>>>>> None >>>>>>>>>>>> >>>>>>>>>>>> *Link to entry on the Chrome Platform Status* >>>>>>>>>>>> https://chromestatus.com/feature/5255454895898624?gate=6043023317401600 >>>>>>>>>>>> >>>>>>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>>>>>> <https://chromestatus.com/>. >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>>> Google Groups "blink-dev" group. >>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from >>>>>>>>>>>> it, send an email to blink-dev+...@chromium.org. >>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/de18f3c4-df5a-4423-80ec-e505e0c9fb2bn%40chromium.org >>>>>>>>>>>> >>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/de18f3c4-df5a-4423-80ec-e505e0c9fb2bn%40chromium.org?utm_medium=email&utm_source=footer> >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>>> Google Groups "blink-dev" group. >>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from >>>>>>>>>>>> it, send an email to blink-dev+...@chromium.org. >>>>>>>>>>>> >>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/PH8PR00MB1445785C11C8FCA346EAE963C5EB2%40PH8PR00MB1445.namprd00.prod.outlook.com >>>>>>>>>>>> >>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/PH8PR00MB1445785C11C8FCA346EAE963C5EB2%40PH8PR00MB1445.namprd00.prod.outlook.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>>> Google Groups "blink-dev" group. >>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from >>>>>>>>>>>> it, send an email to blink-dev+...@chromium.org. >>>>>>>>>>>> >>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2d3b76b1-890f-4a07-961a-ef813c14eef3n%40chromium.org >>>>>>>>>>>> >>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2d3b76b1-890f-4a07-961a-ef813c14eef3n%40chromium.org?utm_medium=email&utm_source=footer> >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> TAMURA Kent >>>>>>>>>>>> Software Engineer, Google >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>> Google Groups "blink-dev" group. >>>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>>> send an email to blink-dev+...@chromium.org. >>>>>>>>>> >>>>>>>>> To view this discussion on the web visit >>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b17e9c59-e826-44e3-9a52-e24067f1cbc9n%40chromium.org >>>>>>>>>> >>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b17e9c59-e826-44e3-9a52-e24067f1cbc9n%40chromium.org?utm_medium=email&utm_source=footer> >>>>>>>>>> . >>>>>>>>>> >>>>>>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "blink-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to blink-dev+...@chromium.org. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e2d678cb-a4ae-4856-8518-161b8a3ffc38n%40chromium.org >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e2d678cb-a4ae-4856-8518-161b8a3ffc38n%40chromium.org?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bdc56314-ec85-4c23-8045-0062734b9594n%40chromium.org.
