- 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.
