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/CAAyoetQoL9GLiLkruE6MXQygT4RuOnSFKNk93GSj8bO-%2B9JiVw%40mail.gmail.com.
