Thanks Mike but I don't use Chromium. Is that even available on Android? On Sat, 7 Oct 2023, 03:27 Mike Taylor, <miketa...@chromium.org> wrote:
> Hi Adam, > > crbug.com/new is a better place to file a feature request to disable this > feature on Chrome for Android (and a more user-friendly option on Desktop). > > thanks, > Mike > On 10/5/23 3:07 PM, Adam Semenenko wrote: > > Thanks for the explanation. But I don't like the scroll to text fragments. > They're annoying, and have never been useful. > > 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 Fri, 6 Oct 2023, 08:01 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/CAAyoetRKLi4P4uL-mRSbRmyMfc6p6LHHcP%2BMGRhj%3DV%3DoM7ouGQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAyoetRKLi4P4uL-mRSbRmyMfc6p6LHHcP%2BMGRhj%3DV%3DoM7ouGQ%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/CAAyoetQ4SM6dp7EKsRKCgDeC7NbOYG7erw9jEuByeRwmJBH-Jw%40mail.gmail.com.
