Intent to Experiment: Scroll To Text Fragment

[Nick Burris]

Contact emails

nbu...@chromium.org, bmcq...@chromium.org, bo...@chromium.org 

Spec

https://github.com/bokand/ScrollToTextFragment

Summary

Scroll To Text allows URLs to link to a piece of text in a webpage rather than just linking to an existing element fragment. The motivating use cases are to enable user sharing of specific content and allow references to deep-link to information.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/aKI6doxffgQ/7dzrVvo4CAAJ

Goals for experimentation

We want to gain insight into site compatibility with the proposed method of using the URL fragment to specify a target text passage. We currently have a Canary/Dev Finch experiment that enables scroll to text and triggers Search to provide a scroll to text URL that navigates directly to the text. We are collecting UMA metrics to evaluate performance, as well as UKM metrics to find websites that have a low/zero match rate and may be breaking. We want to broaden our experimentation with an origin trial to allow sites to serve scroll-to-text URLs.

Experimental timeline

M76 - M79

Any risks when the experiment finishes?

No, with the feature disabled the targetText URL fragment will simply be processed as an element fragment ID and do nothing.

Ongoing technical constraints

None.

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

Yes.

Link to entry on the feature dashboard

https://chromestatus.com/feature/4733392803332096

[Jeffrey Yasskin]

On Thu, Jun 27, 2019 at 1:54 PM Nick Burris <nbu...@chromium.org> wrote:

Contact emails

nbu...@chromium.org, bmcq...@chromium.org, bo...@chromium.org 

Spec

https://github.com/bokand/ScrollToTextFragment

Is there enough support to move this into the WICG?

Did you ever request a TAG review?

Jeffrey

--
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/d7e0444c-9c31-4315-8166-e4eab04cfa12%40chromium.org.

[aar...@microsoft.com]

I’ve been noodling in this space for a while, riffing on ideas brought about by the Indie Web community [1]. I’ll get my draft Explainer finalized and up for discussion.

[1] https://indieweb.org/fragmention

Cheers,

Aaron

----

Aaron Gustafson (he/him/his)

Web Standards, Accessibility, PWAs

Microsoft Edge

@AaronGustafson

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

[Jochen Eisinger]

I want to point out that this experiment is a bit special, as the site that does the origin trial gets to influence behavior on another site.

In any case, if I understood this correctly, the idea to mitigate the timing attack is to only allow anchors where we believe the difference between finding them or not finding them is negligible, right?

--

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.

[PhistucK]

> I want to point out that this experiment is a bit special, as the site that does the origin trial gets to influence behavior on another site.

Why is that?

I thought sites that opt into this trial accept that #scroll=text-search (probably not the syntax) will scroll their page, not scroll the target page (in a different host). Am I misunderstanding?

In case the site that opted in is displayed in an iFrame, do those specific scroll events propagate to parent frames (I would expect not)?

Do they affect the timing of the load event (I would expect not)?

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALjhuifZ-cCFvaUk502CpTZi7Y2CcQWrftX2SH%2BcBQU_S9272A%40mail.gmail.com.

[nbu...@google.com]

Opened TAG review request: https://github.com/w3ctag/design-reviews/issues/392

On Tuesday, July 2, 2019 at 3:59:49 AM UTC-4, PhistucK wrote:

> I want to point out that this experiment is a bit special, as the site that does the origin trial gets to influence behavior on another site.

Why is that?

I thought sites that opt into this trial accept that #scroll=text-search (probably not the syntax) will scroll their page, not scroll the target page (in a different host). Am I misunderstanding?

In case the site that opted in is displayed in an iFrame, do those specific scroll events propagate to parent frames (I would expect not)?

Do they affect the timing of the load event (I would expect not)?

Jochen is correct, this experiment is special in that the origin that has the trial enabled is able to *provide* a #targetText= URL and the feature state is propagated to the destination where scroll to text activates.

 

☆PhistucK

On Mon, Jul 1, 2019 at 10:04 PM Jochen Eisinger <joc...@chromium.org> wrote:

I want to point out that this experiment is a bit special, as the site that does the origin trial gets to influence behavior on another site.

In any case, if I understood this correctly, the idea to mitigate the timing attack is to only allow anchors where we believe the difference between finding them or not finding them is negligible, right?

Our current mitigations are more strict (and I think it would be non-trivial to determine how long matching might take for a given text anchor) as we restrict to top-level (no iframes) full navigations with no opener (no window.open).

 

On Thu, Jun 27, 2019 at 10:54 PM Nick Burris <nbu...@chromium.org> wrote:

Contact emails

nbu...@chromium.org, bmcq...@chromium.org, bo...@chromium.org 

Spec

https://github.com/bokand/ScrollToTextFragment

Summary

Scroll To Text allows URLs to link to a piece of text in a webpage rather than just linking to an existing element fragment. The motivating use cases are to enable user sharing of specific content and allow references to deep-link to information.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/aKI6doxffgQ/7dzrVvo4CAAJ

Goals for experimentation

We want to gain insight into site compatibility with the proposed method of using the URL fragment to specify a target text passage. We currently have a Canary/Dev Finch experiment that enables scroll to text and triggers Search to provide a scroll to text URL that navigates directly to the text. We are collecting UMA metrics to evaluate performance, as well as UKM metrics to find websites that have a low/zero match rate and may be breaking. We want to broaden our experimentation with an origin trial to allow sites to serve scroll-to-text URLs.

Experimental timeline

M76 - M79

Any risks when the experiment finishes?

No, with the feature disabled the targetText URL fragment will simply be processed as an element fragment ID and do nothing.

Ongoing technical constraints

None.

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

Yes.

Link to entry on the feature dashboard

https://chromestatus.com/feature/4733392803332096

--
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/d7e0444c-9c31-4315-8166-e4eab04cfa12%40chromium.org.

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

[David Bokan]

On Tue, Jul 2, 2019 at 4:02 PM <nbu...@google.com> wrote:

On Tuesday, July 2, 2019 at 3:59:49 AM UTC-4, PhistucK wrote:

> I want to point out that this experiment is a bit special, as the site that does the origin trial gets to influence behavior on another site.
Why is that?

I thought sites that opt into this trial accept that #scroll=text-search (probably not the syntax) will scroll their page, not scroll the target page (in a different host). Am I misunderstanding?

In case the site that opted in is displayed in an iFrame, do those specific scroll events propagate to parent frames (I would expect not)?

Do they affect the timing of the load event (I would expect not)?

Jochen is correct, this experiment is special in that the origin that has the trial enabled is able to *provide* a #targetText= URL and the feature state is propagated to the destination where scroll to text activates.

 

Just want to add why we did this: limiting it to a single origin would drastically limit its use since the main use-case here is cross-origin (you can already write some client-side script to implement something like this on a single domain). If we limited the feature to only operate on the target origin, the link creator would somehow have to know that the target is opted into the experiment which isn't feasible. e.g. use cases like reference links on Wikipedia articles.

[David Bokan]

Forgot to answer the other parts of the question: we're restricting the feature to only top-level browsing contexts for now (i.e. no iframes, no window.open) to limit potential security issues. The load event timing shouldn't differ in relative terms but it's possible that the textual search may affect loading performance. That's something we want to measure in the trial.

[David Bokan]

On Mon, Jul 1, 2019 at 3:04 PM Jochen Eisinger <joc...@chromium.org> wrote:

I want to point out that this experiment is a bit special, as the site that does the origin trial gets to influence behavior on another site.

In any case, if I understood this correctly, the idea to mitigate the timing attack is to only allow anchors where we believe the difference between finding them or not finding them is negligible, right?

 We currently restrict the feature to only top-level browsing contexts without an opener and no same-document navigations. That is, an initiator should have no way to persist a scripting context across the navigation.

[PhistucK]

In other words... Google Search wants to use this and this is at least partially why this is special (affecting the target rather than the origin). ;)

☆PhistucK

--

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/CANMmsAuH3oZKq_VHU7Tg9V60xdqskQG%3DzDPxeORzDSCLp54VuQ%40mail.gmail.com.

[Jochen Eisinger]

On Wed, Jul 3, 2019 at 7:53 AM PhistucK <phis...@gmail.com> wrote:

In other words... Google Search wants to use this and this is at least partially why this is special (affecting the target rather than the origin). ;)

That's explicitly listed under "Goals for experimentation"

[PhistucK]

Not so explicitly, "Search" with a capital letter is not very explicit, it can mean a lot in the scope of blink-dev discussions.

Also, Google Search is already using the Finch trial, so this will open this up for other search engines (or bad actors).

☆PhistucK

[bo...@google.com]

On Wednesday, July 3, 2019 at 5:02:01 AM UTC-4, PhistucK wrote:

Not so explicitly, "Search" with a capital letter is not very explicit, it can mean a lot in the scope of blink-dev discussions.

Also, Google Search is already using the Finch trial, so this will open this up for other search engines (or bad actors).

Curious why you mention bad actors? We've taken a lot of care to make sure the feature can't be used to exfiltrate information or be used in a malicious way.

Yes, Google Search is already using this in a Finch experiment. An origin trial opens this up for anyone who wants to experiment with it.

If you, as an author, control the target domain you can accomplish the same thing using https://indieweb.org/fragmention. If we didn't enable the feature on the target origin it would limit the scope to toy examples on the same origin which isn't a representative usage and won't provide us with realistic feedback. 

[PhistucK]

I did not mean anything specific here, I was referring to the special nature of this experiment. If it happens to create undisclosed site vulnerabilities, bad actors can just sign up for the experiment and have their way.

That is not to say I am against it, it is just a potentially much bigger experiment than usual, because it can affect 100% of the sites (rather than the few-percents that are generally allowed for origin trials) if you get to them via a participating origin.

Offhand, I do not see a vulnerability (but I am not a security guy, anyway). The initial reply by Jochen just made me paranoid (but security people do have this tendency ;P). :)

The fact that Google Search automatically has it enabled by default, even if it is only in non-stable, is a bit worrying, though.

It is like the Hangouts-can-screen-share-without-an-extension-while-others-could-not which I really did/do not like. Or certain headers that are only sent to Google properties.

☆PhistucK

--

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/e1701841-4ad2-4354-80e8-7156452e88ff%40chromium.org.

[Daniel Bratell]

Just so that I understand, will this allow to scroll to any text fragment, regardless of whether it would have been inside the obviously reachable document area or not? Some sites like to hide ("preload") content outside the visible area, and this might come as a surprise to such sites.

If I understand correctly. 

Anything else that could come as a surprise?

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_%2BAcaoRoVJ_ucKxEvWTxG2ZLzAEYxJNNB6YDL4Wk2t8QQ%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[David Bokan]

On Thu, Jul 11, 2019 at 4:19 PM Daniel Bratell <bra...@opera.com> wrote:

Just so that I understand, will this allow to scroll to any text fragment, regardless of whether it would have been inside the obviously reachable document area or not? Some sites like to hide ("preload") content outside the visible area, and this might come as a surprise to such sites.

I believe this should work very similarly to the FindInPage feature (the implementation is based on it) so if the text isn't findable using that I would expect it to not be findable from the text fragment. Additionally,  if the text is found but isn't visible (i.e. it's visible rect is clipped out or in a display:none subtree) then it won't be scrolled into view.

We do expect some edge cases with things like collapsible headings; we're hoping this origin trial will help us determine how these edge cases look, how prevalent they are, and give us data and feedback on how best to address them. 

[aar...@microsoft.com]

Here is the explainer I’d been working on for Arbitrary Text Fragments: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/Fragments/explainer.md

It’s related work, but an alternate take worth considering.

Cheers,

Aaron

[David Bokan]

HI Aaron, thank for sharing. Interestingly, this looks a lot like the first iteration of our proposal :P. In experiments we ran, we found that a simple text fragment was often too ambiguous. The WebAnnotations group found the same thing when working on the related TextQuoteSelector - for this we added prefix/suffix terms to help disambiguate shorter passages. We've tried to base the semantics of this feature on TextQuoteSelector since the use cases are very similar.

You mention this and other issues in your explainer but the recommended API doesn't appear to address those. I think we've worked through many of the challenges here and have solutions to them. Given that we appear to be trying to solve the same problem, would you be open to working together in a WIGC repo? We could move https://github.com/bokand/ScrollToTextFragment into WICG and proceed from there. Would be curious if you have any feedback/critiques of the current approach.

Thanks,

David

[Aaron Gustafson]

That would be great! I went back & forth on the need for disambiguation to be honest. The often-changing nature of the web makes it particularly challenging as the surrounding text may be changed or edited post publication too. That was one of the main reasons I decided to let potential ambiguity stand and piggyback on the Find In Page feature to enable users to look for any instance of the quoted text on the page. That system does start to break down when users link to single repeated words (or phrases), but (in my mind at least) that’s kind of a user failure of the user rather than the technology. I don’t mean that to imply we shouldn‘t do what we can to help users link to and share the bits they want, but at the same time, I don’t want to risk introducing more fragility if a page changes because we have the prefix and suffix (if that makes sense).

 

Anyway, I‘d be thrilled to collaborate on this and I’d love to know more about the experiments you’ve run too.

 

Cheers,

 

Aaron

 

Aaron Gustafson (he/him/his) PWAs + Accessibility + Web Standards @AaronGustafson

 

--
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/NySZyk6UMEs/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/d372a8d7-2da7-412e-a677-360ade526641%40chromium.org.

[PhistucK]

Maybe there should simply be a fallback (if nothing is found with the surroundings, get to the first result of the text without the surroundings. Going to the top may get it wrong anyway, so do something with whatever you got).

☆PhistucK

[Alex Russell]

LGTM1 for Experimentation, but very keen to see TAG feedback as they have historically had a lot to say regarding URL structure and referencing within documents.

To unsubscribe from this group and all its topics, send an email to blin...@chromium.org.

[nbu...@google.com]

Thanks! The origin trial experiment is now live (https://developers.chrome.com/origintrials/#/view_trial/3084965744748789761) for M76 which is going to stable today.

[Nick Burris]

This experiment has been live for M76, M77, and M78, and will come to an end after M79. Throughout the experiment, we received feedback from Google Search, who used the feature to scroll to the text quoted in their Featured Snippets. We also gathered and implemented plenty of feedback via WICG repo issues and the TAG review. The feature is now in the intent-to-ship stage, currently with a few blockers that I detailed in this comment and are now mostly resolved - once we resolve the remainder of these issues (within the next week or so) I will update the intent to ship thread, and we hope to ship with M80.

Here's the origin trial feedback we got from Google Search:
“We experimented with Scroll To Text on Featured Snippets on Google Search, where it scrolls to and highlights the same passage on the source page upon opening. We see improvements in the search experience as a result of this feature. By allowing users to jump to the content that is most relevant to their queries, we observe that users consume content on the source page more effectively. Additionally, users end up consuming content from a wider range of search results. There are already two other similar launches within Google Search on small fraction of traffic. This feature will help greatly expand the coverage.”