Re: [webkit-dev] wpt survey

[Maciej Stachowiak]

Hello WebKit folks,

You may be interested in this survey about Web Platform Tests.

> -- Forwarded message --
> From: Simon Pieters mailto:si...@bocoup.com>>
> Date: Tue, Jun 19, 2018 at 10:21 AM
> Subject: Re: wpt survey
> To: Jory Burson mailto:j...@bocoup.com>>
> Cc: Philip Jägenstedt mailto:foo...@google.com>>, James 
> Graham mailto:ja...@hoppipolla.co.uk>>
> 
> 
> OK, 
> http://lists.w3.org/Archives/Public/public-test-infra/2018AprJun/0015.html 
> 
> 
> -- 
> Simon Pieters
> Bocoup https://bocoup.com/ 

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

Re: [webkit-dev] Experimental features enabled by default

[Michael Catanzaro]

On Wed, Jun 20, 2018 at 6:05 PM, Tim Horton  wrote:

It’s definitely not OK, no.


Well, we should make sure the right choice is made for each individual 
feature, but I don't know what those right choices are... hence the 
motivation for my mail.


I think we have some sorting out of this to do, I think it would be 
appreciated if you could hold off for a little bit. Sorry for the 
mess!


OK, I didn't know you were already discussing this. I'll hold off, then.

Michael

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

Re: [webkit-dev] Experimental features enabled by default

[Tim Horton]

Resending from the right address.

> On Jun 20, 2018, at 11:12 AM, Michael Catanzaro  wrote:
> 
> Hi,

Apple folks have been chatting about this elsewhere, so it’s a humorous 
coincidence to see this here at the same time.

> I noticed in glancing over WebPreferences.yaml that we have a large number of 
> experimental features enabled by default. There is a comment header 
> indicating that the only allowed values are false or 
> DEFAULT_EXPERIMENTAL_FEATURES_ENABLED, so true is disallowed, but that's 
> being ignored in many cases. It's become a bit difficult to notice the 
> comment header because the experimental feature list has grown quite large in 
> the past year or two.
> 
> Background: DEFAULT_EXPERIMENTAL_FEATURES_ENABLED is enabled by default in 
> the XCode build (because Apple disables experimental features on branches, 
> not trunk), disabled by default in the CMake build (to prevent experimental 
> features from sneaking into GTK and WPE releases), and finally enabled by 
> build-webkit (so experimental features are always enabled for bots and 
> developers).
> 
> I'm planning to change the default values of the following features from true 
> (not allowed for experimental features) to 
> DEFAULT_EXPERIMENTAL_FEATURES_ENABLED:
> 
> CacheAPIEnabled
> ConstantPropertiesEnabled
> CrossOriginWindowPolicySupportEnabled
> IsSecureContextAttributeEnabled
> StorageAccessAPIEnabled
> SubresourceIntegrityEnabled
> RestrictedHTTPResponseAccess
> CrossOriginResourcePolicyEnabled
> StorageAccessPromptsEnabled
> 
> But I wonder if this is OK for all of the above features, as no doubt the 
> intention behind using true was to make the feature always enabled.

It’s definitely not OK, no.

I think we have some sorting out of this to do, I think it would be appreciated 
if you could hold off for a little bit. Sorry for the mess!

> So if any of the above features are no longer experimental and should be 
> enabled by default on all ports, please speak up so they can be graduated out 
> of the experimental features category. My recommended sanity-check is that if 
> the feature is ready for all Safari users and not just Tech Preview users, 
> then it's probably no longer experimental.
> 
> A couple more oddities:
> 
> I'll mark CSSAnimationTriggersEnabled as experimental, since it uses 
> DEFAULT_EXPERIMENTAL_FEATURES_ENABLED and is clearly intended to be.
> 
> For DisabledAdaptationsMetaTagEnabled, I'm not sure. We could change the 
> default value from DISABLED_ADAPTATIONS_META_TAG_ENABLED to 
> DEFAULT_EXPERIMENTAL_FEATURES_ENABLED, and add a PLATFORM(WATCHOS) condition. 
> I think this should be OK for watchOS. Alternatively, I wonder if it might be 
> better to consider it non-experimental and simply set the default to true 
> (with a PLATFORM(WATCHOS) condition)?
> 
> Michael
> 
> ___
> 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

[webkit-dev] Experimental features enabled by default

[Michael Catanzaro]

Hi,

I noticed in glancing over WebPreferences.yaml that we have a large 
number of experimental features enabled by default. There is a comment 
header indicating that the only allowed values are false or 
DEFAULT_EXPERIMENTAL_FEATURES_ENABLED, so true is disallowed, but 
that's being ignored in many cases. It's become a bit difficult to 
notice the comment header because the experimental feature list has 
grown quite large in the past year or two.


Background: DEFAULT_EXPERIMENTAL_FEATURES_ENABLED is enabled by default 
in the XCode build (because Apple disables experimental features on 
branches, not trunk), disabled by default in the CMake build (to 
prevent experimental features from sneaking into GTK and WPE releases), 
and finally enabled by build-webkit (so experimental features are 
always enabled for bots and developers).


I'm planning to change the default values of the following features 
from true (not allowed for experimental features) to 
DEFAULT_EXPERIMENTAL_FEATURES_ENABLED:


CacheAPIEnabled
ConstantPropertiesEnabled
CrossOriginWindowPolicySupportEnabled
IsSecureContextAttributeEnabled
StorageAccessAPIEnabled
SubresourceIntegrityEnabled
RestrictedHTTPResponseAccess
CrossOriginResourcePolicyEnabled
StorageAccessPromptsEnabled

But I wonder if this is OK for all of the above features, as no doubt 
the intention behind using true was to make the feature always enabled. 
So if any of the above features are no longer experimental and should 
be enabled by default on all ports, please speak up so they can be 
graduated out of the experimental features category. My recommended 
sanity-check is that if the feature is ready for all Safari users and 
not just Tech Preview users, then it's probably no longer experimental.


A couple more oddities:

I'll mark CSSAnimationTriggersEnabled as experimental, since it uses 
DEFAULT_EXPERIMENTAL_FEATURES_ENABLED and is clearly intended to be.


For DisabledAdaptationsMetaTagEnabled, I'm not sure. We could change 
the default value from DISABLED_ADAPTATIONS_META_TAG_ENABLED to 
DEFAULT_EXPERIMENTAL_FEATURES_ENABLED, and add a PLATFORM(WATCHOS) 
condition. I think this should be OK for watchOS. Alternatively, I 
wonder if it might be better to consider it non-experimental and simply 
set the default to true (with a PLATFORM(WATCHOS) condition)?


Michael

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

Re: [webkit-dev] Design for review: EWS for security bugs

[Alexey Proskuryakov]

> 16 июня 2018 г., в 0:12, Daniel Bates  написал(а):
> 
> Hi all,
> 
> I am working to support EWS processing of patches on security bugs (see 
>  >) and I am writing to this 
> list to solicit feedback on any show-stopper bugs in the proposed design. 
> Historically we have not supported this functionality because the EWS was 
> designed to use Bugzilla as its data store and hence the EWS machines 
> (considered untrusted) would need a Bugzilla account with access to all 
> security bugs. Here is my idea to solve this problem without privileging 
> these machines with full security bug access:
> 
> Have webkit-queues.webkit.org  host copies 
> of security sensitive patches. These patches will be deleted once all EWS 
> queues have processed them. Access to these patches will be guarded by an API 
> key(s) to prevent anonymous access. Each EWS machine will need one. 
> Otherwise, it will skip such patches.
> The tool webkit-patch will now upload a copy of each patch attached to a 
> security bug to webkit-queues.webkit.org  
> as part of submitting a patch to EWS.
> Add a Bugzilla extension to CC the EWS feeder queue on a bug if it has a 
> patch up for review, including security bugs. (The EWS feeder queue is 
> responsible for polling Bugzilla to find unreviewed patches and submitting 
> them to webkit-queues.webkit.org ).
> The EWS feeder queue will now upload a copy of each patch attached to a 
> security bug to webkit-queues.webkit.org  
> as part of submitting a patch to EWS.
> 
> Then EWS machines will be able to process security sensitive patches, report 
> compile-time errors and the list of failing tests. There are three known 
> issues with this approach: 1) EWS bots cannot comment on security bugs 2) EWS 
> bots cannot upload layout test failure tarballs to security bugs and 3) the 
> "Submit for EWS analysis" button will not work. I plan to solve these issues 
> in subsequent bugs. One way to solve the first two issues is to have 
> webkit-queues.webkit.org  store comments 
> and tarballs and teach the EWS feeder queue (or another bot) to submit these 
> comments and upload these tarballs to Bugzilla on behalf of the EWS bots 
> (since the EWS feeder queue has access to the security bug by design decision 
> (3)). To solve the last issue without requiring a person to re-enter their 
> Bugzilla credentials there are at least three approaches: 1) set an 
> appropriate CORS policy for webkit-queues.webkit.org 
>  to access Bugzilla 2) 
> webkit-queues.webkit.org  asks Bugzilla to 
> POST a form back to it or 3) re-implement and host the "Submit for EWS 
> analysis" button on Bugzilla so that it can upload the security sensitive 
> patch to EWS when clicked then redirect to the status-bubbles page on 
> webkit-queues.webkit.org .

I just have a comment about the known issues. Not sure if it makes sense to 
invest effort into addressing these within current design, as we want to stop 
using custom EWS code and move as much as possible to Buildbot.

The stack that EWS is currently built on is very different from anything else 
we use, so it's difficult to maintain.

- Alexey

> I am open to suggestions.
> 
> Dan
> ___
> 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