Re: [blink-dev] Intent to Experiment: EditContext API

[Nicola Tommasi]

Hi, from a privacy perspective we have some concerns regarding the 
spellchecker section: we enforced in the past the concept that websites 
should not learn about the user dictionaries [1] and it seems like the 
spellcheking API proposal could leak those via the *textformatupdate *event. 
Was this taken into consideration?Do we have any way to prevent this?

[1] https://drafts.csswg.org/css-pseudo-4/#highlight-security

Thanks,
Nicola
On Thursday, June 15, 2023 at 11:31:59 PM UTC dan...@microsoft.com wrote:

> Thanks Alex!
>
>  
>
> It looks like crbug.com/1263817 
>  is a good 
> tracking bug for https://github.com/w3c/uievents/issues/202 (which is 
> already linked from there). Since EditContext differs in how these events 
> will fire I think this issue can be resolved separately, but I’ve tagged 
> some folks in on that issue to try to drive some progress.
>
>  
>
> I’ll investigate what can be done to get the tests moved to WPT.
>
>  
>
> *From:* Alex Russell  
> *Sent:* Wednesday, June 14, 2023 8:32 AM
> *To:* blink-dev 
> *Cc:* Yoav Weiss ; Mike Taylor <
> miketa...@chromium.org>; blin...@chromium.org ; 
> Joshua Bell ; chri...@google.com ; 
> Anupam Snigdha ; Alex Keng ; 
> Daniel Clark ; mt...@google.com 
> *Subject:* Re: [blink-dev] Intent to Experiment: EditContext API
>
>  
>
> LGTM to experiment assuming WPT caveats are addressed.
>
>  
>
> On editing event order, perhaps we can track this separately. Is there a 
> crbug for it?
>
> On Tuesday, June 13, 2023 at 9:02:34 PM UTC-7 Yoav Weiss wrote:
>
> On Wed, Jun 14, 2023 at 12:03 AM 'Daniel Clark' via blink-dev <
> blink-dev@chromium.org> wrote:
>
> *> Although in the template this is phrased as a yes/no question, can you 
> say more about the WPT coverage and limitations?*
>
>  
>
> We currently do not have tests in web-platform-tests. 
>
> There are tests outside the external/wpt folder:
>
> third_party/blink/web_tests/editing/input/edit-context.html 
> 
>
> third_party/blink/web_tests/editing/input/edit-context-dom-mutation.html 
> 
>
>  
>
> I’m going to migrate as much of the contents of these as I can to WPT. 
> This won’t be possible for a lot of the subtests since they rely on 
> primitives like eventSender and textInputController, which aren’t available 
> in WPT.
>
> There is also test coverage that still needs to be written for scenarios 
> involving nested editable elements, and I plan to add these as WPTs.
>
>  
>
> Would it be possible to add WebDriver extensions to enable these tests to 
> move over to WPT?
>
>  
>
> +Mathias Bynens  - FYI
>
>  
>
>  
>
> There’s been some work done 
>  
> around adding support for IME testing but my understanding is that more 
> work is needed in order to use this in WPTs.
>
>  
>
> *From:* Daniel Clark 
> *Sent:* Tuesday, June 13, 2023 10:42 AM
> *To:* Mike Taylor ; blink-dev@chromium.org
> *Cc:* Chris Harrelson ; Anupam Snigdha <
> sni...@microsoft.com>; Alex Keng 
> *Subject:* RE: [blink-dev] Intent to Experiment: EditContext API
>
>  
>
> Tentatively M116 - M120 for the trial.
>
>  
>
> *From:* Mike Taylor  
> *Sent:* Tuesday, June 13, 2023 9:24 AM
> *To:* Daniel Clark ; blink-dev@chromium.org
> *Cc:* Chris Harrelson ; Anupam Snigdha <
> sni...@microsoft.com>; Alex Keng 
> *Subject:* Re: [blink-dev] Intent to Experiment: EditContext API
>
>  
>
> Do you all have a timeline in mind for experimentation?
>
> On 6/12/23 7:00 PM, 'Daniel Clark' via blink-dev wrote:
>
> Contact emails 
>
> sni...@microsoft.com, shih...@microsoft.com, bemat...@microsoft.com, 
> dan...@microsoft.com
>
> Explainer 
>
> https://github.com/w3c/edit-context/blob/gh-pages/explainer.md
>
> Specification 
>
> https://w3c.github.io/edit-context
>
> Design docs 
>
>
> https://github.com/w3c/edit-context/blob/gh-pages/dev-design.md
>
> Summary 
>
> The EditContext API simplifies the process of integrating a web app with 
> advanced text input methods such as VK shape-writing, Handwriting panels, 
> speech recognition, IME Compositions etc., improves accessibility and 
> performance, and unlocks new capabilities for web-based editors.
>
>
>
> Blink component 
>
> Blink>Editing 
> 
>
> Search tags 
>
> editing , contenteditable 
> , input 
> , rawinput 
> , ime 
> 
>
> TAG review 
>
> https://github.com/w3ctag/design-reviews/issues/416
>
> 

[blink-dev] Re: Intent to Ship: timestamp field on RTCEncodedVideoFrameMetadata

[Nicola Tommasi]

I didn't have much background on this topic to be honest and I wanted to 
understand the real usage scenario. Thanks a lot for clarifying this. 

Nicola

On Tuesday, May 9, 2023 at 9:05:36 AM UTC Tony Herre wrote:

> Thanks for the reply - hard to judge how much context to include for small 
> launches like this.
>
> The motivation is in helping WebRTC web applications which are using both 
> Mediacapture 
> Transforms <https://www.w3.org/TR/mediacapture-transform/> to modify raw 
> audio/video (adding video effects, background replace etc) and WebRTC 
> Encoded Transforms <https://www.w3.org/TR/webrtc-encoded-transform/> for 
> modifying the WebRTC encoded data which gets sent on over the network (to 
> do client-side encryption, appending additional application metadata within 
> the media, observing per-frame WebRTC metadata like ContributingSources 
> etc).
> Adding this `timestamp` field to RTCEncodedVideoFrameMetadata means that, 
> when getting an encoded video frame in the encoded transform, the app can 
> now tell which raw video frame in the mediacapture transform was encoded to 
> produce this (or when receiving video, which raw frame is later 
> produced after decoding this encoded frame), by matching 
> RTCEncodedVideoFrameMetadata.timestamp with VideoFrame.timestamp 
> <https://www.w3.org/TR/webcodecs/#videoframe-interface>.
>
> With this, the application can coordinate the two transforms a lot better 
> - eg changing how raw frames are processed or rendered on the exact frame 
> in which webrtc metadata changed, or change details of the encoded data on 
> the exact frame when something in the raw video transform was changed.
>
> As for developer interest, I'm working closely with at least one quick 
> adopter, and the quick agreement in the WebRTC Working Group shows this is 
> generally useful and a part of the roadmap.
>
> Thanks!
>
> On Mon, 8 May 2023 at 16:21, Nicola Tommasi  wrote:
>
>> Hi Tony,
>>
>> Thanks for this intent, could you please clarify why this new field is 
>> needed and important?Without an explainer is hard to follow this change.
>>
>> Cheers,
>> Nicola
>>
>> On Tuesday, May 2, 2023 at 2:29:22 PM UTC Tony Herre wrote:
>>
>>> Contact emails
>>>
>>> he...@google.com, gui...@chromium.com
>>>
>>> Spec
>>> https://w3c.github.io/webrtc-encoded-transform/#RTCEncodedVideoFrameMetadata
>>>  
>>> particularly
>>> PR#173 <https://github.com/w3c/webrtc-encoded-transform/pull/173>.
>>>
>>>
>>> Summary
>>>
>>> Add a 'timestamp' field to RTCEncodedVideoFrameMetadata containing the 
>>> presentation timestamp of the associated encoded video frame.
>>>
>>> Is this feature supported on all six Blink platforms (Windows, Mac, 
>>> Linux, Chrome OS, Android, and Android WebView)?
>>>
>>> Yes
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> Positive response from all members at W3C WebRTC WG April 2023 Interim, 
>>> PR landed with no open issues.
>>>
>>> Ergonomics
>>>
>>> Added specifically to align with the timestamp field on the WebCodecs 
>>> <https://www.w3.org/TR/webcodecs/#encodedvideochunk-interface>
>>> EncodedVideoChunk 
>>> <https://www.w3.org/TR/webcodecs/#encodedvideochunk-interface>, and 
>>> allow matching video frames with the timestamp in the WebCodecs 
>>> VideoFrame <https://www.w3.org/TR/webcodecs/#videoframe-interface> 
>>> object.
>>>
>>> Will also provide the same timestamp already exposed in 
>>> requestVideoFrameCallback's 'mediaTime'.
>>>
>>> Is this feature fully tested by web-platform-tests 
>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>>> ?
>>>
>>> Tested internally by RTCEncodedVideoFrame-capture-timestamp-id.html 
>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/fast/peerconnection/RTCEncodedVideoFrame-capture-timestamp-id.html>,
>>>  
>>> upstreaming to WPT tracked in crbug.com/1441888.
>>>
>>>
>>>
>>> Entry on the feature dashboard
>>>
>>> None, small delta to launched API. 
>>>
>>

-- 
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/9f5fa678-699e-4525-bfbf-e941db8ea1ben%40chromium.org.

[blink-dev] Re: Intent to Ship: timestamp field on RTCEncodedVideoFrameMetadata

[Nicola Tommasi]

Hi Tony,

Thanks for this intent, could you please clarify why this new field is 
needed and important?Without an explainer is hard to follow this change.

Cheers,
Nicola

On Tuesday, May 2, 2023 at 2:29:22 PM UTC Tony Herre wrote:

> Contact emails
>
> he...@google.com, gui...@chromium.com
>
> Spec
> https://w3c.github.io/webrtc-encoded-transform/#RTCEncodedVideoFrameMetadata 
> particularly
> PR#173 .
>
>
> Summary
>
> Add a 'timestamp' field to RTCEncodedVideoFrameMetadata containing the 
> presentation timestamp of the associated encoded video frame.
>
> Is this feature supported on all six Blink platforms (Windows, Mac, Linux, 
> Chrome OS, Android, and Android WebView)?
>
> Yes
>
> Risks
>
> Interoperability and Compatibility
>
> Positive response from all members at W3C WebRTC WG April 2023 Interim, PR 
> landed with no open issues.
>
> Ergonomics
>
> Added specifically to align with the timestamp field on the WebCodecs 
> 
> EncodedVideoChunk 
> , and allow 
> matching video frames with the timestamp in the WebCodecs VideoFrame 
>  object.
>
> Will also provide the same timestamp already exposed in 
> requestVideoFrameCallback's 'mediaTime'.
>
> Is this feature fully tested by web-platform-tests 
> 
> ?
>
> Tested internally by RTCEncodedVideoFrame-capture-timestamp-id.html 
> ,
>  
> upstreaming to WPT tracked in crbug.com/1441888.
>
>
>
> Entry on the feature dashboard
>
> None, small delta to launched API. 
>

-- 
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/cfa25949-7d3d-4dfd-920d-e89eab6933d5n%40chromium.org.

Re: [blink-dev] Intent to deprecate forwarding of mdoc-scheme URLs as Android Intents

[Nicola Tommasi]

Thanks Adam for providing more info. We discussed this topic within the Web 
Platform team yesterday and the feedback was positive. Could you please 
share the deprecation plan as soon as you have more details?

Cheers,
Nicola

On Friday, March 24, 2023 at 4:59:48 PM UTC Adam Langley wrote:

> On Fri, Mar 24, 2023 at 2:45 AM Nicola Tommasi  
> wrote:
>
>> Hi Adam,
>>
>> Thanks for sending this intent. I'm trying to understand a bit more the 
>> proposed deprecation so I have a few questions for you:
>>
>> - Are these URIs already used by other APIs?If so, could you please make 
>> an example?
>>
>
> These URIs are specific to mdoc presentation. They are not a web API, they 
> are a way for sites on Android to use Chromium's ability to trigger Android 
> Intents, not to invoke the site's app, but to open an unrelated wallet app 
> that would then communicate directly with the origin server.
>
> - Do you plan to block these URIs only for the mdoc presentation API?If 
>> the API is not shipped yet, why do we need a deprecation intent?
>>
>
> These schemes aren't part of a web API. We believe that a web API is the 
> better way to expose mdocs on the web and are sending this notice early to 
> inform the ecosystem of our thinking and hopefully make an eventual 
> deprecation less impactful.
>
>
> Cheers
>
> AGL 
>

-- 
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/09e97cbf-6d46-42b9-aeef-8d703393b65cn%40chromium.org.

Re: [blink-dev] Intent to deprecate forwarding of mdoc-scheme URLs as Android Intents

[Nicola Tommasi]

Hi Adam,

Thanks for sending this intent. I'm trying to understand a bit more the 
proposed deprecation so I have a few questions for you:

- Are these URIs already used by other APIs?If so, could you please make an 
example?
- Do you plan to block these URIs only for the mdoc presentation API?If the 
API is not shipped yet, why do we need a deprecation intent?

I'm sorry if the questions may sound trivial, I just wanted to be sure to 
get the full context around this topic.

Cheers,
Nicola

On Tuesday, March 21, 2023 at 2:45:50 PM UTC Adam Langley wrote:

> On Tue, Mar 21, 2023 at 4:25 AM Yoav Weiss  wrote:
>
>> Thanks for sending this intent! :)
>>
>> It seems like you didn't use the chromestatus.com template, so a few 
>> things are missing:
>> * The title is non-standard and hence didn't get caught in our tooling
>> * What's the timeline for which you want to deprecate the use of these 
>> URI schemes? When will they be removed?
>> * A short explainer outlining what will be deprecated and removed and how 
>> developers should deal with that
>>
>
> At this point we are collecting feedback and metrics on this deprecation 
> and a more standard and concrete plan will follow from that. This is not 
> the usual way around, but we hope that by communicating earlier any impact 
> will be reduced.
>
>
> Cheers
>
> AGL
>

-- 
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/86d2b49b-7110-4c0f-82e9-bef3a453809cn%40chromium.org.

Re: [blink-dev] Re: Intent to Experiment: Shared Element Transitions

[Nicola Tommasi]

Thanks for the info Hannah, I don't need more details at this stage.

Nicola

On Monday, June 13, 2022 at 5:26:52 PM UTC Joe Medley wrote:

> Is the experiment 103 to 106 or 104 to 107.
> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com | 
> 816-678-7195 <(816)%20678-7195>
> *If an API's not documented it doesn't exist.*
>
>
> On Mon, Jun 13, 2022 at 8:49 AM 'Hannah Van Opstal' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Hi Nicola, 
>>
>> This experimentation is still for the same-origin case. 
>> The difference is in the shape of the API. The first intent was approved 
>> for the API when it was using Viz. With Viz Shared Element Transitions, we 
>> did an origin trial where we received some feedback that led us to change 
>> it to use the renderer. So this new intent would be intended for the newer 
>> shape - i.e. renderer SET. 
>>
>> Please let me know if we can provide any more details.
>>
>> Hannah 
>>
>>
>>
>>
>>
>> On Mon, Jun 13, 2022 at 7:16 AM Nicola Tommasi  
>> wrote:
>>
>>> Hi API owners,
>>>
>>> This intent seems to be already approved in the past for same-origin 
>>> experimentation, is this launch intended for the cross-origin case?If not, 
>>> what's exactly in the scope for this particular launch?
>>>
>>> Thanks,
>>> Nicola
>>>
>>> On Thursday, June 9, 2022 at 8:35:23 AM UTC Yoav Weiss wrote:
>>>
>>>> LGTM to experiment M103-M106
>>>>
>>>> Thanks for working on this! I'm super excited about the possibilities 
>>>> this will open!!
>>>>
>>>> On Wed, Jun 8, 2022 at 9:27 PM Khushal Sagar  
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Jun 8, 2022 at 3:11 PM Khushal Sagar <
>>>>> khushalsa...@chromium.org> wrote:
>>>>>
>>>>>> Contact emailskhushalsa...@chromium.org, vmp...@chromium.org, 
>>>>>> hvanops...@chromium.org
>>>>>>
>>>>>> Explainer
>>>>>> https://github.com/WICG/shared-element-transitions/blob/main/explainer.md
>>>>>>
>>>>>> Specification
>>>>>> https://tabatkins.github.io/specs/css-shared-element-transitions
>>>>>>
>>>>>> Design docs
>>>>>>
>>>>>> https://github.com/WICG/shared-element-transitions/blob/main/explainer.md
>>>>>>
>>>>>> Summary
>>>>>>
>>>>>> Shared Element Transitions is a proposal for a new script API that 
>>>>>> allows a simple set of transitions in both Single-Page Applications 
>>>>>> (SPAs) 
>>>>>> and Multi-Page Applications (MPAs). This feature enhances the visual 
>>>>>> polish 
>>>>>> of pages without requiring a large development effort from developers to 
>>>>>> make transitions look nice. By selecting from a set of user-agent 
>>>>>> implemented transition effects, the developers can achieve a polished 
>>>>>> transition look with minimal effort.
>>>>>>
>>>>>>
>>>>>> Blink componentBlink>Animation 
>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EAnimation>
>>>>>>
>>>>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/631
>>>>>>
>>>>>> TAG review statusPending
>>>>>>
>>>>>> Link to origin trial feedback summary
>>>>>> https://docs.google.com/spreadsheets/d/1x7IueF5_Ds7oyihAV1DB3yzR4f-SbPcKc5DMvBzg-nM/edit#gid=2085648173
>>>>>>
>>>>>> Risks
>>>>>>
>>>>>> Interoperability and Compatibility
>>>>>>
>>>>>> Low. As a new feature, the risk here is that other browsers do not 
>>>>>> implement it, but since this is a progressive enhancement, sites should 
>>>>>> be 
>>>>>> able to drop usage of the feature easily in browsers where it is not 
>>>>>> supported.
>>>>>>
>>>>>> *Gecko*: No signal
>>>>>>
>>>>>> *WebKit*: No signal
>>>>>>
>>>>>> *Web developers*: Strongly positive
>>>>>> Interest and developer experiment

Re: [blink-dev] Re: Intent to Experiment: Shared Element Transitions

[Nicola Tommasi]

Hi API owners,

This intent seems to be already approved in the past for same-origin 
experimentation, is this launch intended for the cross-origin case?If not, 
what's exactly in the scope for this particular launch?

Thanks,
Nicola

On Thursday, June 9, 2022 at 8:35:23 AM UTC Yoav Weiss wrote:

> LGTM to experiment M103-M106
>
> Thanks for working on this! I'm super excited about the possibilities this 
> will open!!
>
> On Wed, Jun 8, 2022 at 9:27 PM Khushal Sagar  
> wrote:
>
>>
>>
>> On Wed, Jun 8, 2022 at 3:11 PM Khushal Sagar  
>> wrote:
>>
>>> Contact emailskhushalsa...@chromium.org, vmp...@chromium.org, 
>>> hvanops...@chromium.org
>>>
>>> Explainer
>>> https://github.com/WICG/shared-element-transitions/blob/main/explainer.md
>>>
>>> Specification
>>> https://tabatkins.github.io/specs/css-shared-element-transitions
>>>
>>> Design docs
>>> https://github.com/WICG/shared-element-transitions/blob/main/explainer.md
>>>
>>> Summary
>>>
>>> Shared Element Transitions is a proposal for a new script API that 
>>> allows a simple set of transitions in both Single-Page Applications (SPAs) 
>>> and Multi-Page Applications (MPAs). This feature enhances the visual polish 
>>> of pages without requiring a large development effort from developers to 
>>> make transitions look nice. By selecting from a set of user-agent 
>>> implemented transition effects, the developers can achieve a polished 
>>> transition look with minimal effort.
>>>
>>>
>>> Blink componentBlink>Animation 
>>> 
>>>
>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/631
>>>
>>> TAG review statusPending
>>>
>>> Link to origin trial feedback summary
>>> https://docs.google.com/spreadsheets/d/1x7IueF5_Ds7oyihAV1DB3yzR4f-SbPcKc5DMvBzg-nM/edit#gid=2085648173
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> Low. As a new feature, the risk here is that other browsers do not 
>>> implement it, but since this is a progressive enhancement, sites should be 
>>> able to drop usage of the feature easily in browsers where it is not 
>>> supported.
>>>
>>> *Gecko*: No signal
>>>
>>> *WebKit*: No signal
>>>
>>> *Web developers*: Strongly positive
>>> Interest and developer experiments with the API:
>>>
>>> https://twitter.com/jaffathecake/status/1524782819431555074?t=itU6B0wo6SbjomGiSKLmGQ&s=19
>>>
>>> https://www.reddit.com/r/webdev/comments/uyoit1/i_played_around_with_chromes_new_shared_element/
>>>
>>> https://twitter.com/OliverJAsh/status/1530261401016705026?t=CXqW2yiIMbH6bLfn8ImINw&s=19
>>>
>>> https://css-tricks.com/spas-shared-element-transitions-and-re-evaluating-technology/
>>>
>>> *Other signals*:
>>>
>>> Ergonomics
>>>
>>> None.
>>>
>>> Activation
>>>
>>> Low. As with interop/compat risks, the difficulty stems from this being 
>>> a new feature without support in other browsers. A polyfill for the SPA 
>>> case would be beneficial, but it will not be possible to polyfill MPA 
>>> behavior. That said, dropping the customized transition should not impact 
>>> the usability of a site, fundamentally, so this can easily be dropped on 
>>> browsers that do not support the feature. 
>>>
>>> Security
>>>
>>> The primary security constraint is ensuring isolation of graphics 
>>> resources from multiple origins. The design achieves that using Chromium's 
>>> Viz process similar to OOPIFs.
>>>
>>> See also the security and privacy self-review questionnaire that was 
>>> completed as part of the TAG review process: 
>>> https://github.com/WICG/shared-element-transitions/blob/main/security-privacy-questionnaire.md
>>>
>>> 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?
>>>
>>>
>>>
>>> Goals for experimentation
>>>
>>> Learning from the feedback from the previous OT, the API has been 
>>> updated to layer on top existing animation systems on the platform. This 
>>> allows the browser to provide a set of default transitions which developers 
>>> can extensively customize. We want to learn that developers can easily 
>>> adopt this API and build the desired UX using the customization options 
>>> provided.
>>>
>>> Reason this experiment is being extended
>>> Ongoing technical constraints
>>>
>>> None.
>>>
>>> Debuggability
>>>
>>> The feature can be debugged using standard tooling in devtools. 
>>> Specifically the animation panel can be used to pause and scrub through the 
>>> default animations set by the browser. The pseudo DOM structure generated 
>>> by the UA can also be inspected and targeted, like other DOM elements, in 
>>> the style panel.
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>>> Linux, Chrome OS, Android, and Android WebView)?No
>>>
>>> Currently no support for Android WebView. This is WIP.
>>>
>>> Is this feature fully tested by web-platform-tests 
>>>