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 <[email protected]> >> *Sent:* Friday, May 24, 2024 12:26 AM >> *To:* blink-dev <[email protected]> >> *Cc:* Shuangshuang Zhou <[email protected]>; [email protected] < >> [email protected]>; [email protected] <[email protected]>; Daniel >> Clark <[email protected]>; Olli Pettay <[email protected]> >> *Subject:* Re: [blink-dev] Intent to Ship: Dispatch selectionchange >> event per element >> >> >> >> You don't often get email from [email protected]. 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 [email protected] 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 <[email protected]> >> 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 [email protected] 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 <[email protected]> >> *Sent:* Wednesday, May 22, 2024 9:53 AM >> *To:* blink-dev <[email protected]> >> *Cc:* Daniel Clark <[email protected]>; Shuangshuang Zhou < >> [email protected]> >> *Subject:* Re: [blink-dev] Intent to Ship: Dispatch selectionchange >> event per element >> >> >> >> You don't often get email from [email protected]. 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:* [email protected] <[email protected]> *On Behalf Of >> *Shuangshuang >> Zhou >> *Sent:* Tuesday, May 21, 2024 10:24 PM >> *To:* blink-dev <[email protected]> >> *Subject:* [blink-dev] Intent to Ship: Dispatch selectionchange event >> per element >> >> >> >> You don't often get email from [email protected]. Learn why this is >> important <https://aka.ms/LearnAboutSenderIdentification> >> >> *Contact **emails*[email protected] >> >> *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 [email protected]. >> 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 [email protected]. >> >> 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 [email protected]. >> >> 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 [email protected]. 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.
