You haven't said where your scroll-to-text links are coming from, but I assume it's a search engine, which is the most common case. If you don't like the quality of the links, the proper place to address your complaint is to that search engine.
As this feature has shipped (it appears all the way back in M80), complaining on this thread isn't going to accomplish anything. If you want the spec to change, there are other forums for that. If you want Chrome's behavior to change, you should file a feature request (or ideally, find an existing one). On Thu, Oct 5, 2023, 12:10 PM Adam Semenenko <adam.semene...@gmail.com> wrote: > The feature can be disabled in Safari > https://www.reddit.com/r/MacOS/comments/14l1gcu/how_to_disable_safari_automatically_highlighting/, > so it's a Chrome specific issue that it can't be disabled > > On Fri, 6 Oct 2023, 08:06 K. Moon, <km...@chromium.org> wrote: > >> (Incidentally, it appears Safari 16+ also supports this feature, further >> illustrating that this is not a Chrome-specific concern.) >> https://caniuse.com/url-scroll-to-text-fragment >> >> On Thu, Oct 5, 2023, 12:01 PM K. Moon <km...@chromium.org> wrote: >> >>> If the URL doesn't contain a scroll-to-text fragment, then this feature >>> doesn't get invoked. The site that serves you the URL is responsible for >>> deciding whether or not to include a scroll-to-text fragment. >>> >>> On Thu, Oct 5, 2023, 11:59 AM Adam Semenenko <adam.semene...@gmail.com> >>> wrote: >>> >>>> Sorry, I'm not sure what you mean. I only get usability issues related >>>> to this feature in Chrome, which to me indicates it's a Chrome issue >>>> >>>> On Fri, 6 Oct 2023, 07:53 K. Moon, <km...@chromium.org> wrote: >>>> >>>>> If your complaint is about the URLs (and the resulting behavior), >>>>> isn't that a site authoring issue, not a Chrome issue? >>>>> >>>>> On Thu, Oct 5, 2023, 10:25 AM Adam Semenenko <adam.semene...@gmail.com> >>>>> wrote: >>>>> >>>>>> Sorry Thomas, I should have specified that I am using Android. From >>>>>> what I can tell there's no way to disable this anti-feature on Android. >>>>>> >>>>>> Also, while the macOS option removes some distraction, Chrome still >>>>>> pollutes the URL with unnecessary content that's awkward to remove. (I've >>>>>> never wanted to share a URL with this 'jump to text' option.) >>>>>> >>>>>> On Thu, 5 Oct 2023, 20:54 Thomas Steiner, <to...@google.com> wrote: >>>>>> >>>>>>> See https://web.dev/text-fragments/#disabling-text-fragments for >>>>>>> disabling the feature. >>>>>>> >>>>>>> On Thu, Oct 5, 2023 at 8:51 AM Anton Bershanskyi < >>>>>>> bershans...@gmail.com> wrote: >>>>>>> >>>>>>>> Hi Adam, >>>>>>>> >>>>>>>> > Is it still not possible to disable this distraction yet? >>>>>>>> >>>>>>>> Chrome used to have an option to disable this feature, but the flag >>>>>>>> was removed. It is possible to remove highlights with extensions. I >>>>>>>> found "Disable >>>>>>>> Google Search Text Highlights" >>>>>>>> <https://chrome.google.com/webstore/detail/disable-google-search-tex/ompocnnmgiaoieoanemepjflbokldhom> >>>>>>>> on CWS, but never used it. It's open source (GitHub link on store >>>>>>>> page). >>>>>>>> The source seems fine (albeit I would have written it with declarative >>>>>>>> network rules for efficiency, but very few developers are familiar with >>>>>>>> this API). >>>>>>>> >>>>>>>> Hope this helps. >>>>>>>> >>>>>>>> On Thursday, October 5, 2023 at 2:26:18 AM UTC+3 Adam Semenenko >>>>>>>> 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+unsubscr...@chromium.org. >>>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6969a528-2a88-40ab-8b07-9aa9e522946an%40chromium.org >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6969a528-2a88-40ab-8b07-9aa9e522946an%40chromium.org?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Thomas Steiner, PhD—Developer Relations Engineer ( >>>>>>> https://blog.tomayac.com, https://twitter.com/tomayac) >>>>>>> >>>>>>> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany >>>>>>> Geschäftsführer: Paul Manicle, Liana Sebastian >>>>>>> Registergericht und -nummer: Hamburg, HRB 86891 >>>>>>> >>>>>>> ----- BEGIN PGP SIGNATURE ----- >>>>>>> Version: GnuPG v2.3.4 (GNU/Linux) >>>>>>> >>>>>>> >>>>>>> iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom. >>>>>>> hTtPs://xKcd.cOm/1181/ >>>>>>> ----- END PGP SIGNATURE ----- >>>>>>> >>>>>> -- >>>>>> 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/CAAyoetTfq0Yt6UTv_7xa%3DvEGKESREoVqwHoDWZrgn46yXsKwfw%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAyoetTfq0Yt6UTv_7xa%3DvEGKESREoVqwHoDWZrgn46yXsKwfw%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/CACwGi-57QVVLSxYvrS5EooRVJ1NrDnx72DF7RCY6Nc8%3DUT3J2A%40mail.gmail.com.
