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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c8bb2e50-31de-413a-8099-d807535420e6n%40chromium.org.