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