> Scroll To Text Fragment is a web feature that can be used to make a useful experience, or a not so useful experience. Like animations or funny fonts. That the feature can be used badly is not in itself a reason to remove it (and few people want to support badly tested customization flags).
But there *are* flags to disable features that interfere with accessibility. Animations can be disabled, https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion, and colour schemes can be modified https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme . I don't think "bad websites exist, so that means bad browser features are okay" is a convincing argument. On Thu, 28 Mar 2024 at 18:06, Daniel Bratell <bratel...@gmail.com> wrote: > I see what you mean since I've also ended up with highlighted text that is > very unhelpful, but I think that you are directing your annoyance at the > wrong party. > > Scroll To Text Fragment is a web feature that can be used to make a useful > experience, or a not so useful experience. Like animations or funny fonts. > That the feature can be used badly is not in itself a reason to remove it > (and few people want to support badly tested customization flags). > > Instead I think that you should try to reach the people the use it in a > bad way. If we're talking Google Search, I know that can be hard, but maybe > you can find a way. > > Alternatively, if you have a suggestion for how to make it better (turning > it off doesn't make the feature better but good try), I think there are > places to voice those ideas in connection to Blink. In specification forums > or as feature requests. > There also seems to be at least one browser extension that claims that it > does something: "Disable Google Search Text Highlights". Maybe it works. > > /Daniel > > > On 2024-03-28 17:19, B. Blank wrote: > > > - ok... So to chime in here. Not sure the best way to reach the folks > who created this functionality. There needs to be a way to turn this > feature off. It's been distracting and annoying for a couple of years now, > and any flag or setting to turn it off is gone. Why isn't there a way to > disable this highlighting of text? Come on. Really? > > Sorry. > Please! > > On Thursday, January 18, 2024 at 8:25:35 AM UTC-5 Mike Taylor wrote: > >> If you believe you've found a bug, please file a new issue at >> crbug.com/new. This is not a support forum. >> >> thanks, >> Mike >> On 1/17/24 7:30 PM, Adam Semenenko wrote: >> >> Unfortunately the opt-out feature no longer seems to work, and now Chrome >> is randomly highlighting text and scrolling halfway through a page even >> when no highlighting was requested. >> >> The colours are getting even more garish over time too. >> >> Is there any other way to disable the highlighting? >> >> On Wed, 25 Oct 2023 at 09:53, Adam Semenenko <adam.se...@gmail.com> >> wrote: >> >>> Sorry, this is just an email isn't it? The thread was closed. I've heard >>> many things from different people, but I'm still experiencing the problem. >>> I'm not sure who any of you are either, is there some sort of guide for >>> who's in charge of who I can email? It'd be nice if the OP was could reply >>> to their thread, instead of just cherry picking praise and running away >>> with an idea that could be improved. >>> >>> It's not a Chrome product feedback by the way, as I understand there's >>> the same problem in other browsers. >>> >>> On Thu, 19 Oct 2023, 06:04 K. Moon, <km...@chromium.org> wrote: >>> >>>> Please stop posting this kind of feedback to this thread; you've been >>>> informed multiple times by multiple individuals that this is not the right >>>> forum for Chrome product feedback. >>>> >>>> Continuing to persist in doing so may lead to intervention, like >>>> blocking your ability to post entirely. >>>> >>>> On Tue, Oct 17, 2023, 10:15 PM Adam Semenenko <adam.se...@gmail.com> >>>> wrote: >>>> >>>>> Here's another example of useless and distracting highlighting. What >>>>> is it about the first two sentences that need highlighting? Is their >>>>> position not significant enough? >>>>> >>>>> On Thu, 5 Oct 2023, 11:40 Adam Semenenko, <adam.se...@gmail.com> >>>>> wrote: >>>>> >>>>>> Is it still not possible to disable this distraction yet? I found a >>>>>> wonderfully ironic example today - see attached screenshot. >>>>>> >>>>>> There seem to be only two ways that this feature is used: >>>>>> >>>>>> 1. The first sentence of a page is highlighted, which is completely >>>>>> redundant and patronising. Yes Chrome, thank you for highlighting the >>>>>> very >>>>>> first sentence. However could I cope without you. >>>>>> >>>>>> 2. A random sentence halfway through the page is highlighted. This is >>>>>> never what I want: I always want to read the page so that I can >>>>>> understand >>>>>> the sentence in context. >>>>>> >>>>>> >>>>>> >>>>>> On Wed, 5 May 2021, 06:40 Adam Semenenko, <adam.se...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Do you know if there's a consistent and easy way to disable this >>>>>>> yet? It's really distracting for me. When I google something and click >>>>>>> on a >>>>>>> result, I like consistent behaviour and to see the whole page from the >>>>>>> start. I feel disrupted when I'm randomly dropped into the middle of a >>>>>>> page >>>>>>> with a garish colour jumping out at me. >>>>>>> >>>>>>> Cheers, >>>>>>> Adam >>>>>>> >>>>>>> On Mon, 26 Apr 2021 at 21:54, 'Grant Wang' via blink-dev < >>>>>>> blin...@chromium.org> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> It’s been roughly nine months since we first utilized Scroll To >>>>>>>> Text Fragment in featured snippets in Google Search. In that time, >>>>>>>> we’ve >>>>>>>> seen that Scroll To Text Fragment links help us towards our goal to get >>>>>>>> users the information they need. In particular: >>>>>>>> >>>>>>>> 1. We find that Scroll To Text Fragment links increase >>>>>>>> engagement -- users are less likely to visit a page and then >>>>>>>> quickly hit >>>>>>>> the back button, because they can more readily understand how >>>>>>>> relevant the >>>>>>>> page is to their search after arriving at the page. >>>>>>>> >>>>>>>> 2. In user surveys, we find that users prefer being scrolled to >>>>>>>> the relevant section of a page that’s in a featured snippet. Users >>>>>>>> who were >>>>>>>> scrolled to the relevant section preferred the experience at a rate >>>>>>>> of 2:1; >>>>>>>> even users who were not scrolled in the control group preferred the >>>>>>>> option >>>>>>>> of being scrolled to the relevant section at the same 2:1 rate. >>>>>>>> >>>>>>>> Besides their usage on Google Search, we’ve noticed scroll to text >>>>>>>> fragments links during our crawls of the web. One of the best use >>>>>>>> cases >>>>>>>> has been wikipedia citations. For instance, citation 9 >>>>>>>> <https://en.wikipedia.org/wiki/Melbourne_Cup_%28greyhounds%29#:~:text=%22How%20the%20Cup%20Was%20Won%22.%20Sandown%20Greyhounds.%20Retrieved%2017%20March%202021.> >>>>>>>> on this page: >>>>>>>> https://en.wikipedia.org/wiki/Melbourne_Cup_(greyhounds) provides >>>>>>>> the detailed attribution to the fastest-ever time at the Melbourne Cup. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Grant >>>>>>>> On Thursday, December 12, 2019 at 12:24:40 PM UTC-8 >>>>>>>> sligh...@chromium.org wrote: >>>>>>>> >>>>>>>>> LGTM4 >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thursday, December 12, 2019 at 12:17:49 PM UTC-8, Daniel >>>>>>>>> Bratell wrote: >>>>>>>>>> >>>>>>>>>> LGTM3 >>>>>>>>>> >>>>>>>>>> /Daniel >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thursday, 12 December 2019 19:45:38 UTC+1, Chris Harrelson >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> LGTM2 >>>>>>>>>>> >>>>>>>>>>> On Wed, Dec 11, 2019 at 10:27 PM Yoav Weiss <yo...@yoav.ws> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> LGTM1 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Dec 11, 2019, 22:03 Nick Burris <nbu...@chromium.org> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> We feel that we're now in good shape for shipping. We have >>>>>>>>>>>>> addressed all of the shipping blockers that I listed in my >>>>>>>>>>>>> previous email, >>>>>>>>>>>>> and the corresponding implementation changes have landed in >>>>>>>>>>>>> Chrome. We're >>>>>>>>>>>>> still continuing to make improvements to the spec, functionality, >>>>>>>>>>>>> and web >>>>>>>>>>>>> platform tests but we consider the outstanding issues to be minor >>>>>>>>>>>>> and >>>>>>>>>>>>> wouldn't have an effect on interop, so we don't believe they're >>>>>>>>>>>>> ship-blocking. >>>>>>>>>>>>> >>>>>>>>>>>>> We have received positive signal on the feature from Safari, >>>>>>>>>>>>> thank you Maciej for the reply on webkit-dev >>>>>>>>>>>>> <https://lists.webkit.org/pipermail/webkit-dev/2019-December/030996.html>! >>>>>>>>>>>>> Note that we actually do have feature detectability specified >>>>>>>>>>>>> implemented >>>>>>>>>>>>> per my reply >>>>>>>>>>>>> <https://lists.webkit.org/pipermail/webkit-dev/2019-December/030998.html>. >>>>>>>>>>>>> My apologies this was not mentioned in the initial intent to ship >>>>>>>>>>>>> email, it >>>>>>>>>>>>> developed a few emails down the line. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Nick >>>>>>>>>>>>> >>>>>>>>>>>>> On Thursday, October 31, 2019 at 11:50:21 AM UTC-4, Nick >>>>>>>>>>>>> Burris wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks so much for the detailed feedback! Here's a specific >>>>>>>>>>>>>> list of blockers, with some comments inline. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Specification issues >>>>>>>>>>>>>> >>>>>>>>>>>>>> - #64 >>>>>>>>>>>>>> <https://github.com/WICG/ScrollToTextFragment/issues/64> >>>>>>>>>>>>>> - Prevent invocation from popup >>>>>>>>>>>>>> - #66 >>>>>>>>>>>>>> <https://github.com/WICG/ScrollToTextFragment/issues/66> >>>>>>>>>>>>>> - Clarify how scroll to fragment is performed >>>>>>>>>>>>>> >>>>>>>>>>>>>> Web platform test cases >>>>>>>>>>>>>> >>>>>>>>>>>>>> - Security restrictions >>>>>>>>>>>>>> >>>>>>>>>>>>>> <https://wicg.github.io/ScrollToTextFragment/#should-allow-text-fragment> >>>>>>>>>>>>>> - Setting window.location.fragmentDirective has no effect >>>>>>>>>>>>>> - All combinations of optional parameters in text >>>>>>>>>>>>>> directive >>>>>>>>>>>>>> - Matching TextMatchChar >>>>>>>>>>>>>> <https://wicg.github.io/ScrollToTextFragment/#textmatchchar>s >>>>>>>>>>>>>> and PercentEncodedChar >>>>>>>>>>>>>> >>>>>>>>>>>>>> <https://wicg.github.io/ScrollToTextFragment/#percentencodedchar>s >>>>>>>>>>>>>> (in particular the syntactical characters ‘,’ and ‘-’) >>>>>>>>>>>>>> including non-ASCII >>>>>>>>>>>>>> - Multiple matches in the page (currently we only test 0 >>>>>>>>>>>>>> or 1 match) >>>>>>>>>>>>>> - Cross-whitespace/node matching (i.e. context terms and >>>>>>>>>>>>>> match terms can be separated by whitespace and node >>>>>>>>>>>>>> boundaries) >>>>>>>>>>>>>> - Test matching hidden and shadow DOM >>>>>>>>>>>>>> - Test horizontal scroll into view >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thursday, October 31, 2019 at 10:17:56 AM UTC-4, Frédéric >>>>>>>>>>>>>> Wang wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 30/10/2019 15:52, Yoav Weiss wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This intent received a lot of feedback, but some of it more >>>>>>>>>>>>>>> relevant to the general Blink process in general than to this >>>>>>>>>>>>>>> intent >>>>>>>>>>>>>>> specifically. So, let me try to sum up where I believe things >>>>>>>>>>>>>>> are and what >>>>>>>>>>>>>>> is and isn't blocking this intent from my perspective. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> While the original intent could have done a better job at >>>>>>>>>>>>>>> expressing the outreach efforts done, and potentially a better >>>>>>>>>>>>>>> job reaching >>>>>>>>>>>>>>> out to WebKit folks, that *should not block* the current >>>>>>>>>>>>>>> intent. Official signals from other vendors would be most >>>>>>>>>>>>>>> welcome, but I >>>>>>>>>>>>>>> would not block the intent on getting them. (The Blink process >>>>>>>>>>>>>>> needs to >>>>>>>>>>>>>>> establish the best ways to get feedback from other vendors in >>>>>>>>>>>>>>> reasonable >>>>>>>>>>>>>>> timeframes. That discussion is beyond the scope of this intent) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> A list of blockers for this intent from my perspective: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Anne's security concern >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <https://github.com/w3ctag/design-reviews/issues/392#issuecomment-510855073> >>>>>>>>>>>>>>> seems >>>>>>>>>>>>>>> like something we should address in spec. Even if Chrome >>>>>>>>>>>>>>> security folks >>>>>>>>>>>>>>> don't consider this a blocking issue, assuming Mozilla does, >>>>>>>>>>>>>>> that would get >>>>>>>>>>>>>>> in their way if they wished to follow us. >>>>>>>>>>>>>>> - Daniel's feedback on augmenting the Privacy & Security >>>>>>>>>>>>>>> section with feedback from the Chrome security seems >>>>>>>>>>>>>>> valuable, and I'd like >>>>>>>>>>>>>>> to see it addressed before shipping. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Forgot to note that David did address this in #62 >>>>>>>>>>>>>> <https://github.com/WICG/ScrollToTextFragment/issues/62>, I >>>>>>>>>>>>>> believe the security and privacy >>>>>>>>>>>>>> <https://wicg.github.io/ScrollToTextFragment/#allow-text-fragment-directives> >>>>>>>>>>>>>> section now details all of the feedback and work we've done here. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Regarding Rego and Fréd's feedback on WPTs - I'd like >>>>>>>>>>>>>>> for us to reach agreement on which test cases should be >>>>>>>>>>>>>>> added beyond what's >>>>>>>>>>>>>>> currently covered in order for the test suite to be >>>>>>>>>>>>>>> considered complete. >>>>>>>>>>>>>>> Rego/Fréd - do you have such a list of cases in mind? Once >>>>>>>>>>>>>>> we reach >>>>>>>>>>>>>>> agreement on what that list should be, we should block >>>>>>>>>>>>>>> shipping until the >>>>>>>>>>>>>>> test suite is complete. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> People developing the feature probably know better the >>>>>>>>>>>>>>> things to test. That said, after checking a bit the spec and >>>>>>>>>>>>>>> tests, it >>>>>>>>>>>>>>> looks like the features can be divided into the following >>>>>>>>>>>>>>> categories: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (1) Fragment directive, IDL interface and TreeWalker >>>>>>>>>>>>>>> navigation >>>>>>>>>>>>>>> This is the core of the proposal, so it would probably >>>>>>>>>>>>>>> be a blocker if it >>>>>>>>>>>>>>> is not tested extensively. Exiting tests already cover >>>>>>>>>>>>>>> several cases, but >>>>>>>>>>>>>>> I suspect more can be tested here (e.g. check the actual >>>>>>>>>>>>>>> value >>>>>>>>>>>>>>> of window.location.fragmentDirective for different >>>>>>>>>>>>>>> cases, check that >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Note that window.location.fragmentDirective does not actually >>>>>>>>>>>>>> expose the fragment directive string, for now it is just >>>>>>>>>>>>>> specified for >>>>>>>>>>>>>> feature detectability (see #19 >>>>>>>>>>>>>> <https://github.com/WICG/ScrollToTextFragment/issues/19> and >>>>>>>>>>>>>> spec >>>>>>>>>>>>>> <https://wicg.github.io/ScrollToTextFragment/#feature-detectability> >>>>>>>>>>>>>> ). >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> setting it has no effect, doing query for all >>>>>>>>>>>>>>> combinations of >>>>>>>>>>>>>>> mandatory/optional parameters, TextMatchChar, percent >>>>>>>>>>>>>>> encoding of special >>>>>>>>>>>>>>> characters, non-ascii chars, more complex test pages >>>>>>>>>>>>>>> with 0, 1 or more >>>>>>>>>>>>>>> matches, with whitespace, with different locales, etc) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (2) Security & Privacy >>>>>>>>>>>>>>> Apparently people have raised concerns about this so it >>>>>>>>>>>>>>> seems important to >>>>>>>>>>>>>>> tests any mitigation or protection described in the >>>>>>>>>>>>>>> spec, if any (and if >>>>>>>>>>>>>>> possible with the current WPT infrastructure). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (3) Navigating to a Text Fragment >>>>>>>>>>>>>>> It seems that the idea of the proposal is to rely on >>>>>>>>>>>>>>> existing concepts >>>>>>>>>>>>>>> like Range/TreeWalker and APIs similar to >>>>>>>>>>>>>>> window.find/scrollIntoView. >>>>>>>>>>>>>>> I think it would be good to have minimal tests checking >>>>>>>>>>>>>>> that (scroll >>>>>>>>>>>>>>> position actually changed, scroll alignment/behavior, >>>>>>>>>>>>>>> hidden DOM/CSS, etc) >>>>>>>>>>>>>>> but this does not need to be exhaustive, since it is >>>>>>>>>>>>>>> assumed that these are >>>>>>>>>>>>>>> already implemented, tested and inter-operable (See >>>>>>>>>>>>>>> comment below though). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (4) Indicating The Text Match >>>>>>>>>>>>>>> The spec explicitly says it is UA-defined so it cannot >>>>>>>>>>>>>>> really be >>>>>>>>>>>>>>> tested. I guess one could write a minimal != reftest to >>>>>>>>>>>>>>> check that highlight >>>>>>>>>>>>>>> actually happens but it would be very weak anyway, so >>>>>>>>>>>>>>> I'm not sure it's >>>>>>>>>>>>>>> necessary. These will instead likely be browser-specific >>>>>>>>>>>>>>> tests. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Agreed, I think this should be left as browser-specific; we >>>>>>>>>>>>>> only want to specify the matching/scroll-into-view behavior and >>>>>>>>>>>>>> leave it up >>>>>>>>>>>>>> to the UA/browser how the specific text is actually indicated. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> BTW, I don't think my comment regarding BroadcastChannel is >>>>>>>>>>>>>>> a blocker, I just believe it would be nice to avoid relying on >>>>>>>>>>>>>>> non-interoperable APIs. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Though not a shipping blocker I definitely want to fix this, >>>>>>>>>>>>>> I spoke to some WPT experts and using WPT's Stash >>>>>>>>>>>>>> <https://web-platform-tests.org/tools/wptserve/docs/stash.html> >>>>>>>>>>>>>> seems like a viable option. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Besides tests, I share Anne's concern on Mozilla repo >>>>>>>>>>>>>>> regarding lack of existing primitive for actually performing >>>>>>>>>>>>>>> the scroll to >>>>>>>>>>>>>>> text. I opened >>>>>>>>>>>>>>> https://github.com/WICG/ScrollToTextFragment/issues/66 for >>>>>>>>>>>>>>> that purpose. Right now it's unclear to me if this is >>>>>>>>>>>>>>> well-specified and >>>>>>>>>>>>>>> tested in the current proposal, and this may be considered a >>>>>>>>>>>>>>> blocker. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Frédéric Wang >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>> 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 blin...@chromium.org. >>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1238c06f-dcd1-434c-87b8-97a373fdf735%40chromium.org >>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1238c06f-dcd1-434c-87b8-97a373fdf735%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 blin...@chromium.org. >>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgFMwT1ArGjrHMcWZ9pKe8%2Bsv%2BJHDLpOd4ofOQss0a-zA%40mail.gmail.com >>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgFMwT1ArGjrHMcWZ9pKe8%2Bsv%2BJHDLpOd4ofOQss0a-zA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>> You received this message because you are subscribed to a topic in >>>>>>>> the Google Groups "blink-dev" group. >>>>>>>> To unsubscribe from this topic, visit >>>>>>>> https://groups.google.com/a/chromium.org/d/topic/blink-dev/zlLSxQ9BA8Y/unsubscribe >>>>>>>> . >>>>>>>> To unsubscribe from this group and all its topics, 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/e9c07baa-3c2a-4835-9014-9d5a2b249618n%40chromium.org >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e9c07baa-3c2a-4835-9014-9d5a2b249618n%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/CAAyoetTc9x1UFboXG0KpRvp9t3CScyYjYNpiX839XX7p8gWCKQ%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAyoetTc9x1UFboXG0KpRvp9t3CScyYjYNpiX839XX7p8gWCKQ%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 blink-dev+...@chromium.org. >> >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAyoetQCRN2yCPu6j5xSK3odOhX3VNvWbjsHgUiM-PpWLXCCbw%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAyoetQCRN2yCPu6j5xSK3odOhX3VNvWbjsHgUiM-PpWLXCCbw%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 blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a57474d0-4c51-4649-8afb-7446cd7fdfd3n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a57474d0-4c51-4649-8afb-7446cd7fdfd3n%40chromium.org?utm_medium=email&utm_source=footer> > . > > -- > You received this message because you are subscribed to a topic in the > Google Groups "blink-dev" group. > To unsubscribe from this topic, visit > https://groups.google.com/a/chromium.org/d/topic/blink-dev/zlLSxQ9BA8Y/unsubscribe > . > To unsubscribe from this group and all its topics, 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/1281ace1-4282-4591-83bf-20f8b43eb5a4%40gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1281ace1-4282-4591-83bf-20f8b43eb5a4%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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAyoetQ_3pSDJWrZO%3D3nCHVjmRXxaaBD4BsftL3mchW_BFHfmA%40mail.gmail.com.
