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.

Reply via email to