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.semene...@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.semene...@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.semene...@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.semene...@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 <blink-dev@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+unsubscr...@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/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+unsubscr...@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>.
