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-4J6avV1e3_gCsijBsMQt-7_jduccMbkgmz5JYEt9paWw%40mail.gmail.com.
