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.
