Filed crbug.com/462131663 to raise the question of whether the defaults should be improved.
On Wed, Nov 19, 2025 at 11:53 AM Daniel Bratell <[email protected]> wrote: > I don't think I need to add another approval here, since I think it's > already some kind of record, but I'm happy that there are now documented > use cases, even if some are a bit weird. Is there no limit to what web > developers think of? > > And I do hope someone in the Chrome/Chromium UI team has noticed how weak > the default find highlight is and is considering improvements, so that > people do not feel forced to "fix" the browser in CSS. It is ok if they > want to, but not if they feel like they must. > > /Daniel > On 2025-11-19 17:26, Stephen Chenney wrote: > > > > 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. >> > > Indeed. We already have > https://github.com/web-platform-tests/wpt/issues/30863 for spelling and > grammar markers, and this would be another use for the same system. Maybe a > project for the Supporters of Chromium Based Browsers foundation to add as > many of these backlogged testing requirements as possible. Igalia has been > funded in the past for Accessibility test improvements (which are clearly > more important) so there is precedent for foundation funding to improve > testing. > > Cheers, > Stephen. > > >> >> 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/CAGsbWzShzBRvEFx2eC%3D-N-Pi0m0fVdbBBARqec7EXQQa7vmMiw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzShzBRvEFx2eC%3D-N-Pi0m0fVdbBBARqec7EXQQa7vmMiw%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/af8f7945-649b-400b-962a-bf21266e28b9%40gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/af8f7945-649b-400b-962a-bf21266e28b9%40gmail.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-CLatvDXg7mEM_N3UTDqMm5yjVRhO%2Byj2ZZkRwYzCRqA%40mail.gmail.com.
