[blink-dev] Re: TextFragmentFinder and its related objects cannot be GC?

[David Bokan]

Thanks for the heads up, I'll take a look 

On Monday, April 29, 2024 at 8:43:38 AM UTC-4 Bill Shen wrote:

> Hi, 
> I asked an issue here: https://issues.chromium.org/issues/336357543, 
> but it has not been processed for a long time. 
> Can anyone take a look?
>
> Thanks!

-- 
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/63252ea4-2fb4-4ab7-a43b-f7945cfae230n%40chromium.org.

Re: [blink-dev] Intent to Ship: 'pagereveal' event

[David Bokan]

On Friday, February 2, 2024 at 9:35:13 AM UTC-5 David Bokan wrote:

On Friday, February 2, 2024 at 1:18:42 AM UTC-5 Domenic Denicola wrote:

Can you un-tentative these tests?


Sure, will do this today! 


 Done.

-- 
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/3b2df66a-aadf-4c45-aa28-48c7344db9a0n%40chromium.org.

Re: [blink-dev] Intent to Ship: 'pagereveal' event

[David Bokan]

On Friday, February 2, 2024 at 1:18:42 AM UTC-5 Domenic Denicola wrote:

Can you un-tentative these tests?


Sure, will do this today! 

-- 
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/6b4280fe-cd1b-46a4-9de0-bd211e137992n%40chromium.org.

[blink-dev] Intent to Ship: 'pagereveal' event

[David Bokan]

Contact emailsbo...@chromium.org, khushalsa...@chromium.org,
nrosent...@chromium.org, vmp...@chromium.org

Explainer
https://github.com/WICG/view-transitions/blob/main/cross-doc-explainer.md

Specificationhttps://html.spec.whatwg.org/#reveal

Design docs
https://github.com/WICG/view-transitions/blob/main/cross-doc-explainer.md

Summary

The `pagereveal` event is fired on a Document's window object at the first
render opportunity after a Document is: initially loaded, restored from the
back-forward cache, or activated from a prerender. It can be used by a page
author to set up a page entry UX - such as a ViewTransition from a previous
state. This feature is split out from the larger Cross Document View
Transition project.


Blink componentBlink>ViewTransitions


Search tagstransition ,
firstrender , reveal
, event
, viewtransition


TAG reviewhttps://github.com/w3ctag/design-reviews/issues/851

Note: TAG review was for Cross-Document View Transitions which included
this event as a piece. I asked TAG whether they'd like to do a separate
review but didn't receive a response.

TAG review statusIssues addressed

Risks


Interoperability and Compatibility

This is a new event so shouldn't have any compatibility risks. Usual
interop risk of other engines not adopting it exists but this should be low
since it's had input and discussion[1] from engineers of both WebKit and
Mozilla and is a dependency of cross-document view transitions which has
received a positive signal from at least Mozilla[2] (waiting to hear from
Apple[3]). [1] https://github.com/whatwg/html/issues/9315 [2]
https://github.com/mozilla/standards-positions/issues/677

[3] https://github.com/WebKit/standards-positions/issues/302


*Gecko*: Positive (https://github.com/mozilla/standards-positions/issues/677)
See:
https://github.com/mozilla/standards-positions/issues/677#issuecomment-1904541389

*WebKit*: No signal (
https://github.com/WebKit/standards-positions/issues/303) Awaiting response.

*Web developers*: No signals

*Other signals*:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?

No


Debuggability

None


Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, ChromeOS, Android, and Android WebView)?Yes

This is a standard HTML event applicable to all platforms


Is this feature fully tested by web-platform-tests

?Yes

https://wpt.fyi/results/html/browsers/browsing-the-web/history-traversal/pagereveal?label=experimental&label=master&aligned


Flag name on chrome://flags
chrome://flags/#enable-experimental-web-platform-features

Finch feature namePageRevealEvent

Requires code in //chrome?False

Tracking bughttps://crbug.com/1466250

Estimated milestones
Shipping on desktop 123
DevTrial on desktop 120
Shipping on Android 123
DevTrial on Android 120
Shipping on WebView 123

Anticipated spec changes

Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github issues
in the project for the feature specification) whose resolution may
introduce web compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way).
None

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5205586941837312

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f0f76584-ea3f-43ab-946c-b920fc064344n%40chromium.org

This intent message was generated by Chrome Platform Status
.

-- 
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/CANMmsAvhWAzVrHCudjLgQRtePgqEHucNqb27Wkn9r4dCKeUTWg%40mail.gmail.com.

Re: [blink-dev] Intent to Prototype: 'firstrender' event

[David Bokan]

>
> On Thu, Sep 28, 2023 at 3:06 PM Sangwhan Moon  wrote:
>>
>>> This looks useful.
>>>
>>> Likely a quick review (I don't see why it would be contentious) so maybe
>>> not a big deal, but any reason why there is no TAG review?
>>>
>>
>> It was TAG-reviewed as part of CSS view transitions:
>> https://github.com/w3ctag/design-reviews/issues/851
>>
>> FYI - we had a quick debate amongst our team about whether that larger
review was sufficient for this and decided to ask TAG whether they'd like
us to file a separate review. If we do, I'll update the chromestatus entry.

This is exciting!! (also as a scheduling primitive - e.g. as a way to start
> loading or executing certain scripts only after the first render)


It's technically _before_ the first render so that the author can make
modifications knowing they'll be displayed to the user ~immediately.


> Are you planning to have the event first more or less at a similar time to
> when first paint is reported? I'm guessing that we want that event to run
> after rendering is kicked off (rather than have it delay the first render).
>

I believe it'll be before first paint since it's early in the "update the
rendering
"
steps of the spec and, IIRC, the paint-related metrics measure when pixels
change on the display.

We do actually want this to run _before_ rendering so that the event can
affect the initial output. For example, to determine what kind of page the
navigation is coming from and set up the appropriate CSS
view-transition-names. This must happen before the first frame is rendered.
Though, as you mention, this does mean authors will have to be somewhat
careful not to unnecessarily delay first paint.

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

[blink-dev] Intent to Prototype: 'firstrender' event

[David Bokan]

Contact emails
bo...@chromium.org, khushalsa...@chromium.org, nrosent...@chromium.org, 
vmp...@chromium.org

Explainer
https://github.com/WICG/view-transitions/blob/main/cross-doc-explainer.md
(See https://github.com/whatwg/html/issues/9315 for design discussion 
around this event specifically)

Specification
https://drafts.csswg.org/css-view-transitions-2/#pagerevealevent

Summary

The `firstrender` event is fired on a Document's window object at the first 
render opportunity after a Document is: initially loaded, restored from the 
back-forward cache, activated from a prerender. It can be used by a page 
author to setup a page entry UX - such as a ViewTransition from a previous 
state. This feature is split out from the larger 
ViewTransition-on-Navigation project.


Blink component
Blink>ViewTransitions 


Motivation

This event enables authors to make last-minute DOM changes once a document 
is ready to be presented but before it is rendered. In particular, this 
enables an author to setup their style for a ViewTransition, if one is 
available, from a single convenient place. Without it, authors would have 
to do this from a `requestAnimationFrame` and also remember to add listen 
to `pageshow.persisted` to handle the BFCache case, which is error prone. 
This event is also how a cross-document ViewTransition object is passed 
into the incoming Document.


Initial public proposal
https://github.com/whatwg/html/issues/9315

Search tags
transition , firstrender 
, reveal 
, event 
, viewtransition 


TAG review
None

TAG review status
Pending

Risks

Interoperability and Compatibility

None

*Gecko*: No signal

*WebKit*: No signal

*Web developers*: No signals

*Other signals*:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that 
it has potentially high risk for Android WebView-based applications?

None


Debuggability

None

Is this feature fully tested by web-platform-tests 

?
No

Flag name on chrome://flags
None

Finch feature name
None

Non-finch justification
None

Requires code in //chrome?
False

Tracking bug
https://crbug.com/1466250

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5205586941837312

This intent message was generated by Chrome Platform Status 
.

-- 
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/f0f76584-ea3f-43ab-946c-b920fc064344n%40chromium.org.

[blink-dev] Removing FocuslessSpatialNavigation runtime-enabled-feature

[David Bokan]

Hi all,

We added the FocuslessSpatialNavigation feature to modify how
spatial-navigation works back in 2019, however, it was never used for our
use-case so I'd like to remove it.

However, since it was mostly working I just want to double check that there
aren't any other embedders currently relying on this flag?

If I don't hear back in the affirmative by next week I'll remove this code
path in M118.

Thanks,
David

-- 
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/CANMmsAuzmO62NtLLE1cg-xBpAyQed2%2BD_kdjpeOmx_3y3_D6Nw%40mail.gmail.com.

Re: [blink-dev] PSA: Adjacent CDATA sections in XML documents will now be merged

[David Bokan]

Apologies, I wasn't aware the PSA guidance has changed. I've created
https://chromestatus.com/feature/5168429241204736 to track the change.

As to an intent, I believed the breakage risk to be small so thought PSA
was sufficient. I think so since we already can perform this kind of merge
(from https://crrev.com/2fdffd306d488, granted, the case that CL merges is
very unlikely to happen). Additionally, if this case does get hit, the
resulting data would still be consistent, applications are likely to
concatenate the CDATA sections anyway.

But I didn't have hard data so I did some digging today:

Via the XMLDocument UseCounter, 0.18% of page loads include an XMLDocument
(this is the *upper bound* on potentially affected page loads).

I went looking through HTTPArchive data using the `requests` and
`resposne_bodies` tables from 2023_08_01_desktop. I filtered requests to:

Content-Type header with "application/xhtml+xml"
request_type "Document"

Which I believe is the case where XMLDocument is used.

I then looked at the response bodies for those requests looking for
adjacent CDATA sections: looking for instances of the string "]]>

[blink-dev] PSA: Adjacent CDATA sections in XML documents will now be merged

[David Bokan]

Hi blink-dev,

I just landed https://crrev.com/f848cbce89b422 which will cause an XML 
document to merge sibling CDATA section nodes into a single CDATA section 
during parsing.

The reason for this is that libxml emits separate nodes at 300 byte 
boundaries for a CDATA section that's spread across more than one input 
chunk. If the CDATA is split across input chunks, libxml also emits 
separate nodes and this merging behavior was already applied to this case 
by https://crrev.com/2fdffd306d488 - the change I'm making generalizes this 
to also cover the 300 byte chunking behavior (see CL commit message for 
more details).

I'm hoping this is web-compatible but have added a flag-guard if we need to 
turn it off. If anyone sees any breakage related to this or knows specific 
sites/apps to check please let me know.

Thanks!
David

-- 
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/4bfd9115-b843-4dc7-b10f-26b87d215689n%40chromium.org.

Re: [blink-dev] Scroll to Text Fragment - Gmail doesn't preview the link

[David Bokan]

Ah, I see it now...it's because GMail doesn't use an  tag...it fakes it
and adds a click handler. Unfortunately there's not much you can do as a
user in this case (aside from copy/pasting the URL manually) - ideally
Gmail would fix their window.open to include noopener.

On Tue, May 9, 2023 at 2:05 PM PhistucK  wrote:

> That also does not work (in draft mode), but this is probably because it
> does not have an href (and it probably uses the same code path as a
> normal click), so a broken GMail implementation that breaks it.
>
> ☆*PhistucK*
>
>
> On Tue, May 9, 2023 at 3:24 PM David Bokan  wrote:
>
>> Text fragments work just fine from `window.open` but have restrictions
>> about being isolated from other pages. I suspect gmail isn't adding
>> `noopener` in window.open so that the opened page remains reachable from
>> gmail.
>>
>> If that's the case, your link should work if you ctrl/cmd-click the link
>> or right-click>"open in new tab".
>>
>> On Monday, May 8, 2023 at 7:32:58 AM UTC-4 PhistucK wrote:
>>
>>> Looks like the issue is that opening a URL with a scroll-to-fragment via
>>> window.open(...) does not scroll/highlight. GMail uses window.open(...)
>>> in draft mode.
>>>
>>> Here is a small test case (copy it and paste it in the address bar and
>>> click on both of the links) -
>>> data:text/html,window.open
>>> normal
>>> href
>>>
>>>
>>> There is also some weird handling of the fragment. If you unescape more
>>> than one of the commas (%2C), it stops highlighting -
>>> data:text/html,normal
>>> href with one unescaped comma normal
>>> href with two unescaped commas
>>>
>>> Note that the URL you mentioned does not really have an accurate
>>> scroll-to-fragment, it uses %22 for all quotes, but the page uses special
>>> types of quotes (not sure why it works, but maybe there is
>>> some pre-processing for easier URL creation).
>>>
>>>
>>> You can report this at crbug.com. Be sure to search for an existing
>>> issue first, though.
>>>
>>>
>>>
>>> ☆*PhistucK*
>>>
>>>
>>> On Wed, May 3, 2023 at 1:02 AM Michael Bradley 
>>> wrote:
>>>
>>>> When drafting a gmail with a link containing a *ScrollToTextFragment*,
>>>> Duties of Loyalty, Care and Obedience
>>>> <https://www.councilofnonprofits.org/running-nonprofit/governance-leadership/board-roles-and-responsibilities#:~:text=Just%20as%20for%20any%20corporation%2C%20the%20board%20of%20directors%20of%20a%20nonprofit%20has%20three%20primary%20legal%20duties%20known%20as%20the%20%22duty%20of%20care%2C%22%20%22duty%20of%20loyalty%2C%22%20and%20%22duty%20of%20obedience%2E%22>,
>>>> clicking on the link (in Draft) shows the dialog, "Go to link: https
>>>> ... | Change | Remove", but following the link to test my intention to
>>>> scroll merely loads the target webpage.
>>>>
>>>> However, sending the draft to a Yahoo email renders the highlighted
>>>> text on the target webpage.  This is the desired result, but it would be
>>>> more convenient to verify the intended behavior when testing the link in
>>>> the draft.
>>>>
>>>> Windows 10 Home 22H2 1/‎14/‎2021 Build: 19045.2846
>>>> Chrome Version 112.0.5615.138 (Official Build) (64-bit)
>>>> GMail: 05-02-2023, No Add-ons, Advanced: all disabled.
>>>>
>>>> I understand the desire to disable this behavior, but I appreciate what
>>>> this feature can do, as demonstrated in this link.
>>>>
>>>> --
>>>> 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/2650c78e-e0f4-4d5d-9918-62a6ece72c1cn%40chromium.org
>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2650c78e-e0f4-4d5d-9918-62a6ece72c1cn%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/CANMmsAsCKmOV%2BQAE43ObpX_KpfbmjFroS92jLDjkFYBXxpG5yw%40mail.gmail.com.

Re: [blink-dev] Scroll to Text Fragment - Gmail doesn't preview the link

['David Bokan' via blink-dev]

Text fragments work just fine from `window.open` but have restrictions 
about being isolated from other pages. I suspect gmail isn't adding 
`noopener` in window.open so that the opened page remains reachable from 
gmail.

If that's the case, your link should work if you ctrl/cmd-click the link or 
right-click>"open in new tab".

On Monday, May 8, 2023 at 7:32:58 AM UTC-4 PhistucK wrote:

> Looks like the issue is that opening a URL with a scroll-to-fragment via 
> window.open(...) does not scroll/highlight. GMail uses window.open(...) 
> in draft mode.
>
> Here is a small test case (copy it and paste it in the address bar and 
> click on both of the links) -
> data:text/html,window.open
>  
> normal
>  
> href
>
>
> There is also some weird handling of the fragment. If you unescape more 
> than one of the commas (%2C), it stops highlighting -
> data:text/html,normal
>  
> href with one unescaped comma normal
>  
> href with two unescaped commas
>
> Note that the URL you mentioned does not really have an accurate 
> scroll-to-fragment, it uses %22 for all quotes, but the page uses special 
> types of quotes (not sure why it works, but maybe there is 
> some pre-processing for easier URL creation).
>
>
> You can report this at crbug.com. Be sure to search for an existing issue 
> first, though.
>
>
>
> ☆*PhistucK*
>
>
> On Wed, May 3, 2023 at 1:02 AM Michael Bradley  wrote:
>
>> When drafting a gmail with a link containing a *ScrollToTextFragment*,  
>> Duties 
>> of Loyalty, Care and Obedience 
>> ,
>>  
>> clicking on the link (in Draft) shows the dialog, "Go to link: https ... 
>> | Change | Remove", but following the link to test my intention to 
>> scroll merely loads the target webpage.
>>
>> However, sending the draft to a Yahoo email renders the highlighted text 
>> on the target webpage.  This is the desired result, but it would be more 
>> convenient to verify the intended behavior when testing the link in the 
>> draft.
>>
>> Windows 10 Home 22H2 1/‎14/‎2021 Build: 19045.2846 
>> Chrome Version 112.0.5615.138 (Official Build) (64-bit)
>> GMail: 05-02-2023, No Add-ons, Advanced: all disabled.
>>
>> I understand the desire to disable this behavior, but I appreciate what 
>> this feature can do, as demonstrated in this link.
>>
>> -- 
>> 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/2650c78e-e0f4-4d5d-9918-62a6ece72c1cn%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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/45594dcf-62d0-4165-a0f4-cce65821b6e2n%40chromium.org.

Re: [blink-dev] Intent to Ship: Android OSK resizes visual viewport by default + opt-out

[David Bokan]

On Thursday, October 13, 2022 at 11:59:54 AM UTC-4 David Bokan wrote:

> Users can undo the change using 
> chrome://flags/osk-resizes-visual-viewport-by-default  to confirm if this 
> change is responsible.
>

To clarify, setting this flag to "Disabled" will unship this change.

-- 
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/b64164ba-4c6e-4573-8d35-101390461e48n%40chromium.org.

Re: [blink-dev] Intent to Ship: Android OSK resizes visual viewport by default + opt-out

[David Bokan]

The feature is enabled in trunk with all the changes to match Bramus' 
explainer (thanks!), as well as an enterprise policy, in time for today's 
M108 branch.

Please file bugs to me or reply here if you find issues related to this 
change. Users can undo the change using 
chrome://flags/osk-resizes-visual-viewport-by-default  to confirm if this 
change is responsible.

Thanks!
David

On Tuesday, October 11, 2022 at 7:20:20 PM UTC-4 Bramus Van Damme wrote:

> The explainer has also been updated to match the spec: 
> https://github.com/bramus/viewport-resize-behavior/blob/main/explainer.md#proposal
>
> B!
>
>
> On Tuesday, October 11, 2022 at 5:26:54 PM UTC+2 David Bokan wrote:
>
>> Update: the PR has been merged 
>> <https://github.com/w3c/csswg-drafts/pull/7826>!
>>
>> There's been some small changes to naming, the tl;dr, authors will be 
>> able to keep the existing OSK resize behavior by adding this meta tag (or 
>> modifying their existing one):
>>
>> 
>>
>> Will land changes in our implementation today to make that match the spec 
>> text and then enable in trunk.
>>
>> Thanks,
>> David
>>
>> On Monday, October 10, 2022 at 2:34:41 PM UTC-4 David Bokan wrote:
>>
>>> Thanks everyone!
>>>
>>> I'm still waiting on a confirmation for the last remaining issue on the 
>>> spec PR 
>>> <https://github.com/w3c/csswg-drafts/pull/7826#discussion_r990725831> but 
>>> I hope to have that resolved and the changes enabled in trunk in the next 
>>> day or two.
>>>
>>> I'll update this thread when that happens.
>>>
>>> On Friday, October 7, 2022 at 5:52:39 AM UTC-4 Mike West wrote:
>>>
>>>> LGTM3.
>>>>
>>>> -mike
>>>>
>>>>
>>>> On Fri, Oct 7, 2022 at 4:56 AM Yoav Weiss  
>>>> wrote:
>>>>
>>>>> LGTM2 under the same conditions!
>>>>>
>>>>> On Fri, Oct 7, 2022 at 2:23 AM Mike Taylor  
>>>>> wrote:
>>>>>
>>>>>> I see that Emilio has approved 
>>>>>> https://github.com/w3c/csswg-drafts/pull/7826, with a few 
>>>>>> suggestions.
>>>>>>
>>>>>> LGTM1 to ship w/ the review comments addressed and the PR landing 
>>>>>> (and thanks for speccing it!).
>>>>>>
>>>>>> On 9/23/22 10:17 PM, David Bokan wrote:
>>>>>>
>>>>>> Contact emails
>>>>>>
>>>>>> bo...@chromium.org
>>>>>>
>>>>>> Explainer 
>>>>>>
>>>>>> https://github.com/bramus/viewport-resize-behavior/blob/main/explainer.md
>>>>>>
>>>>>> Specification
>>>>>> The resize behavior of the virtual keyboard is not specified.
>>>>>> The viewport meta tag is not yet fully specified 
>>>>>> <https://drafts.csswg.org/css-viewport/#viewport-meta>.
>>>>>> See also https://github.com/w3c/csswg-drafts/issues/7767.
>>>>>>
>>>>>> Summary
>>>>>> This intent:
>>>>>>
>>>>>>- Changes the Android virtual keyboard such that it resizes the 
>>>>>> visual 
>>>>>>viewport only, rather than the current behavior of resizing the 
>>>>>> initial 
>>>>>>containing block (ICB) and layout viewport (LVP). 
>>>>>>- Ships support for a new meta-viewport key interactive-widgets 
>>>>>>which can be used to opt-out of the above change, and instead retain 
>>>>>> the 
>>>>>>old behavior.
>>>>>>
>>>>>>Example: >>>>>content=”interactive-widgets=resize-layout”> 
>>>>>>
>>>>>>
>>>>>> *Motivation *Browsers do not currently agree on how the virtual 
>>>>>> keyboard should interact with the viewport:
>>>>>>
>>>>>>- 
>>>>>>
>>>>>>Chrome for Android and Firefox for Android both resize the initial 
>>>>>>containing block and  layout viewport.
>>>>>>- 
>>>>>>
>>>>>>Chrome for ChromeOS and Windows; and Safari/iOS both resize the 
>>>>>> visual 
>>>>>>viewport only.
>>>>>>
>&g

Re: [blink-dev] Intent to Ship: Android OSK resizes visual viewport by default + opt-out

[David Bokan]

Update: the PR has been merged 
<https://github.com/w3c/csswg-drafts/pull/7826>!

There's been some small changes to naming, the tl;dr, authors will be able 
to keep the existing OSK resize behavior by adding this meta tag (or 
modifying their existing one):



Will land changes in our implementation today to make that match the spec 
text and then enable in trunk.

Thanks,
David

On Monday, October 10, 2022 at 2:34:41 PM UTC-4 David Bokan wrote:

> Thanks everyone!
>
> I'm still waiting on a confirmation for the last remaining issue on the 
> spec PR 
> <https://github.com/w3c/csswg-drafts/pull/7826#discussion_r990725831> but 
> I hope to have that resolved and the changes enabled in trunk in the next 
> day or two.
>
> I'll update this thread when that happens.
>
> On Friday, October 7, 2022 at 5:52:39 AM UTC-4 Mike West wrote:
>
>> LGTM3.
>>
>> -mike
>>
>>
>> On Fri, Oct 7, 2022 at 4:56 AM Yoav Weiss  wrote:
>>
>>> LGTM2 under the same conditions!
>>>
>>> On Fri, Oct 7, 2022 at 2:23 AM Mike Taylor  
>>> wrote:
>>>
>>>> I see that Emilio has approved 
>>>> https://github.com/w3c/csswg-drafts/pull/7826, with a few suggestions.
>>>>
>>>> LGTM1 to ship w/ the review comments addressed and the PR landing (and 
>>>> thanks for speccing it!).
>>>>
>>>> On 9/23/22 10:17 PM, David Bokan wrote:
>>>>
>>>> Contact emails
>>>>
>>>> bo...@chromium.org
>>>>
>>>> Explainer 
>>>>
>>>> https://github.com/bramus/viewport-resize-behavior/blob/main/explainer.md
>>>>
>>>> Specification
>>>> The resize behavior of the virtual keyboard is not specified.
>>>> The viewport meta tag is not yet fully specified 
>>>> <https://drafts.csswg.org/css-viewport/#viewport-meta>.
>>>> See also https://github.com/w3c/csswg-drafts/issues/7767.
>>>>
>>>> Summary
>>>> This intent:
>>>>
>>>>- Changes the Android virtual keyboard such that it resizes the visual 
>>>>viewport only, rather than the current behavior of resizing the initial 
>>>>containing block (ICB) and layout viewport (LVP). 
>>>>- Ships support for a new meta-viewport key interactive-widgets 
>>>>which can be used to opt-out of the above change, and instead retain 
>>>> the 
>>>>old behavior.
>>>>
>>>>Example: >>>content=”interactive-widgets=resize-layout”> 
>>>>
>>>>
>>>> *Motivation *Browsers do not currently agree on how the virtual 
>>>> keyboard should interact with the viewport:
>>>>
>>>>- 
>>>>
>>>>Chrome for Android and Firefox for Android both resize the initial 
>>>>containing block and  layout viewport.
>>>>- 
>>>>
>>>>Chrome for ChromeOS and Windows; and Safari/iOS both resize the visual 
>>>>viewport only.
>>>>
>>>> This discrepancy is a source of frustration for authors [1] 
>>>> <https://stackoverflow.com/questions/52384678/how-to-stop-soft-keyboard-resizing-chrome-browser-window-on-android-mobiles>
>>>>  
>>>> [2] 
>>>> <https://stackoverflow.com/questions/67800763/how-to-avoid-the-android-keyboard-is-closed-automatically-after-i-click-on-an-in>
>>>>  
>>>> [3] 
>>>> <https://medium.com/@sruthisreemenon/avoid-ui-distortions-during-keyboard-display-for-a-mobile-friendly-webpage-86eb99590a13>
>>>>  
>>>> [4] <https://bugs.chromium.org/p/chromium/issues/detail?id=404315>. 
>>>> While both approaches have valid use-cases, we believe that resizing the 
>>>> visual viewport is the best default, as it avoids any layout-jank from 
>>>> opening the keyboard, and in general interferes with the page as little as 
>>>> possible.
>>>>
>>>> Other vendors also have long-standing issues in this area: 
>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1007286
>>>>
>>>> This intent improves interop for mobile viewports, a priority 
>>>> investigation 
>>>> area for Interop 2022 <https://wpt.fyi/interop-2022>. Mobile viewports 
>>>> (especially the meta tag) are unfortunately not well specified, and we 
>>>> plan 
>>>> to work on resolving CSSWG issue 7

Re: [blink-dev] Intent to Ship: Android OSK resizes visual viewport by default + opt-out

[David Bokan]

Thanks everyone!

I'm still waiting on a confirmation for the last remaining issue on the 
spec PR 
<https://github.com/w3c/csswg-drafts/pull/7826#discussion_r990725831> but I 
hope to have that resolved and the changes enabled in trunk in the next day 
or two.

I'll update this thread when that happens.

On Friday, October 7, 2022 at 5:52:39 AM UTC-4 Mike West wrote:

> LGTM3.
>
> -mike
>
>
> On Fri, Oct 7, 2022 at 4:56 AM Yoav Weiss  wrote:
>
>> LGTM2 under the same conditions!
>>
>> On Fri, Oct 7, 2022 at 2:23 AM Mike Taylor  
>> wrote:
>>
>>> I see that Emilio has approved 
>>> https://github.com/w3c/csswg-drafts/pull/7826, with a few suggestions.
>>>
>>> LGTM1 to ship w/ the review comments addressed and the PR landing (and 
>>> thanks for speccing it!).
>>>
>>> On 9/23/22 10:17 PM, David Bokan wrote:
>>>
>>> Contact emails
>>>
>>> bo...@chromium.org
>>>
>>> Explainer 
>>> https://github.com/bramus/viewport-resize-behavior/blob/main/explainer.md
>>>
>>> Specification
>>> The resize behavior of the virtual keyboard is not specified.
>>> The viewport meta tag is not yet fully specified 
>>> <https://drafts.csswg.org/css-viewport/#viewport-meta>.
>>> See also https://github.com/w3c/csswg-drafts/issues/7767.
>>>
>>> Summary
>>> This intent:
>>>
>>>- Changes the Android virtual keyboard such that it resizes the visual 
>>>viewport only, rather than the current behavior of resizing the initial 
>>>containing block (ICB) and layout viewport (LVP). 
>>>- Ships support for a new meta-viewport key interactive-widgets 
>>>which can be used to opt-out of the above change, and instead retain the 
>>>old behavior.
>>>
>>>Example: >>content=”interactive-widgets=resize-layout”> 
>>>
>>>
>>> *Motivation *Browsers do not currently agree on how the virtual 
>>> keyboard should interact with the viewport:
>>>
>>>- 
>>>
>>>Chrome for Android and Firefox for Android both resize the initial 
>>>containing block and  layout viewport.
>>>- 
>>>
>>>Chrome for ChromeOS and Windows; and Safari/iOS both resize the visual 
>>>viewport only.
>>>
>>> This discrepancy is a source of frustration for authors [1] 
>>> <https://stackoverflow.com/questions/52384678/how-to-stop-soft-keyboard-resizing-chrome-browser-window-on-android-mobiles>
>>>  
>>> [2] 
>>> <https://stackoverflow.com/questions/67800763/how-to-avoid-the-android-keyboard-is-closed-automatically-after-i-click-on-an-in>
>>>  
>>> [3] 
>>> <https://medium.com/@sruthisreemenon/avoid-ui-distortions-during-keyboard-display-for-a-mobile-friendly-webpage-86eb99590a13>
>>>  
>>> [4] <https://bugs.chromium.org/p/chromium/issues/detail?id=404315>. 
>>> While both approaches have valid use-cases, we believe that resizing the 
>>> visual viewport is the best default, as it avoids any layout-jank from 
>>> opening the keyboard, and in general interferes with the page as little as 
>>> possible.
>>>
>>> Other vendors also have long-standing issues in this area: 
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1007286
>>>
>>> This intent improves interop for mobile viewports, a priority investigation 
>>> area for Interop 2022 <https://wpt.fyi/interop-2022>. Mobile viewports 
>>> (especially the meta tag) are unfortunately not well specified, and we plan 
>>> to work on resolving CSSWG issue 7767 
>>> <https://github.com/w3c/csswg-drafts/issues/7767> in parallel with this 
>>> intent. In the meantime we plan to add this feature to the Compat spec 
>>> <https://compat.spec.whatwg.org/>.
>>>
>>> Blink component
>>> Blink>Scroll 
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EScroll>
>>>
>>> TAG review
>>> N/A
>>>
>>> TAG review status
>>> Not applicable
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> The main risk with this change is web apps which critically depend on 
>>> the current LVP-resize behavior, e.g. a chat app with a message box fixed 
>>> above the keyboard.
>>>
>>> Those use-cases would no longer be possible with the default

Re: [blink-dev] Intent to Ship: Android OSK resizes visual viewport by default + opt-out

['David Bokan' via blink-dev]

On Thu, Sep 29, 2022 at 8:44 PM Rick Byers  wrote:

> I am worried about the web compat impact. David, will you also have a
> finch kill-switch so that we can flip the default quickly if needed (eg.
> during stable roll out)?
>

Yup, this will be revertable via Finch.

 Worst case could we split out the new API from the default so that sites
> could explicitly opt-into the new behavior prior to the default changing?


 We did discuss this as a possibility and this is the fallback plan if we
do find too much compat impact. I think the concern with it was that the
kind of sites we're worried about are the ones that just won't get updated
at all (i.e. it's very low effort to add the opt-out meta and get back to
the old behavior), but this could be a useful way to give authors time.

I'll split the flag into two, one for the API and one for the default
behavior so we have that control prior to shipping.

-- 
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/CANMmsAv%3DQBpW7OK7KJfLE2wfOT%3DRW5BKkyF6Ot-PdMATSMeYuQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Android OSK resizes visual viewport by default + opt-out

[David Bokan]

Sure, I'll start on a PR.

Taking another look, there does seem to be some basic parsing of the meta
in CSS Viewport .
It's still a fairly early-stage spec but I wonder if it'd make more sense
to just add the `interactive-widgets` keyword there rather than bouncing it
between the two specs? I could also help flesh out the meta processing
model more generally there.

On Wed, Sep 28, 2022 at 2:26 AM Philip Jägenstedt 
wrote:

> On Tue, Sep 27, 2022 at 7:07 PM Chris Harrelson 
> wrote:
>
>> (API owner hat off for this intent, I'm one of the people working on this
>> feature change)
>>
>> On Tue, Sep 27, 2022 at 1:32 AM Philip Jägenstedt 
>> wrote:
>>
>>> I think this plan makes sense, but the lack of a spec makes it unusual.
>>>
>>> Can you say more about how this will eventually be spec'd, and who is
>>> signed up to push that work to completion?
>>>
>>
>> The feature will be documented in the Compat spec for now, and once there
>> is spec text for CSS viewport we'll add it there. The  tag is not
>> specified at all at present..
>>
>
> Ah yes, it was linked in the text. Will someone send a pull request for
> https://github.com/whatwg/compat? Normally we'd block shipping on the
> spec change being made, and since the Compat spec exists and it sounds like
> there's multi-vendor support, I think we can stick to that here too, right?
>
> Since Firefox Android would also need to change to get full interop, a
>>> stronger statement from Mozilla would be really helpful. Would they be
>>> happy to ship this if it turns out to be web compatible in Chrome?
>>>
>>
>> In a discussion with Emilio (cc'd) at TPAC, he informally agreed it's
>> probably fine to switch Firefox Android to match in a similar time frame.
>>
>> (Emilio, please let me know if I've misquoted in any way. :) )
>>
>
> Sounds good! If we do a compat spec PR, support on that would do the
> trick.
>

-- 
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/CANMmsAuM-kW5PP9_%2BF-1y12gE0GK-3Z84YqopTasbUOX6n-ZQw%40mail.gmail.com.

[blink-dev] Intent to Ship: Android OSK resizes visual viewport by default + opt-out

[David Bokan]

Contact emails

bo...@chromium.org

Explainer
https://github.com/bramus/viewport-resize-behavior/blob/main/explainer.md

Specification
The resize behavior of the virtual keyboard is not specified.
The viewport meta tag is not yet fully specified 
.
See also https://github.com/w3c/csswg-drafts/issues/7767.

Summary
This intent:

   - Changes the Android virtual keyboard such that it resizes the visual 
   viewport only, rather than the current behavior of resizing the initial 
   containing block (ICB) and layout viewport (LVP).
   - Ships support for a new meta-viewport key interactive-widgets which 
   can be used to opt-out of the above change, and instead retain the old 
   behavior.
   
   Example: 


*Motivation*Browsers do not currently agree on how the virtual keyboard 
should interact with the viewport:

   - 
   
   Chrome for Android and Firefox for Android both resize the initial 
   containing block and  layout viewport.
   - 
   
   Chrome for ChromeOS and Windows; and Safari/iOS both resize the visual 
   viewport only.
   
This discrepancy is a source of frustration for authors [1] 

 
[2] 

 
[3] 

 
[4] . While 
both approaches have valid use-cases, we believe that resizing the visual 
viewport is the best default, as it avoids any layout-jank from opening the 
keyboard, and in general interferes with the page as little as possible.

Other vendors also have long-standing issues in this area: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1007286

This intent improves interop for mobile viewports, a priority investigation 
area for Interop 2022 . Mobile viewports 
(especially the meta tag) are unfortunately not well specified, and we plan 
to work on resolving CSSWG issue 7767 
 in parallel with this 
intent. In the meantime we plan to add this feature to the Compat spec 
.

Blink component
Blink>Scroll 


TAG review
N/A

TAG review status
Not applicable

Risks

Interoperability and Compatibility

The main risk with this change is web apps which critically depend on the 
current LVP-resize behavior, e.g. a chat app with a message box fixed above 
the keyboard.

Those use-cases would no longer be possible with the default behavior, and 
it was exactly this concern that stopped the previous attempt to ship this 
behavior 

 
at LGTM2.

What makes this intent different:

   - 
   
   The VirtualKeyboard API 
    now 
   exists, which exposes the geometry of the keyboard as CSS-reachable 
   environment variables allowing app full control over keyboard behavior.
   - 
   
   For an easier fix, a new  opt-out has been added which can be used 
   to maintain the current LVP-resize behavior. This is a trivial fix for any 
   affected web app.
   
As there is no good way to detect the problematic cases with a use-counter 
/ HTTP Archive query, we must instead rely on developer outreach to inform 
this change. That outreach will reference this intent, and therefore the 
results of that will be provided in a follow-up e-mail.

We expect this change to be a significant win for interop.

*Signals:*

Gecko: No response yet[standards position 
] (Some 
non-official positive signals from Mozilla engineers from discussions at 
TPAC and in 7767 
 
that Firefox could make this change)

WebKit: No response yet [standards position 
]. The change to 
Chromium’s default behavior would now align with WebKit behavior..

Web developers: See “author frustration” links earlier in this e-mail.

Other signals: N/A
WebView application risks

There is no intended behavior change for Android WebView. The Android app 
is responsible for sizing the WebView and can implement either mode via 
windowSoftInputMode 

.
Debuggability

N/A - There's no DevTools functionality directly related to the virtual 
keyboard.
Will this feature be supported on all six Blink platforms (Windows, Mac, 
Linux, Chrome OS, Android, and Android WebView)?

This change affects

[blink-dev] Re: Intent to Prototype: document.fragmentDirective API

[David Bokan]

cc: flackr@,girard@,mehdika@

On Friday, November 5, 2021 at 5:11:18 PM UTC-4 David Bokan wrote:

> (Note - this is an extension to the already shipped "scroll-to-text"/text 
> directive feature)
> Contact emailsbo...@chromium.org, blink-interactions-t...@google.com
>
> Explainer
> https://github.com/WICG/scroll-to-text-fragment/blob/main/fragment-directive-api.md
>
> SpecificationTODO: None yet
>
> SummaryWe propose exposing JavaScript APIs for working programmatically 
> with text directives (a.k.a. Scroll-to-text highlights)
>
>
> The new API enables authors to better work with text directives when they 
> are used to navigate to their page:
>
>
>
>- 
>
>Exposes the previously unavailable text directive (everything in the 
>URL fragment after “:~:”) in the URL to page authors via a structured API
>- 
>
>Exposes the DOM Range being highlighting
>- 
>
>Allows programmatically adding and removing text directive highlights
>
>
> It also enables authors to *create* deep link navigations:
>
>
>- Allows the browser to generate a text directive URL from an 
>arbitrary DOM Range, making it easier for authors to create deep links to 
>their own content.
>
>
> Blink componentBlink>Scroll 
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EScroll>
>
> MotivationWe’ve seen a few use cases crop up for working with text 
> fragments:
>
>
>
>- 
>
>Being able to attach commentary/UI to a targeted text range [received 
>as part of Mozilla’s feedback on the core text directive 
>
> <https://github.com/mozilla/standards-positions/issues/194#:~:text=prototyping%20on%20balance.-,The%20marginalia%20use%20case%20described%20at,-https%3A//indieweb.org>
>  
>feature]
>- 
>
>Tools that wish to create text directive links of their own find it 
>difficult <https://github.com/WICG/scroll-to-text-fragment/issues/160> 
>since the rules around matching text are rather complicated 
>
> <https://wicg.github.io/scroll-to-text-fragment/#find-a-range-from-a-text-directive>
>  
>(necessarily so). This API allows such tools/pages to give the browser a 
>Range and receive a text directive string in return.
>- Pages that use <https://github.com/ampproject/amphtml/issues/32139> 
>a cross-origin iframe to host content and want to enable text highlighting 
>can coordinate between the embedder and embeddee by passing the text 
>directive string to the embeddee and having it set the text directive on 
>itself. The text directive is currently exposed (accidentally) on the 
>performance API <http://crbug.com/1096983> which pages can to read to 
>achieve this behavior. An explicit API would allow us to remove the 
>performance API hack which may enable more privacy-sensitive features 
>
> <https://github.com/bokand/web-annotations/blob/main/URL-based-annotation.md> 
>to use the fragment directive mechanism.
>
>
>
> Initial public proposal
> https://github.com/WICG/scroll-to-text-fragment/issues/160
>
> Search tagstext <https://chromestatus.com/features#tags:text>, scroll 
> <https://chromestatus.com/features#tags:scroll>, fragment 
> <https://chromestatus.com/features#tags:fragment>, directive 
> <https://chromestatus.com/features#tags:directive>, fragmentDirective 
> <https://chromestatus.com/features#tags:fragmentDirective>, document 
> <https://chromestatus.com/features#tags:document>
>
> TAG reviewTODO: None yet
>
> TAG review statusPending
>
> Risks
>
> No compat risk as this is a new API.
>
> Usual interop risk of other vendors not implementing. Given this is 
> extending a feature other vendors don’t yet implement, there’s some risk 
> here this makes it more difficult to reach interop. We plan to mitigate 
> this with detailed spec text and extensive web-platform tests.
>
> One thing to highlight - the fragment directive (everything after `:~:` in 
> the URL) is stripped from the URL during page load. This is done for 
> compatibility, to ensure that target pages are not confused by the fragment 
> directive. A page can already tell where the user gets scrolled to, and 
> what text is at that location, so explicitly exposing the text directive 
> data in an API doesn’t reveal anything new or sensitive to the page.
>
> Interoperability and Compatibility
>
> TODO
> Gecko: No signal
> WebKit: No signal
> Web developers: No signals
> Other signals:
>
>
> Debuggability
>
> Authors working with text directives today have no v

[blink-dev] Intent to Prototype: document.fragmentDirective API

[David Bokan]

(Note - this is an extension to the already shipped "scroll-to-text"/text
directive feature)
Contact emailsbo...@chromium.org, blink-interactions-t...@google.com

Explainer
https://github.com/WICG/scroll-to-text-fragment/blob/main/fragment-directive-api.md

SpecificationTODO: None yet

SummaryWe propose exposing JavaScript APIs for working programmatically
with text directives (a.k.a. Scroll-to-text highlights)


The new API enables authors to better work with text directives when they
are used to navigate to their page:



   -

   Exposes the previously unavailable text directive (everything in the URL
   fragment after “:~:”) in the URL to page authors via a structured API
   -

   Exposes the DOM Range being highlighting
   -

   Allows programmatically adding and removing text directive highlights


It also enables authors to *create* deep link navigations:


   - Allows the browser to generate a text directive URL from an arbitrary
   DOM Range, making it easier for authors to create deep links to their own
   content.


Blink componentBlink>Scroll


MotivationWe’ve seen a few use cases crop up for working with text
fragments:



   -

   Being able to attach commentary/UI to a targeted text range [received as
   part of Mozilla’s feedback on the core text directive
   

   feature]
   -

   Tools that wish to create text directive links of their own find it
   difficult 
   since the rules around matching text are rather complicated
   

   (necessarily so). This API allows such tools/pages to give the browser a
   Range and receive a text directive string in return.
   - Pages that use  a
   cross-origin iframe to host content and want to enable text highlighting
   can coordinate between the embedder and embeddee by passing the text
   directive string to the embeddee and having it set the text directive on
   itself. The text directive is currently exposed (accidentally) on the
   performance API  which pages can to read to
   achieve this behavior. An explicit API would allow us to remove the
   performance API hack which may enable more privacy-sensitive features
   
   to use the fragment directive mechanism.



Initial public proposal
https://github.com/WICG/scroll-to-text-fragment/issues/160

Search tagstext , scroll
, fragment
, directive
, fragmentDirective
, document


TAG reviewTODO: None yet

TAG review statusPending

Risks

No compat risk as this is a new API.

Usual interop risk of other vendors not implementing. Given this is
extending a feature other vendors don’t yet implement, there’s some risk
here this makes it more difficult to reach interop. We plan to mitigate
this with detailed spec text and extensive web-platform tests.

One thing to highlight - the fragment directive (everything after `:~:` in
the URL) is stripped from the URL during page load. This is done for
compatibility, to ensure that target pages are not confused by the fragment
directive. A page can already tell where the user gets scrolled to, and
what text is at that location, so explicitly exposing the text directive
data in an API doesn’t reveal anything new or sensitive to the page.

Interoperability and Compatibility

TODO
Gecko: No signal
WebKit: No signal
Web developers: No signals
Other signals:


Debuggability

Authors working with text directives today have no visibility into their
inner workings. This API improves the situation and will allow us to
provide some more useful output (e.g. by explaining in an exception why a
TextDirective fails to parse).

Is this feature fully tested by web-platform-tests

?Yes - we’ve added tests to wpt_internal

which can be simply upstreamed when shipping. Will continue to add
extensive tests as the feature develops.

Flag name--enable-blink-features=TextFragmentAPI

Requires code in //chrome?False

Tracking bughttps://crbug.com/1214791

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status
https://chr