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/a3aa3f2c-210b-4c62-97b0-360b51da787bn%40chromium.org.
