LGTM3 On Wed, Nov 19, 2025 at 5:19 PM 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/CAOmohSLps7k%2B9XJqjxLUpKOZz9fdxQCCOc7mmeW3y7FPC9ahTg%40mail.gmail.com.
