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 < shuangshuang.z...@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+unsubscr...@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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJ6LnKsLS2cU_ur1ORD3UUS9S_%3DAgV5DHev58b3UfO_uA%40mail.gmail.com.
