You can right click on it and select "Remove highlight" or something like that.
I agree that it is not a nice experience, it is annoying that it is left highlighted. Maybe the original duration was too short, but this is too long/permanent. Around five seconds might make sense and an option to double click on it to remove it, which would work for most texts. ☆*PhistucK* On Fri, Mar 11, 2022 at 9:54 PM Adam Semenenko <[email protected]> wrote: > Hi all, > > Is there a way to remove this option yet? The usability is getting worse > for me. Now the ugly highlighting is sticking around for longer. > > I don't need Chrome to randomly highlight an arbitrary sentence of some > websites in a different colour. It's distracting and annoying. I'd like to > turn it off. > > Kind regards, > Adam > > > On Tue, 4 May 2021, 20:40 Adam Semenenko, <[email protected]> > 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 < >> [email protected]> 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 >>> [email protected] 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 <[email protected]> wrote: >>>>>> >>>>>>> LGTM1 >>>>>>> >>>>>>> >>>>>>> On Wed, Dec 11, 2019, 22:03 Nick Burris <[email protected]> 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 [email protected]. >>>>>>>> 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 [email protected]. >>>>>>> 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 >>> [email protected]. >>> 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAyoetRLA%3Da5WScarBrGJnBOpiR9A7eBNJ6nt%3DR4CXDB7czLCg%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAyoetRLA%3Da5WScarBrGJnBOpiR9A7eBNJ6nt%3DR4CXDB7czLCg%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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_K9phYuRTUef3uY2Eu__S63iwxdZ2HW_03E7gLwEpEA8Q%40mail.gmail.com.
