Re: [webkit-dev] Requesting a position on Document Policy

[Ryosuke Niwa]

Sorry for the late reply. We're going to review this feature.

- R. Niwa

On Tue, Jul 28, 2020 at 7:02 AM Ian Clelland  wrote:
>
> Hi WebKit!
>
> I'm building out the infrastructure in Blink for Document Policy, and would 
> like to ship at least part of it in Chrome for developers to take advantage 
> of. I'd like to get an official position from WebKit leads on this. I'm also 
> interested in getting thoughts from other WebKit folks about the design or 
> implementation.
>
> Some details:
>
> Document Policy explainer: 
> https://github.com/w3c/webappsec-permissions-policy/blob/master/document-policy-explainer.md
> Document Policy spec: 
> https://w3c.github.io/webappsec-permissions-policy/document-policy.html
> GitHub Repository (shared with Permissions Policy (previously Feature 
> Policy)): https://github.com/w3c/webappsec-permissions-policy
> Blink intent-to-ship discussion: 
> https://groups.google.com/a/chromium.org/g/blink-dev/c/Za159T1QOek/m/lewQUFlBCQAJ
> Also previously discussed at the TAG: 
> https://github.com/w3ctag/design-reviews/issues/408
>
> I think that the last time I brought this to WebKit engineers would have been 
> at TPAC last year, where it was discussed in the WebAppSec meetings as a way 
> to provide a general configuration mechanism for documents, splitting off of 
> ideas that had been floating around at the time for Feature Policy.
>
> While Document Policy itself doesn't prescribe any actual features, it could 
> eventually be used to configure the behaviour of different web-platform 
> features, such as:
> - Restricting the use of poorly-performing images
> - Disabling slow synchronous JS APIs
> - Configuring frame, image, or script loading styles
> - Restricting overall document sizes or network usage
> - Restricting patterns which cause page re-layout
>
> The initial intent, though, is to ship part of this in Chrome to support an 
> opt-out for the Scroll-to-text-fragment feature.
>
> Document Policy has two different mechanisms which can work in conjunction 
> with each other: The first is the Document-Policy (and 
> Document-Policy-Report-Only) HTTP header, which just sets the policy on the 
> document it ships with. The other is a negotiation mechanism between an 
> embedder and its embedded content, which uses an Iframe attribute and an 
> additional request header.
>
> I'm currently interested in shipping just the first of these mechanisms in 
> Chrome. The second may warrant more discussion and review, and isn't needed 
> for the Scroll-to-text-fragment opt-out. The details are in the Chrome 
> Platform Status entry: https://www.chromestatus.com/feature/5756689661820928
>
> Feel free to ask any questions; I'm happy to discuss this in whatever forum 
> works best for folks,
>
> Thanks!
> Ian
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for Position on Native File System API

[Ryosuke Niwa]

On Mon, Aug 17, 2020 at 10:38 AM Marijn Kruisselbrink  wrote:
>
> We would like to get an official position from webkit for the Native File 
> System API (spec, explainer), a API that enables developers to build powerful 
> web apps that interact with files on the user’s local device. It builds on 
> File API for file reading capabilities, and adds new API surface to enable 
> modifying files, as well as working with directories. Chrome has implemented 
> what is currently in the spec, and is planning to ship that soon.
>

Apple's WebKit team does not support this feature due to the security
/ safety concerns.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Status of custom paint?

[Ryosuke Niwa]

Our intern worked on the feature but I don't think anyone is actively
maintaining or developing the feature at the moment.

I don't think it's accurate to say it's mostly implemented. We got the
basics working but there is quite a bit of work left to get to a
feature complete / shippable state.

- R. Niwa

On Tue, Aug 25, 2020 at 2:58 PM Chris Harrelson  wrote:
>
> (re-sending as chris...@chromium.org, which is actually on the webkit list)
>
> On Tue, Aug 25, 2020 at 1:36 PM Chris Harrelson  wrote:
>>
>> Hi WebKit friends,
>>
>> I'm wondering about the status of the implementation of the CSS Painting API 
>> (a.k.a. Custom Paint). I think this is the tracking bug?
>>
>> My understanding is that it's mostly implemented, and the current 
>> implementation is available in Tech Preview. Is it still being worked on?
>>
>> Thanks,
>> Chris
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Status of custom paint?

[Chris Harrelson]

(re-sending as chris...@chromium.org, which is actually on the webkit list)

On Tue, Aug 25, 2020 at 1:36 PM Chris Harrelson  wrote:

> Hi WebKit friends,
>
> I'm wondering about the status of the implementation of the CSS Painting
> API 
> (a.k.a. Custom Paint). I think this
>  is the tracking bug?
>
> My understanding is that it's mostly implemented, and the current
> implementation is available in Tech Preview. Is it still being worked on?
>
> Thanks,
> Chris
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] EWS now sends email notifications for failures

[Aakash Jain]

Hi Everyone,

I am happy to announce another EWS feature: email notifications.

>From now on, whenever EWS detects any build or test failure caused by a patch, 
>it will send email notification to the patch author. In case of build failure, 
>email will contain the relevant error lines, so as to help in quickly 
>identifying the issue. In case of test failure, email will contain the list of 
>failing test, along with the link to test history.

In case someone prefers not to receive these emails, they can unsubscribe 
either by emailing me or adding their email id to EMAIL_IDS_TO_UNSUBSCRIBE in 
Tools/BuildSlaveSupport/ews-build/emails.json

These email notifications are added as per the feedback received in a survey we 
did earlier (in 
https://lists.webkit.org/pipermail/webkit-dev/2019-December/030980.html). Some 
more details in: https://bugs.webkit.org/show_bug.cgi?id=215220#c0

Please let me know if you notice any issue or have any feedback.

Thanks
Aakash
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev