LGTM3 I agree with Philip that it would ideally be testable in WPT but filing an issue to track the omission is good enough for me for now.
On Wed, Nov 19, 2025 at 11:19 AM Philip Jägenstedt <[email protected]> wrote: > LGTM2 > > On testing, I see that the key piece is internals.addTextMatchMarker here: > > https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/wpt_internal/css/support/markers.js;l=29-36;drc=f3fae8c3c1c805156cf7a5a8124db274bdd7c355 > > Defining a WebDriver BiDi command for this is probably straightforward, > although I'm not aware of CSS specs defining WebDriver BiDi commands in the > style of https://w3c.github.io/webauthn/#sctn-automation. If you'd like > to do this it would be great, but I also think it's OK to just file an > issue at > https://github.com/web-platform-tests/wpt/issues?q=is%3Aissue%20state%3Aopen%20label%3Atype%3Auntestable > and do it if there's a second feature that needs it, or a second > implementer that requests it. > > On Wed, Nov 19, 2025 at 5:10 PM Mike Taylor <[email protected]> > wrote: > >> LGTM1 >> On 11/17/25 2:54 p.m., Stephen Chenney wrote: >> >> Hi folks, >> >> I'm finally back to this. I just spent some time looking for further >> sources of developer and user needs for this feature. >> >> One use-case I had not previously appreciated is in user-facing contrast >> adjustment for find-in-page results. With ::search-text an extension could >> provide functionality to adjust the colors. >> >> I've updated the chromestatus entry to add three more developer notes: >> >> - On the original CSS WG issue someone wants this to avoid conflicts >> with the ECMAScript spec highlights. >> https://github.com/w3c/csswg-drafts/issues/3812#issuecomment-1703272181 >> - In a discussion about find-in-page and accessibility, a "remaining >> challenge is "Styling Search Matches" >> >> https://schepp.dev/posts/rethinking-find-in-page-accessibility-making-hidden-text-work-for-everyone/#remaining-challenges >> - A Mozilla user asks for the feature here: >> >> https://connect.mozilla.org/t5/ideas/increased-visibility-for-current-quot-find-in-page-quot-match/idi-p/26500 >> >> >> WIth this in mind I will re-request API owners approval. >> >> Cheers, >> Stephen. >> >> On Mon, Sep 29, 2025 at 2:10 PM Alex Russell <[email protected]> >> wrote: >> >>> Hey Stepen, >>> >>> Any progress? Again, inclined to LGTM, as the arguments we've heard from >>> other vendors to date are not compelling. If there's more to add, would be >>> great to get it in this thread. Would like to get you unblocked. >>> >>> Best, >>> >>> Alex >>> >>> On Monday, September 8, 2025 at 8:49:04 AM UTC-7 Stephen Chenney wrote: >>> >>>> There's quite a bit of discussion going on in the TAG and I'm (still) >>>> waiting on feedback from the client who requested this as to their >>>> specific use case. My goal is to improve our understanding of the >>>> motivation because right now it's unclear how to balance the benefits vs >>>> the risks of the feature. I have a meeting later this week to try to move >>>> things forward. Sorry for the delay. >>>> >>>> Cheers, >>>> Stephen. >>>> >>>> On Wed, Sep 3, 2025 at 10:09 AM Alex Russell <[email protected]> >>>> wrote: >>>> >>>>> Any updates here? >>>>> >>>>> I'm inclined to LGTM this, but would feel much better about it if we >>>>> had input from developers directly. >>>>> >>>>> Best, >>>>> >>>>> Alex >>>>> >>>>> On Wednesday, August 27, 2025 at 11:07:10 PM UTC+1 >>>>> [email protected] wrote: >>>>> >>>>>> Thanks Stephen for providing more context here. Please do let us know >>>>>> if you're able to get more developer feedback on this. >>>>>> >>>>>> The way I'm looking at it, there's an important distinction between >>>>>> possible reasons developers might want the feature. If most only want it >>>>>> because the color schemes of their sites happen to have poor contrast >>>>>> with >>>>>> browsers' built-in find-in-page colors, that's a sign that maybe browsers >>>>>> should take care of ensuring contrast so developers don't have to think >>>>>> about this a11y problem. On the other hand, if developers want to control >>>>>> the find-in-page colors because they want to make them fit in >>>>>> stylistically >>>>>> with their page's color scheme, then that's clearly demonstrating need >>>>>> for >>>>>> this feature. >>>>>> >>>>>> Interestingly, selection color is kind of an example in both >>>>>> directions. If devs don't do anything with it, browsers ensure contrast >>>>>> automatically, but authors can still control the colors if they want. >>>>>> >>>>>> -- Dan >>>>>> >>>>>> On Friday, August 15, 2025 at 5:45:19 AM UTC-7 Stephen Chenney wrote: >>>>>> >>>>>>> Sorry for the time out. I'm still waiting for feedback from >>>>>>> the developers who requested this, but I'll try to add some responses >>>>>>> now. >>>>>>> >>>>>>> On Wed, Jul 23, 2025 at 12:05 PM 'Dan Clark' via blink-dev < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> The API Owners discussed this today and had some concerns that the >>>>>>>> motivation is not as clear as it could be. We'd like to better >>>>>>>> understand >>>>>>>> the developer need for styling these highlights. >>>>>>> >>>>>>> >>>>>>> We have TAG review now, >>>>>>> https://github.com/w3ctag/design-reviews/issues/1120, and the use >>>>>>> case seems strong to them. They had questions about Safari compat. >>>>>>> >>>>>>> Looking at the Motivation section >>>>>>>> <https://github.com/Igalia/explainers/blob/main/css/find-in-page/README.md#-motivation> >>>>>>>> of >>>>>>>> the explainer, 3 StackOverflow links were given: >>>>>>>> >>>>>>>> - Someone directly asks for CSS styling of find-in-page >>>>>>>> >>>>>>>> <https://stackoverflow.com/questions/50309703/css-for-browsers-find-in-page>: >>>>>>>> the use case is *"if a user use's their browser's find function >>>>>>>> to search through the table, the browser will highlight the >>>>>>>> matching text, >>>>>>>> but I want to be able to highlight the entire row if any of it's >>>>>>>> cells >>>>>>>> contain a match". *But this proposal won't solve for this; it >>>>>>>> only allows for things like the color/background color to be >>>>>>>> changed, not >>>>>>>> the area that the highlight covers. >>>>>>>> - Another direct question >>>>>>>> >>>>>>>> <https://stackoverflow.com/questions/18666075/how-to-style-detect-highlighted-boxes-generated-from-browser-native-search-in-pa>: >>>>>>>> it's not clear why the developer wants to do this. >>>>>>>> - A user wants to hide find-in-page results >>>>>>>> >>>>>>>> <https://stackoverflow.com/questions/77458310/confuse-browsers-in-built-find-in-page-feature>: >>>>>>>> for this one the developer basically wants to disable find-on-page, >>>>>>>> which >>>>>>>> seems like something we don't want to be helping with since it >>>>>>>> makes things >>>>>>>> less accessible for users. >>>>>>>> >>>>>>>> Yes, we don't know why the 2nd link wants styling. Regarding the >>>>>>> last, developers can already capture the Ctrl-F and disable find in >>>>>>> page, >>>>>>> and as far as I can tell the way to get custom search styling is to >>>>>>> implement the entire find-in-page system yourself. That's not a >>>>>>> developer >>>>>>> friendly solution. >>>>>>> >>>>>>> So these don't make a strong case to why this feature is the right >>>>>>>> answer. >>>>>>>> >>>>>>>> If the main developer concern being solved for is lack of contrast >>>>>>>> for find results against other page content, such as in >>>>>>>> https://github.com/w3c/csswg-drafts/issues/3812#issuecomment-1703272181, >>>>>>>> then couldn't browsers be doing a better job of solving this problem by >>>>>>>> default rather than pushing the burden onto developers? For example, >>>>>>>> the >>>>>>>> case pointed out in that issue comment >>>>>>>> <https://github.com/w3c/csswg-drafts/issues/3812#issuecomment-1703272181> >>>>>>>> is not so bad in Safari because of Safari's greying-out of the rest of >>>>>>>> the >>>>>>>> page when Find is active. >>>>>>>> >>>>>>> >>>>>>> Our request comes from an embedder. They can apply downstream >>>>>>> patches themselves to adjust styling, but it is cumbersome and gets >>>>>>> more complicated when different styling is needed for different >>>>>>> elements. >>>>>>> Then they are implementing this entire feature themselves. The embedder >>>>>>> story would get more complex, I think, if the browser layer took over >>>>>>> find-in-page, as Safari seems to do. It's also worth pointing out that a >>>>>>> browser level solution takes away power from the site. If an author >>>>>>> doesn't >>>>>>> like what Safari is doing, they cannot do anything about it beyond a >>>>>>> complete custom search function. This raises the difficulty for those >>>>>>> just >>>>>>> wishing to improve the search results styling on their page. >>>>>>> >>>>>>> I'll reply some more once I get more feedback from developers. >>>>>>> >>>>>>> Stephen. >>>>>>> >>>>>>> >>>>>>>> -- Dan >>>>>>>> >>>>>>>> On Wednesday, July 16, 2025 at 12:41:48 PM UTC-7 Stephen Chenney >>>>>>>> wrote: >>>>>>>> >>>>>>>>> There's no problem waiting. We're not in any big hurry and we >>>>>>>>> slowed ourselves down anyway. >>>>>>>>> >>>>>>>>> Regarding WPT testing there's already >>>>>>>>> https://github.com/web-platform-tests/wpt/issues/45844 to get >>>>>>>>> this done and we should solve the spelling/grammar issue too, >>>>>>>>> https://github.com/web-platform-tests/wpt/issues/30863. I'll ask >>>>>>>>> around and see if anyone at Igalia has bandwidth to do this. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Stephen. >>>>>>>>> >>>>>>>>> On Wed, Jul 16, 2025 at 11:14 AM Philip Jägenstedt < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> On testing in WPT, can you look into a WebDriver BiDi command for >>>>>>>>>> triggering find-in-page? That would enable testing this. >>>>>>>>>> >>>>>>>>>> On Wed, Jul 16, 2025 at 5:11 PM Philip Jägenstedt < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Thank you for filing >>>>>>>>>>> https://github.com/w3ctag/design-reviews/issues/1120! Since it >>>>>>>>>>> was just two days ago, let's give it some time before proceeding. >>>>>>>>>>> +Jeffrey >>>>>>>>>>> Yasskin if the TAG can expedite this, it would be great :) >>>>>>>>>>> >>>>>>>>>>> On Mon, Jul 14, 2025 at 1:43 PM Stephen Chenney < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> On Sun, Jul 13, 2025 at 11:58 PM Domenic Denicola < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Thursday, July 10, 2025 at 4:41:12 AM UTC+9 Chromestatus >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Contact emails [email protected], [email protected] >>>>>>>>>>>>> >>>>>>>>>>>>> Explainer https://github.com/Igalia/ >>>>>>>>>>>>> explainers/blob/main/css/find-in-page/README.md >>>>>>>>>>>>> >>>>>>>>>>>>> Specification https://drafts.csswg.org/css- >>>>>>>>>>>>> pseudo-4/#selectordef-search-text >>>>>>>>>>>>> >>>>>>>>>>>>> Design docs >>>>>>>>>>>>> https://github.com/Igalia/explainers/blob/main/css/find- >>>>>>>>>>>>> in-page/README.md >>>>>>>>>>>>> >>>>>>>>>>>>> Summary >>>>>>>>>>>>> >>>>>>>>>>>>> Exposes find-in-page search result styling to authors as a >>>>>>>>>>>>> highlight pseudo-element, like selection and spelling errors. >>>>>>>>>>>>> This allows >>>>>>>>>>>>> authors to change the foreground and background colors or add text >>>>>>>>>>>>> decorations, which can be especially useful if the UA defaults >>>>>>>>>>>>> have >>>>>>>>>>>>> insufficient contrast with the page colors or are otherwise >>>>>>>>>>>>> unsuitable. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Blink component Blink>CSS >>>>>>>>>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ECSS%22> >>>>>>>>>>>>> >>>>>>>>>>>>> Search tags search <http:///features#tags:search> >>>>>>>>>>>>> >>>>>>>>>>>>> TAG review None >>>>>>>>>>>>> >>>>>>>>>>>>> TAG review status Not applicable >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Can you explain why it is not applicable? I can't see which >>>>>>>>>>>>> exception >>>>>>>>>>>>> <https://www.chromium.org/blink/launching-features/wide-review/#exceptions> >>>>>>>>>>>>> category it might fall into. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> We weren't sure because this is a feature already in the CSS >>>>>>>>>>>> spec. I'll set up a review now, and I'll also look into the >>>>>>>>>>>> reviews for all >>>>>>>>>>>> the other highlights (spelling. grammar, find-in-page etc) to see >>>>>>>>>>>> if >>>>>>>>>>>> there's anything still actionable there. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Risks >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>>>> >>>>>>>>>>>>> The feature is in the CSS Pseudo spec and there are no open >>>>>>>>>>>>> issues. The behavior is designed to be implementable in Firefox >>>>>>>>>>>>> and Chrome, >>>>>>>>>>>>> but is unlikely to be viable in Safari due to highly customize UI >>>>>>>>>>>>> for >>>>>>>>>>>>> find-in-page. The spec is explicit that browsers may choose not to >>>>>>>>>>>>> implement this feature provided @supports information is correct. >>>>>>>>>>>>> The >>>>>>>>>>>>> Safari behavior is so different that developers are unlikely to >>>>>>>>>>>>> believe >>>>>>>>>>>>> their styling would apply there. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *Gecko*: Under consideration (https://github.com/mozilla/ >>>>>>>>>>>>> standards-positions/issues/1103) >>>>>>>>>>>>> >>>>>>>>>>>>> *WebKit*: No signal (https://github.com/WebKit/ >>>>>>>>>>>>> standards-positions/issues/421) Will file a request for >>>>>>>>>>>>> position, but in spec conversations were neutral with no >>>>>>>>>>>>> expectation of >>>>>>>>>>>>> implementing it themselves. >>>>>>>>>>>>> >>>>>>>>>>>>> *Web developers*: Positive Developers wishing to avoid >>>>>>>>>>>>> conflicts with the find-in-page colors and their page styles have >>>>>>>>>>>>> requested >>>>>>>>>>>>> this feature. Someone directly asks for CSS styling of >>>>>>>>>>>>> find-in-page: >>>>>>>>>>>>> https://stackoverflow.com/questions/50309703/css-for-browsers- >>>>>>>>>>>>> find-in-page Another direct question: >>>>>>>>>>>>> https://stackoverflow.com/questions/18666075/how-to- >>>>>>>>>>>>> style-detect-highlighted-boxes-generated-from-browser- >>>>>>>>>>>>> native-search-in-pa A developer wants to hide find-in-page >>>>>>>>>>>>> results: https://stackoverflow.com/questions/77458310/confuse- >>>>>>>>>>>>> browsers-in-built-find-in-page-feature) and could do so by >>>>>>>>>>>>> styling them as transparent >>>>>>>>>>>>> >>>>>>>>>>>>> *Other signals*: >>>>>>>>>>>>> >>>>>>>>>>>>> Ergonomics >>>>>>>>>>>>> >>>>>>>>>>>>> None. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Activation >>>>>>>>>>>>> >>>>>>>>>>>>> There is no way to polyfill this. There is no real challenge >>>>>>>>>>>>> to adopting beyond awareness that the feature exists, and we will >>>>>>>>>>>>> be >>>>>>>>>>>>> producing blog postings and other social media evangelization. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Security >>>>>>>>>>>>> >>>>>>>>>>>>> There is no security risk. The CSS styling is available >>>>>>>>>>>>> regardless of whether the text is search for or not, so user >>>>>>>>>>>>> find-in-page >>>>>>>>>>>>> queries cannot be seen by script. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 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? >>>>>>>>>>>>> >>>>>>>>>>>>> No >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Debuggability >>>>>>>>>>>>> >>>>>>>>>>>>> There is no security risk. The CSS styling is available >>>>>>>>>>>>> regardless of whether the text is search for or not, so user >>>>>>>>>>>>> find-in-page >>>>>>>>>>>>> queries cannot be seen by script. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>>>>>> (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)? >>>>>>>>>>>>> Yes >>>>>>>>>>>>> >>>>>>>>>>>>> All platforms support find-in-page and could use CSS styling >>>>>>>>>>>>> to improve legibility on some sites. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>>>>>> ? No >>>>>>>>>>>>> >>>>>>>>>>>>> Testing is in wpt_internal tests due to a lack of wpt support >>>>>>>>>>>>> for adding find-in-page markers. third_party/blink/web_tests/ >>>>>>>>>>>>> wpt_internal/css/css-pseudo/search-text-* >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> DevTrial instructions https://github.com/Igalia/ >>>>>>>>>>>>> explainers/blob/main/css/find-in-page/README.md >>>>>>>>>>>>> >>>>>>>>>>>>> Flag name on about://flags Experimental Web Platform Features >>>>>>>>>>>>> >>>>>>>>>>>>> Finch feature name SearchTextHighlightPseudo >>>>>>>>>>>>> >>>>>>>>>>>>> Rollout plan Will ship enabled for all users >>>>>>>>>>>>> >>>>>>>>>>>>> Requires code in //chrome? False >>>>>>>>>>>>> >>>>>>>>>>>>> Tracking bug https://issues.chromium.org/issues/339298411 >>>>>>>>>>>>> >>>>>>>>>>>>> Measurement We will implement UseCounters for this pseudo >>>>>>>>>>>>> element (and all the other too, see >>>>>>>>>>>>> https://issues.chromium.org/issues/381093928) >>>>>>>>>>>>> >>>>>>>>>>>>> Availability expectation Available in Chrome, and Firefox. >>>>>>>>>>>>> Not available in Safari >>>>>>>>>>>>> >>>>>>>>>>>>> Adoption expectation Hard to predict and not relevant to most >>>>>>>>>>>>> sites >>>>>>>>>>>>> >>>>>>>>>>>>> Adoption plan Blog posts and developer outreach >>>>>>>>>>>>> >>>>>>>>>>>>> Non-OSS dependencies >>>>>>>>>>>>> >>>>>>>>>>>>> Does the feature depend on any code or APIs outside the >>>>>>>>>>>>> Chromium open source repository and its open-source dependencies >>>>>>>>>>>>> to >>>>>>>>>>>>> function? >>>>>>>>>>>>> No >>>>>>>>>>>>> >>>>>>>>>>>>> Estimated milestones Shipping on desktop 140 DevTrial on >>>>>>>>>>>>> desktop 135 Shipping on Android 140 DevTrial on Android 135 >>>>>>>>>>>>> Shipping >>>>>>>>>>>>> on WebView 140 >>>>>>>>>>>>> >>>>>>>>>>>>> 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/5195073796177920?gate= >>>>>>>>>>>>> 5047118541881344 >>>>>>>>>>>>> >>>>>>>>>>>>> Links to previous Intent discussions Intent to Prototype: >>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ >>>>>>>>>>>>> c447ed4dfd05b588e2afc650277371fd%40igalia.com >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 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 visit >>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzRDTpo0grPCaqQkdUOacQQ0ovjr_mL-%3DpOmxYKqcyNYMw%40mail.gmail.com >>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzRDTpo0grPCaqQkdUOacQQ0ovjr_mL-%3DpOmxYKqcyNYMw%40mail.gmail.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 visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/df61d4d1-f902-46ef-9e6d-ad349f7c556bn%40chromium.org >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/df61d4d1-f902-46ef-9e6d-ad349f7c556bn%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 visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzT8TPf8dPQXzSUM_ueX%2B1wvhHFfo%2B6fv2cPtUaydeNJwg%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzT8TPf8dPQXzSUM_ueX%2B1wvhHFfo%2B6fv2cPtUaydeNJwg%40mail.gmail.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 visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdKtGgVuaAd7B5RT1Zm8WGp_Qz9hyKqO-Y-wdoHaOHS5A%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdKtGgVuaAd7B5RT1Zm8WGp_Qz9hyKqO-Y-wdoHaOHS5A%40mail.gmail.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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-13x_EP4JbEoBiNGMbywLpodoomhABh2hW2ZUgwBx0eg%40mail.gmail.com.
