Re: [webkit-dev] Raw string literals

[Maciej Stachowiak via webkit-dev]

> On Nov 17, 2021, at 2:58 PM, Alex Christensen via webkit-dev 
>  wrote:
> 
> Right now, our style checker disapproves of raw string literals, which were 
> introduced in C++11.  It complains with this message:
> 
> Multi-line string ("...") found.  This lint script doesn't do well with such 
> strings, and may give bogus warnings.  They're ugly and unnecessary, and you 
> should use concatenation instead".
> 
> https://webkit.org/code-style-guidelines/ 
>  says nothing on the subject.  I 
> find them quite useful and nice, especially with strings that contain lots of 
> quotation marks that would otherwise need escaping.  Would anyone oppose to 
> my changing our style checker to allow them if I ever get around to it?

Seems like the style checker complains in part because it doesn’t know how to 
properly parse such strings. With that fixed it seems ok to me to use that type 
of string.

 - Maciej

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

Re: [webkit-dev] Request for position: New Canvas 2D API

[Maciej Stachowiak via webkit-dev]

> On May 3, 2021, at 9:58 AM, Simon Fraser via webkit-dev 
>  wrote:
> 
> 
>> On May 1, 2021, at 10:07 AM, Aaron Krajeski via webkit-dev 
>> mailto:webkit-dev@lists.webkit.org>> wrote:
>> 
>> Hi webkit-dev,
>> 
>> This is a request for WebKit's position on New Canvas 2D API 
>>  features. 
>> 
>> Explainer/Chrome Dev Summit Video
>> https://github.com/fserb/canvas2d 
>> https://youtu.be/dfOKFSDG7IM 
>> 
>> Summary
>> Updated functionality for the Canvas2D API. Adds nine new features/functions 
>> to CanvasRenderingContext2D:
>>   - "ContextLost" and "ContextRestored" events
> 
> Seems reasonable.
> 
>>   - "willReadFrequently" option for canvases where lots of readback is 
>> expected
> 
> Seems reasonable.
> 
>>   - CSSColorValues as style inputs
> 
> Seems reasonable (gated on Typed OM support).
> 
>>   - More CSS text modifier support
> 
> WebKit has already expressed support for the proposal.
> 
>>   - A reset function
> 
> We'e already expressed some concerns in the issue.
> 
>>   - A roundRect draw primitive
> 
> Seems reasonable.
> 
>>   - Full 4x4 transformation matrices
> 
> WebKit's architecture on macOS/iOS currently has no way to render these, so 
> we don't support this proposal at this time.
> 
>>   - Conic gradients
> 
> Seems reasonable.
> 
>>   - Better support for SVG filters
> 
> Seems reasonable, although this would have performance implications in our 
> current architecture.

^ On this one I’ll add, it would be better if this could reuse the existing CSS 
or SVG ways of describing a filter instead of adding a novel way. In addition, 
the filter syntax here is strictly less expressive than SVG filters; it appears 
to only support a linear filter chain, rather than a filter graph like SVG does.

> 
> Simon
> 
>> 
>> Contact emails
>> aaro...@chromium.org , fs...@chromium.org 
>> 
>> 
>> Spec and tests
>>   - WHATWG spec in progress:
>>  Text Modifiers 
>>  Filters 
>>  Perspective Transforms 
>>  reset() 
>>  CSSColorValue 
>>  willReadFrequently 
>>  RoundRect 
>>  ConicGradient 
>>  Context Loss 
>>   - MDN spec 
>>  Conic gradient 
>> 
>>  Text Modifiers 
>>  (via 
>> ChromeLabs/puppy-content)
>>   - Web platform tests
>>  RoundRect
>> 
>>  reset() 
>> 
>>  Perspective Transforms 
>> 
>>  Context Loss 
>> 
>>  (this is not testable on WPT)
>>  Filters 
>> 
>>  CSSColorValue Input 
>> 
>>  WillReadFrequently 
>> 
>>  (testable in WPT, work in progress to add tests there)
>>  Conic Gradient 
>> 
>>  Text Modifiers 
>> 
>>   - Chrome Status 
>> 
>> Look forward to hearing your feedback!
>> 
>> Cheers!
>>   Aaron
>> ___
>> 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 mailing list
webkit-dev@lists.webkit.org

Re: [webkit-dev] Request for Position on Storage Foundation API

[Maciej Stachowiak via webkit-dev]

We are not opposed to the concept of efficient access to files, but we are 
strongly opposed to minting a brand new Web API for file access instead of 
enhancing one of the existing ones.

This issue outlines the problem: 
https://github.com/fivedots/storage-foundation-api-explainer/issues/4 

A similar issue was filed by Domenic Denicola from the Chrome team: 
https://github.com/fivedots/storage-foundation-api-explainer/issues/8 


We strongly urge Chrome not to move forward with this API until the above 
issues are addressed in a satisfactory manner.

Regards,
Maciej

> On Feb 5, 2021, at 9:15 AM, Emanuel Krivoy via webkit-dev 
>  wrote:
> 
> (Resending with correct subject for findability and to add further context. 
> Sorry for the spam.)
> 
> Hello webkit-dev,
> 
> We would like to get an official position from WebKit on the Storage 
> Foundation API (https://github.com/fivedots/storage-foundation-api-explainer 
> ), a storage 
> API that resembles a very basic filesystem, with direct access to stored data 
> through buffers and offsets. Our goal is to give developers flexibility by 
> providing generic, simple, and performant primitives upon which they can 
> build higher-level components. It's particularly well suited for Wasm-based 
> libraries and applications that want to use custom storage algorithms to 
> fine-tune execution speed and memory usage.
> 
> The API is currently available behind a flag in Google Chrome. We've received 
> feedback before in #4 
> (https://github.com/fivedots/storage-foundation-api-explainer/issues/4 
> ), 
> asking to clarify our relationship to other storage APIs. We are still 
> working on gathering all the required data to resolve the issues raised 
> there, we intend to update it as soon as we can.
> 
> Thank you,
> Emanuel Krivoy
> ___
> 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] Starting January 4, 2021, Google will block all sign-ins to Google accounts from embedded browser frameworks

[Maciej Stachowiak via webkit-dev]

This sounds obnoxious and potentially anti-competitive. But I think it’s 
restricted to OAuth flows, which would indeed only affect other sites that 
allow the user to sign in with their Google account. So that would be the thing 
to test.

> On Nov 17, 2020, at 12:20 PM, Michael Catanzaro via webkit-dev 
>  wrote:
> 
> On Tue, Nov 17, 2020 at 12:50 pm, Michael Catanzaro  
> wrote:
>> Oh, I missed a very important point. There is a header we can use to test: 
>> Google-Accounts-Check-OAuth-Login:true. I will try to figure out how to hack 
>> up the libsoup backend to send that header with all requests and see what 
>> happens
> 
> I tested this hack:
> 
> diff --git a/Source/WebCore/platform/network/HTTPHeaderNames.in 
> b/Source/WebCore/platform/network/HTTPHeaderNames.in
> index cbc470412f9f..eb19ab00a054 100644
> --- a/Source/WebCore/platform/network/HTTPHeaderNames.in
> +++ b/Source/WebCore/platform/network/HTTPHeaderNames.in
> @@ -109,3 +109,5 @@ X-Temp-Tablet
> // These headers are specific to GStreamer.
> Icy-MetaInt
> Icy-Metadata
> +
> +Google-Accounts-Check-OAuth-Login
> diff --git a/Source/WebCore/platform/network/ResourceRequestBase.h 
> b/Source/WebCore/platform/network/ResourceRequestBase.h
> index 6c9ce5cccefe..db234c37271f 100644
> --- a/Source/WebCore/platform/network/ResourceRequestBase.h
> +++ b/Source/WebCore/platform/network/ResourceRequestBase.h
> @@ -206,6 +206,7 @@ protected:
>, m_hiddenFromInspector(false)
>, m_isTopSite(false)
>{
> + addHTTPHeaderField(HTTPHeaderName::GoogleAccountsCheckOAuthLogin, "true");
>}
> 
>ResourceRequestBase(const URL& url, ResourceRequestCachePolicy policy)
> @@ -221,6 +222,7 @@ protected:
>, m_hiddenFromInspector(false)
>, m_isTopSite(false)
>{
> + addHTTPHeaderField(HTTPHeaderName::GoogleAccountsCheckOAuthLogin, "true");
>}
> 
>void updatePlatformRequest(HTTPBodyUpdatePolicy = 
> HTTPBodyUpdatePolicy::DoNotUpdateHTTPBody) const;
> 
> 
> And confirmed in the web inspector to ensure the header is really sent. Login 
> still works. So... maybe we will be OK? I'm not sure. I tested direct login 
> via google.com. I'm confused as to how this change is in any way related to 
> OAuth. Maybe it will only break for third-party websites that allow logging 
> in with a Google account? I guess we'll find out
> 
> 
> ___
> 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] Reducing / removing use of Makefile based DerivedSources.make

[Maciej Stachowiak via webkit-dev]

> On Oct 17, 2020, at 10:00 AM, Sam Weinig  wrote:
> 
> Hi webkit-dev,
> 
> I’d like to propose, and gauge feedback on, reducing (with the goal of 
> ultimately removing) the use of Makefile based DerivedSources.make.
> 
> My understanding is that currently only the Xcode based ports still use 
> DerivedSources.make, as all the CMake based ones have moved derived source 
> generation to within CMake, so that should limit the scope of who this might 
> affect.
> 
> 
> Why do we use Makefiles today?
> 
> While I can’t recall the initial reasons for using Makefiles for derived 
> sources, over the years there have been a number of advantages to it that I 
> do know of. One clear advantage, that is no longer applicable, was code 
> sharing, as earlier in the project, at least the Apple Windows port did 
> utilize these Makefiles. Another was to work around some limitations in what 
> dependencies Xcode was able to track with build rules. It seems at least some 
> of the problems with build rules are no longer an issue, as we can now 
> specify inputs to build rules, but I don’t if other problems will still be 
> there, but for some prototyping I did, nothing yet has come up.

I think I might be responsible for this, and I think the reason was that at the 
time, Xcode could not properly handle derived source dependencies, and ended up 
either gratuitously rebuilding, or miscomputing by failing to regenerate a 
source, or failing to rebuild it when needed. It’s possible, maybe even likely 
Xcode handling of derived sources has improved since then. But the last attempt 
to do this via Xcode caused subtle broken build issues and/ir gratuitous 
rebuilding, so we’d have to validate that it doesn’t have these problems any 
more.

DerivedSources.make is also more human-editable without having to do so via the 
Xcode GUI.


> 
> 
> What would we move to?
> 
> As this only affects the Xcode based ports, we would move to distinct script 
> phases and build rules in the Xcode project.  
> 
> 
> Why make this change? What’s the benefit?
> 
> There are few reasons to consider this. One advantage is simplifying the 
> build system. Rather than two dependency systems (one for Xcode, one for the 
> Makefile) we reduce it down to one. And with additional knowledge of the 
> stages and dependencies, Xcode could potentially parallelize more phases. We 
> would would also save some time by avoiding invoking make in the first place. 
> 
> We also have a bit of an issue with make itself, as due to system 
> requirements, we are forever stuck with Make 3.81, which is coming up on 
> being 15 years old. More than once in the last year I have tried to 
> troubleshoot makefile issues, looking for resources on the web, only to be 
> stymied because the solutions I found required newer make.

One question in my mind is whether this would potentially lead to faster 
builds. If so, and the reliability problems from older Xcode’s are gone, then 
this would probably be a worthwhile change. But see below...

> 
> 
> What are the downsides?
> 
> One potential downside will be that it will be a bit harder for those without 
> Xcode to add new types of derived sources. I am not sure how much a real 
> problem in practice this will be, as editing project.pbxproj files is already 
> required for just adding new files, but I want to call it out anyway.
> 
> 
> What are your thoughts on this? Are there additional reasons we might want to 
> stick with or move away from Makefile based derived sources?

One additional though, I think we hope to move the Apple-maintained ports to 
CMake, so the value of changes to the Xcode-based build system may be limited. 
We think this could speed up both incremental and full builds significantly.

 - Maciej


> 
> Thanks,
> -Sam
> 
> ___
> 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] User Agent Client Hints

[Maciej Stachowiak]

> On Nov 2, 2020, at 8:56 AM, Yoav Weiss  wrote:
> 
> Thanks for re-reviewing, Maciej!
> 
> Adding Mike Taylor, who's likely to take a closer look at this.
> 
> On Mon, Nov 2, 2020 at 2:17 AM Maciej Stachowiak  <mailto:m...@apple.com>> wrote:
> 
> I just did a fresh review of that spec and explainer. Thanks for addressing 
> many of the previous issues. This addresses many of the potential objections.
> 
> Here’s the new issues I filed:
> 
> https://github.com/WICG/ua-client-hints/issues/141 
> <https://github.com/WICG/ua-client-hints/issues/141>
> https://github.com/WICG/ua-client-hints/issues/142 
> <https://github.com/WICG/ua-client-hints/issues/142>
> https://github.com/WICG/ua-client-hints/issues/143 
> <https://github.com/WICG/ua-client-hints/issues/143>
> https://github.com/WICG/ua-client-hints/issues/144 
> <https://github.com/WICG/ua-client-hints/issues/144>
> https://github.com/WICG/ua-client-hints/issues/145 
> <https://github.com/WICG/ua-client-hints/issues/145>
> https://github.com/WICG/ua-client-hints/issues/146 
> <https://github.com/WICG/ua-client-hints/issues/146>
> https://github.com/WICG/ua-client-hints/issues/147 
> <https://github.com/WICG/ua-client-hints/issues/147>
> https://github.com/WICG/ua-client-hints/issues/148 
> <https://github.com/WICG/ua-client-hints/issues/148>
> https://github.com/WICG/ua-client-hints/issues/149 
> <https://github.com/WICG/ua-client-hints/issues/149>
> https://github.com/WICG/ua-client-hints/issues/150 
> <https://github.com/WICG/ua-client-hints/issues/150>
> https://github.com/WICG/ua-client-hints/issues/151 
> <https://github.com/WICG/ua-client-hints/issues/151>
> 
> 
> Thanks for filing those! We'll take a look and respond shortly.
>  
> Most of these are minor/editorial, but I think 151 is potentially a 
> deal-breaker. I may be misreading the spec, but as written 
> getHighEntropyValues seems to give access to all of the high entropy client 
> hints to third-party scripts in the first party context, and scripts running 
> in third-party iframes, regardless of which ones the site has opted into via 
> the relevant HTTP header. 
> 
> That's indeed the case, as we didn't consider the Client Hints opt-in to be 
> something that impacts the availability of the JS API. (as it doesn't do that 
> for other hints)

We’re currently deeply skeptical of implementing any of the other client hints 
due to their expansion of fingerprinting surface, so I don’t feel particularly 
compelled by that precedent. That said, it’s likely the other client hints have 
this same problem, where they expose fingerprinting surface way more widely 
than they may be intending to.

> That would be a huge problem, as it would grant a lot of active 
> fingerprinting surface unnecessarily 
> 
> We did discuss 
> <https://github.com/WICG/ua-client-hints/issues/37#issuecomment-576730548> 
> adding a Feature Policy (now Permission Policy) to that effect. Would that 
> help with your concerns?

My understanding is that feature policy applies at the frame level, and 
therefore could not be used to control what happens when a third-party script 
in a first party context calls the API. Even for third-party iframes, it seems 
like Feature Policy could only default-deny this JS API entirely, and would not 
be able to filter the results down to the set delegated via HTTP headers (or 
otherwise). Maybe you intend a feature policy per individual high entropy hint, 
but first of all that seems like overkill, and second, the spec is clearly not 
written to support such filtering.

So no, it would not address the concerns.

I think the best approach is to limit the hints to those opted into (or, in 
case of a third-party frame, delegated). That or remove the script API 
entirely. The origin-based delegation model that works well at the HTTP level 
is not well aligned with the widespread practice of including third-party 
scripts in the top frame.

The spec does not eve allow denying the request entirely as written. A 
non-normative Note suggests that is allowed, but I can’t find any step in the 
algorithm that would ever reject the promise.

>  
> (perhaps even expanding beyond what is currently possible with the UA string).
> 
> Can you expand on that last point?

I mean that the client hints might include info that is not in the UA sting 
(possibly not at all, or possibly frozen in UA string but could be unfrozen in 
the client hints).

>  
> 
> Regards,
> Maciej
> 
> 
>> On Oct 27, 2020, at 12:35 AM, Yoav Weiss > <mailto:y...@yoav.ws>> wrote:
>> 
>> Yet-another ping! :)
>> 
>> On Wed, Oct 7, 2020 at 8:23 AM Yoav Weiss > <mailto:y...@yoav.ws>> wrote:
>> Fr

Re: [webkit-dev] Feedback on Blink's text fragment directive proposal

[Maciej Stachowiak]

> On Oct 30, 2020, at 1:40 PM, David Bokan  wrote:
> 
> Hi Ryosuke,
> 
> Would just like to clarify one point.
> 
> On Fri, Sep 25, 2020 at 12:42 PM David Bokan  > wrote:
> [Sorry, meant to reply-all]
> 
> On Fri, Sep 25, 2020 at 1:25 AM Ryosuke Niwa  > wrote:
> 
> On Thu, Sep 24, 2020 at 8:19 AM David Bokan  > wrote:
> Can you clarify what question you’re looking to have answered? Are you asking 
> for a new standards position in light of the replies below?
> 
>  There are two specific points:
> 
>  - As I understand it, HTML requires multi-vendor interest to merge changes 
> to specs. Is Apple's position sufficient to start that process? I'd be happy 
> to start turning the spec into PRs but I interpreted the earlier position in 
> this thread more as "not-opposed" rather than support (is that a fair 
> reading?)
> 
> Given we're concerned about compatibility and this affects how URL, which is 
> a pretty fundamental part of the Web, is interpreted, it's fair to say we're 
> not ready to endorse such a motion.
> 
> The change we've proposed and implemented in Chrome doesn't touch anything in 
> the URL spec or handling; it's entirely an extension to fragment processing 
> in HTML documents only. If this were implemented in WebKit and Gecko I think 
> that'd address any compat issues? If you don't agree, could you clarify what 
> you see as the main compat risk?

It looks like the current spec does not affect URL per se, but does have this 
remark re the fragment directive: "It is reserved for UA instructions, such as 
text=, and is stripped from the URL during loading so that author scripts can’t 
directly interact with it.” 
>

The is not specified precisely enough for interop. What does it mean to strop 
the fragment directive from the UR? When during loading does this occur?

Section 3.3.1 is more specific 
>
 in that it monkeypatches the HTML create and initialize a Document object 
steps in a way that would affect what JavaScript sees.  However, it’s not clear 
what happens to other ways the UA exposes the URL, such as in the location 
field, or if the page is bookmarked or shared.

Regards,
Maciej

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

Re: [webkit-dev] User Agent Client Hints

[Maciej Stachowiak]

I just did a fresh review of that spec and explainer. Thanks for addressing 
many of the previous issues. This addresses many of the potential objections.

Here’s the new issues I filed:

https://github.com/WICG/ua-client-hints/issues/141 

https://github.com/WICG/ua-client-hints/issues/142 

https://github.com/WICG/ua-client-hints/issues/143 

https://github.com/WICG/ua-client-hints/issues/144 

https://github.com/WICG/ua-client-hints/issues/145 

https://github.com/WICG/ua-client-hints/issues/146 

https://github.com/WICG/ua-client-hints/issues/147 

https://github.com/WICG/ua-client-hints/issues/148 

https://github.com/WICG/ua-client-hints/issues/149 

https://github.com/WICG/ua-client-hints/issues/150 

https://github.com/WICG/ua-client-hints/issues/151 


Most of these are minor/editorial, but I think 151 is potentially a 
deal-breaker. I may be misreading the spec, but as written getHighEntropyValues 
seems to give access to all of the high entropy client hints to third-party 
scripts in the first party context, and scripts running in third-party iframes, 
regardless of which ones the site has opted into via the relevant HTTP header. 
That would be a huge problem, as it would grant a lot of active fingerprinting 
surface unnecessarily (perhaps even expanding beyond what is currently possible 
with the UA string).

Regards,
Maciej


> On Oct 27, 2020, at 12:35 AM, Yoav Weiss  wrote:
> 
> Yet-another ping! :)
> 
> On Wed, Oct 7, 2020 at 8:23 AM Yoav Weiss  > wrote:
> Friendly ping! :)
> 
> On Wed, Sep 30, 2020 at 9:29 AM Yoav Weiss  > wrote:
> Hi WebKit folks,
> 
> Circling back on the previous discussion 
>  about 
> User-Agent ClientHint. The feature was implemented in Chromium and is being 
> rolled out in Chrome.
> 
> There were some concerns mentioned in the previous thread, that we believe 
> were since addressed. Would the feature be something that WebKit would 
> consider shipping? 
> 
> Cheers :)
> Yoav
> ___
> 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] WebKit Transition to Git

[Maciej Stachowiak]

> On Oct 13, 2020, at 2:37 PM, Konstantin Tokarev  wrote:
> 
> 
> 
> 13.10.2020, 22:33, "Maciej Stachowiak" :
>>>  On Oct 2, 2020, at 10:59 AM, Michael Catanzaro  
>>> wrote:
>>> 
>>>  On Fri, Oct 2, 2020 at 6:36 pm, Philippe Normand  wrote:
>>>>  Would you also consider preventing merge commits in order to keep a
>>>>  clean mainline branch?
>>> 
>>>  Big +1 to blocking merge commits. Merge commits in a huge project like 
>>> WebKit would make commit archaeology very frustrating. (I assume this is 
>>> implied by the monotonic commit identifiers proposal, but it doesn't 
>>> exactly say that.)
>> 
>> I’m assuming your objection is to regular merges, but how do you feel about 
>> squash merges? Or do you think all PRs should be landed by rebasing?
> 
> I'm not Michael but will add my 2 dollars anyway :)
> 
> In these two approaches commits inside PR have different meaning, and 
> workflow is different.
> 
> Below I use a term "atomic change" to describe minimal code change which is a 
> self-contained work unit with following properties:
> * It implements well-defined task which can be summarized as a short English 
> sentence (typical soft limit is 60 characters)
> * It doesn't introduce defects (e.g. bugs, compilation breakages, style 
> errors, typos) which were discovered during review process
> * It doesn't include any code changes unrelated to main topic. This 
> separation is sometimes subjective, but it's usually recommended to split 
> refactoring and implementation of feature based on that, bug fix and new 
> feature, big style change and fix or feature.
> 
> AFAIU our current review process has similar requirements to patches 
> submitted to Bugzilla, though sometimes patches include unrelated changes. 
> This can be justified by weakness of webkit-patch/Bugzilla tooling which has 
> no support for patch series, and by fact that SVN doesn't support keeping 
> local patch series at all.
> 
> 1. Workflow 1 - "Squash merge" policy
> 
> * Whole PR is considered to be a single atomic change of WebKit source tree. 
> If work is supposed to be landed as a series of changes which depend on each 
> other (e.g. refactoring and feature based on it, or individual separate 
> features touching same parts of code), each change needs a separate PR, and, 
> as a consequence, only one of them can be efficiently reviewed at the moment 
> of time
> * Commits in PR represent review iterations or intermediate implementation 
> progress
> * Reviewers' comments are addressed by pushing new commits without rewriting 
> history, which works around GitHub's lack of "commit revisions". Also this 
> workflow has lower entry barrier for people who haven't mastered git yet, as 
> it requires only "git commit" and "git push" without rebases.
> 
> 2. Workflow 2 - "Rebase" ("cherry-pick")) or "Merge" policy
> 
> * PR is considered to be a series of atomic changes. If work consists of 
> several atomic changes, each commit represent an atomic change
> * Review iterations are done by fixing commits in place and reuploading 
> entire series using force push (of course if review discovers that 
> substantial part of work is missing it can be added as a new atomic commit to 
> the series)
> * It's possible to review each commit in the series separately
> * Workflow requires developers to have more discipline and experience with 
> using git rebase for history rewriting. Entry barrier can be lowered by 
> providing step by step instructions like e.g. [1]. 
> 
> 
> Workflow 1 is more like what we have now with Bugzilla.
> 
> Workflow 2 is used by many projects which use git for a long time and value 
> high-quality commit history. It's used e.g. by Linux kernel, or projects 
> which use Gerrit as a review tool (Chromium, Android, Qt, etc). It advantages 
> for developers (who can submit more work to review at the same time without 
> risk of mixing up unrelated changes together), reviewers (it's easier to 
> review atomic changes than those with too high or too low granularity), 
> maintainers of stable branches (they can pick bug reports and avoid at least 
> some unneeded refactorings, features and style improvements).
> 
> Workflow 1 is the most obvious way to use GitHub, because it doesn't make any 
> hints about existence of workflow 2. However, many projects which use GitHub 
> for code review and value high-quality history are using workflow 2. For 
> example, see Ryosuke's example with whatwg/html repo.
> 
> Workflow 2 is facilitated by Gerrit, which doesn't require using force pushes 
> and

Re: [webkit-dev] WebKit Transition to Git

[Maciej Stachowiak]

> On Oct 3, 2020, at 9:42 AM, Tetsuharu OHZEKI  
> wrote:
> 
>>> I think having to create an account on a website isn't the main thing
>>> preventing people to contribute anyway? It's more about having to use
>>> project-specific tools to prepare the patch for submission (in the case
>>> of WebKit, having to write the commit message in the Changelog file, for
>>> example).
>> 
>> It's about all those things. We've definitely heard of people
>> complaining or refusing to create a Bugzilla account to report bugs.
>> I've gotta say I'm very much concerned about getting rid of change
>> logs when we move to Git. We put a lot of useful information about
>> what was causing the bug, how we fixed it, and why we fixed the way we
>> did in a change log. I've seen a few projects which transitioned to
>> Git and somehow lost the rigor in maintaining an equally high quality
>> commit message, partly because most code review tools don't let you
>> add inline comments to commit messages.
> 
> I'd like to tell my feelings about a ChangeLog file other than
> perspective for code review.

I think we should come up with a way to have the same level of detail in commit 
messages as is currently present in ChangeLog entries.

One example: ChangeLog-style commit message is included in a file in the diff 
(so that the review tool can properly review it), and it would be dropped and 
converted to a commit entry at merge time.

> 
> As a newbie patch contributor, it's true that ChangeLog file is a
> *bit* tired when I update a patch.
> I felt repeatedly that it should be replaced by VCS' commit log to
> make it easier.
> 
> On the other hand, ChangeLog file also helps me many times when I dig
> into the history of WebKit
> because ChangeLog file contains what functions are removed in which
> commit with Bugzilla id
> and sometimes includes detailed reason for changeset.
> 
> Perhaps it may be just that I don't know the way, VCS (I think here is
> Git) has a powerful feature to trace when we added codes
> but it's hard to trace when we removed codes, and it force a tough
> work to me when I investigate why we introduced this line to fix a
> bug.
> By contrast, WebKit's ChangeLog file is helpful to make it easier to
> trace both of adding ones and removing codes.
> 
> --
> Tetsuharu OHZEKI
> tetsuharu.ohz...@gmail.com 
> 
> On Sat, Oct 3, 2020 at 7:17 PM Ryosuke Niwa  > wrote:
>> 
>> On Sat, Oct 3, 2020 at 2:25 AM Adrien Destugues
>> mailto:pulkoma...@pulkomandy.tk>> wrote:
>>> 
>>> On Fri, Oct 02, 2020 at 07:05:21PM -0500, Michael Catanzaro wrote:
> I realize that Gerrit might not integrate at all with hosting the repo
> on Github, but has any thought been given to this aspect of the
> transition?
 
 That sounds like it would be a significant barrier to contribution, and
 frankly defeat the point of switching. If we have serious concerns with
 GitHub's code review functionality (which, again, I'm not familiar with),
 then we should just use GitLab and have everything in one place. (GitLab
 accepts GitHub logins via OAuth, both on gitlab.com and self-hosted
 instances, so the barrier to contributing remains low either way.)
>>> 
>>> Gerrit accepts GitHub and other OAuth providers as well, so that's not a
>>> problem. We have been using this for Haiku code reviews for a few years
>>> now, and interestingly we got some complaints from people who don't want
>>> to have a Github account (for various reasons) and won't use our code
>>> review tool because of that.
>>> 
>>> I think the integration referred to was rather in terms of having
>>> reviews synchronized between Gerrit and Github pull requests, which is
>>> also possible, but I think if the point is to use Github, it doesn't
>>> work this way: if your workflow is too different from the standard way
>>> to use Github, people will still be confused by it and it will still be
>>> a barrier to contribution.
>> 
>> But using Gerrit would make that situation any better either.
>> 
>>> I think having to create an account on a website isn't the main thing
>>> preventing people to contribute anyway? It's more about having to use
>>> project-specific tools to prepare the patch for submission (in the case
>>> of WebKit, having to write the commit message in the Changelog file, for
>>> example).
>> 
>> It's about all those things. We've definitely heard of people
>> complaining or refusing to create a Bugzilla account to report bugs.
>> I've gotta say I'm very much concerned about getting rid of change
>> logs when we move to Git. We put a lot of useful information about
>> what was causing the bug, how we fixed it, and why we fixed the way we
>> did in a change log. I've seen a few projects which transitioned to
>> Git and somehow lost the rigor in maintaining an equally high quality
>> commit message, partly because most code review tools don't let you
>> add inline comments to commit 

Re: [webkit-dev] WebKit Transition to Git

[Maciej Stachowiak]

> On Oct 2, 2020, at 10:59 AM, Michael Catanzaro  wrote:
> 
> On Fri, Oct 2, 2020 at 6:36 pm, Philippe Normand  wrote:
>> Would you also consider preventing merge commits in order to keep a
>> clean mainline branch?
> 
> Big +1 to blocking merge commits. Merge commits in a huge project like WebKit 
> would make commit archaeology very frustrating. (I assume this is implied by 
> the monotonic commit identifiers proposal, but it doesn't exactly say that.)

I’m assuming your objection is to regular merges, but how do you feel about 
squash merges? Or do you think all PRs should be landed by rebasing?

My own preference would be to require squash merge, because it keeps the 
history simple for the main branch, but does not risk putting intermediate 
revisions which may work or even build on the main branch.

 - Maciej

> 
> I'm sure transition to git and GitHub should go well. I would have selected 
> GitLab myself -- it's nicer and also overwhelmingly popular -- but whatever. 
> (Does GitHub have merge request approvals? Replicating our reviewer/owner 
> permissions with GitLab merge request approvals would be easy.)
> 
> One downside is that using github.com might actually make it *too* easy to 
> spam us with low-quality issue reports and merge requests. We've historically 
> been pretty bad at maintaining a clean issue tracker -- the quantity of 
> untriaged issues on Bugzilla is very high -- and GitHub will make this worse. 
> That's not an issue with the GitHub platform, though. Just something to stay 
> on top of.
> 
> 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

Re: [webkit-dev] Feedback on Blink's text fragment directive proposal

[Maciej Stachowiak]

Can you clarify what question you’re looking to have answered? Are you asking 
for a new standards position in light of the replies below?

 - Maciej

> On Sep 18, 2020, at 7:35 AM, David Bokan  wrote:
> 
> Friendly ping to get an answer here.
> 
> Do my answers above address those points or is there anything else I can 
> clarify?
> 
> Thanks,
> David
> 
> On Mon, Aug 31, 2020 at 1:42 PM David Bokan  > wrote:
> [sending (again, sorry) from correct e-mail]
> 
> I think Nick's replies 
>  
> mostly still apply, some updated answers to those questions.
> 
> (1) We’re concerned about compatibility issues in a world where some browsers 
> support this but not all. Aware browsers will strip `:~:`, but unaware 
> browsers won’t. I saw that on the blink-dev ItS thread, it was mentioned that 
> at least one site (webmd.com ) totally breaks if any 
> fragment ID is exposed to the page. This makes it difficult to create a link 
> that uses this feature but which is safe in all browsers:
> - Since there is no feature detection mechanism, it’s hard for a webpage to 
> know whether it should issue such a link. It would have to be based on UA 
> string checks, which is regrettable.
> - A link meant for a supporting browser can end up in a non-supporting 
> browser, at the very least by copy paste from the URL field, and perhaps 
> through other features to share a link.
> 
> We do have a feature detection 
> 
>  mechanism for this.
> 
> On the latter point, this is true but we think implementing fragment 
> directive stripping (removing the part after and including `:~:`) is trivial 
> even if the UA doesn't wish to implement the text-fragment feature. FWIW, we 
> haven't seen or heard of another such example since.
>  
> (2) The portions of this Community Group report that monkey patch other 
> standards (HTML, URL and CSSOM View I think?) should be turned into PRs 
> against those specifications. Monkeypatching other specs is not a good way to 
> build specifications for the long term.
> 
> We still need support from another vendor to start merging the monkey patches 
> into the real standards - if Apple's supportive I'd be happy to start on that 
> immediately.
>  
> (3) Text fragment trumping a regular fragment ID seems a bit strange. The 
> more natural semantic would be that the text search starts at the fragment, 
> so if there are multiple matches it’s possible to scroll to a more specific 
> one. It’s not clear why the fragment is instead entirely ignored.
> 
> This was discussed in more detail in issue#75 
> ; I agree with 
> Nick's point that the disambiguation syntax is already specific enough that 
> starting from a fragment isn't necessary. This also keeps us 
> mostly-compatible with the TextQuoteSelector 
>  specified in 
> WebAnnotations which I think may have benefits for interaction with 
> annotation applications.
> 
> On Mon, Aug 31, 2020 at 1:31 PM David Bokan  > wrote:
> I think Nick's replies 
>  
> mostly still apply, some updated answers to those questions.
> 
> (1) We’re concerned about compatibility issues in a world where some browsers 
> support this but not all. Aware browsers will strip `:~:`, but unaware 
> browsers won’t. I saw that on the blink-dev ItS thread, it was mentioned that 
> at least one site (webmd.com ) totally breaks if any 
> fragment ID is exposed to the page. This makes it difficult to create a link 
> that uses this feature but which is safe in all browsers:
> - Since there is no feature detection mechanism, it’s hard for a webpage to 
> know whether it should issue such a link. It would have to be based on UA 
> string checks, which is regrettable.
> - A link meant for a supporting browser can end up in a non-supporting 
> browser, at the very least by copy paste from the URL field, and perhaps 
> through other features to share a link.
> 
> We do have a feature detection 
> 
>  mechanism for this.
> 
> On the latter point, this is true but we think implementing fragment 
> directive stripping (removing the part after and including `:~:`) is trivial 
> even if the UA doesn't wish to implement the text-fragment feature. FWIW, we 
> haven't seen or heard of another such example since.
>  
> (2) The portions of this Community Group report that monkey patch other 
> standards (HTML, URL and CSSOM View I think?) should be turned into PRs 
> against those specifications. Monkeypatching other specs is not a good way to 
> build specifications for the long 

Re: [webkit-dev] Suggesting to enable paint timing by default

[Maciej Stachowiak]

> On Jul 17, 2020, at 12:12 AM, Noam Rosenthal  wrote:
> 
> 
> 
> On Thu, Jul 16, 2020 at 11:03 PM Keith Miller  <mailto:keith_mil...@apple.com>> wrote:
> Results appear to be neutral on the page load time benchmark, so you should 
> be good on that front. I don’t know who the best person to vet the maturity 
> of the code is though, sorry.
> 
> Thanks a lot Keith, I appreciate it!
> @Maciej Stachowiak <mailto:m...@apple.com>, what would be a good way to 
> assert whether the code maturity is good enough to enable paint timing by 
> default?
> The original code was reviewed by smfr and initially by zalan. It's covered 
> by over 30 tests, mostly WPT, and A/B tests show no effect on load times as 
> per Keith's check.
> Would asking for additional reviews be the next step? From whom?

At this point, if a reviewer approves a patch to enable it by default on trunk, 
I think you are good to go.

As a courtesy to Apple, I’d ask you to hold off on landing until mid-September, 
but that is optional.

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

Re: [webkit-dev] Plugin process

[Maciej Stachowiak]

> On Jul 20, 2020, at 10:23 AM, Darin Adler  wrote:
> 
>> On Jul 20, 2020, at 7:35 AM, Michael Catanzaro  wrote:
>> 
>> Then we can make the plugin process specific to PLATFORM(COCOA)
> 
> Side note: It will be specific to PLATFORM(MAC).

And we’ll probably attempt to remove it from PLATFORM(MAC) once we get data on 
the compatibility impact of doing so.

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

Re: [webkit-dev] Request for position on Media Feeds

[Maciej Stachowiak]

Without having read the spec in detail, the first thing I wonder is why not use 
RSS for this purpose? That seems to be the de facto standard for audio feeds 
(i.e. podcasts). This is dismissed in a cursory way in the explainer. There’s 
some more detailed discussion in the issue filed by the TAG: 
, which I found 
eventually. It seems like some of that should go in the Explainer.

Second, it’s not clear to me if this spec has anything that would need to be 
implemented in the browser engine. Rather, it provides a format for metadata 
linked from the page, which can optionally be used by the UA in some manner 
unrelated to processing of web content. Is that correct? (Asking in part to 
know the right people to ask for an opinion.)

Third, and this is a minor thing, it seems strange that the spec (and parts of 
its syntax) are called Media Feeds instead of Video Feeds, since audio is 
explicitly out of scope. Perhaps audio is intended to be added later. If so, 
that increases the value of aligning with how podcasts are done today.


> On Jun 17, 2020, at 2:48 PM, Becca Hughes  wrote:
> 
> Hi webkit-dev,
> 
> I would like to request an official position on Media Feeds.
> 
> Explainer: https://github.com/WICG/media-feeds/blob/master/explainer.md 
> 
> Chrome Status: https://chromestatus.com/feature/5695114963845120 
> 
> TAG review: https://github.com/w3ctag/design-reviews/issues/477 
> 
> 
> Thanks,
> Becca
> ___
> 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 First-Party Sets

[Maciej Stachowiak]

> On Jun 3, 2020, at 5:21 PM, Kaustubha Govind  wrote:
> 
> Hi Maciej,
> 
> Thanks for feedback.
> 
> We had previously started the incubation process in WICG, and it was just 
> moved there: https://github.com/WICG/first-party-sets 
> <https://github.com/WICG/first-party-sets>
> 
> In addition, I have also filed a Proposal Issue in PrivacyCG: 
> https://github.com/privacycg/proposals/issues/17 
> <https://github.com/privacycg/proposals/issues/17>
Thanks! I expressed support for the above proposal.

> 
> Regarding your concern about preventing (a) Bad faith claims, and (b) The 
> “500 domains” problem. These are absolutely cases that we would consider 
> "unacceptable sets", and our initial thinking was that this would be covered 
> by the "UA Policy" and be subject to review during the 
> acceptance/verification process. In this version of the proposal, we 
> attempted to build maximum flexibility for UAs; but it has since become clear 
> that browsers find this problem worth solving, and also deem it important to 
> agree on a common policy. We are currently working on an initial draft of a 
> policy, and will bring that for discussion when ready. 

That sounds like a positive development, looking forward to it.


> 
> Kaustubha
> 
> 
> 
> 
> 
> On Wed, May 27, 2020 at 3:16 PM Maciej Stachowiak  <mailto:m...@apple.com>> wrote:
> 
> (1) I notice that this proposal still exists only in a random personal repo. 
> Could it please be contributed to an appropriate standards or incubation 
> group? Privacy CG would almost certainly welcome this, and I’m sure it would 
> be easy to move to WICG as well. There doesn’t seem to be a reason to keep 
> the proposal in this “pre-incubation” state.
> 
> (2) As discussed in the Privacy CG Face-to-Face, there are two key problems 
> to solve with First Party Sets or any similar proposals:
>   (a) Bad faith claims. How to prevent domains that are not actually 
> owned and controlled by the same party from making claims of being related? 
> For example, an ad network could get its top publishers to enter an 
> association to regain a certain level of tracking powers.
>   (b) The “500 domains” problem. If a first party owns domains that 
> aren’t obviously related and that appear to different and distinct brands to 
> the user, then the user won’t expect to be tracked across them. (Problem 
> named such because of a party known to have hundreds of domains that mostly 
> appear to be totally distinct brands). Users would expect both transparency 
> and control over this.
> 
> The explainer does not really give solutions to these problems. Rather, it 
> defers entirely to each individual browser to define a policy to solve these 
> problems. Deferring to individual browsers on such key points is problematic 
> in a few ways:
>   (i) It doesn’t seem right for a proposed web standard to solve only the 
> easy problem of syntax, and leave the hardest technical problems of semantics 
> to each browser separately.
>   (ii) Deferring in this way is bad for interop.
>   (iii) It’s not entirely clear if there exists any policy that suitably 
> addresses these problems. By only speculating about policies, the explainer 
> fails to provide an existence proof that it is implementable.
>   (iv) If sites come to depend on First Party Sets for correct behavior, 
> there is a risk that every UA will have to adopt a policy that’s the most 
> permissive of any, or that copies the most popular UA, for the sake of 
> compatibility. Thus, leaving this open may not in fact provide a useful 
> degree of freedom.
> 
> Given these issues, I don’t think we’d implement the proposal in its current 
> state. That said, we’re very interested in this area, and indeed, John 
> Wilander proposed a form of this idea before Mike West’s later re-proposal. 
> If these issues were addressed in a satisfactory way, I think we’d be very 
> interested. It does seem that binding strictly to eTLD+1 is not good enough 
> for web privacy features. Driving these issues to resolution is part of why 
> we’d like to see this proposal adopted into a suitable standards or 
> incubation group.
> 
> Regards,
> Maciej
> 
> 
>> On May 27, 2020, at 9:33 AM, Lily Chen > <mailto:chl...@chromium.org>> wrote:
>> 
>> Hi WebKit-dev,
>> 
>> We are requesting WebKit's position on the First-Party Sets proposal as 
>> described in the explainer [1]. Feedback [2] was provided on a previous 
>> version of the proposal, which has since been revised. The TAG review thread 
>> is here [3].
>> 
>> Thanks!
>> 
>> [1] Explai

Re: [webkit-dev] Request for position on First-Party Sets

[Maciej Stachowiak]

(1) I notice that this proposal still exists only in a random personal repo. 
Could it please be contributed to an appropriate standards or incubation group? 
Privacy CG would almost certainly welcome this, and I’m sure it would be easy 
to move to WICG as well. There doesn’t seem to be a reason to keep the proposal 
in this “pre-incubation” state.

(2) As discussed in the Privacy CG Face-to-Face, there are two key problems to 
solve with First Party Sets or any similar proposals:
(a) Bad faith claims. How to prevent domains that are not actually 
owned and controlled by the same party from making claims of being related? For 
example, an ad network could get its top publishers to enter an association to 
regain a certain level of tracking powers.
(b) The “500 domains” problem. If a first party owns domains that 
aren’t obviously related and that appear to different and distinct brands to 
the user, then the user won’t expect to be tracked across them. (Problem named 
such because of a party known to have hundreds of domains that mostly appear to 
be totally distinct brands). Users would expect both transparency and control 
over this.

The explainer does not really give solutions to these problems. Rather, it 
defers entirely to each individual browser to define a policy to solve these 
problems. Deferring to individual browsers on such key points is problematic in 
a few ways:
(i) It doesn’t seem right for a proposed web standard to solve only the 
easy problem of syntax, and leave the hardest technical problems of semantics 
to each browser separately.
(ii) Deferring in this way is bad for interop.
(iii) It’s not entirely clear if there exists any policy that suitably 
addresses these problems. By only speculating about policies, the explainer 
fails to provide an existence proof that it is implementable.
(iv) If sites come to depend on First Party Sets for correct behavior, 
there is a risk that every UA will have to adopt a policy that’s the most 
permissive of any, or that copies the most popular UA, for the sake of 
compatibility. Thus, leaving this open may not in fact provide a useful degree 
of freedom.

Given these issues, I don’t think we’d implement the proposal in its current 
state. That said, we’re very interested in this area, and indeed, John Wilander 
proposed a form of this idea before Mike West’s later re-proposal. If these 
issues were addressed in a satisfactory way, I think we’d be very interested. 
It does seem that binding strictly to eTLD+1 is not good enough for web privacy 
features. Driving these issues to resolution is part of why we’d like to see 
this proposal adopted into a suitable standards or incubation group.

Regards,
Maciej


> On May 27, 2020, at 9:33 AM, Lily Chen  wrote:
> 
> Hi WebKit-dev,
> 
> We are requesting WebKit's position on the First-Party Sets proposal as 
> described in the explainer [1]. Feedback [2] was provided on a previous 
> version of the proposal, which has since been revised. The TAG review thread 
> is here [3].
> 
> Thanks!
> 
> [1] Explainer: https://github.com/krgovind/first-party-sets 
> 
> [2] Previous feedback: https://github.com/krgovind/first-party-sets/issues/6 
> 
> [3] TAG review: https://github.com/w3ctag/design-reviews/issues/342 
> 
> ___
> 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] Suggesting to enable paint timing by default

[Maciej Stachowiak]

> On May 11, 2020, at 9:53 PM, Noam Rosenthal  wrote:
> 
> 
> 
> On Tue, May 12, 2020 at 1:36 AM Maciej Stachowiak  <mailto:m...@apple.com>> wrote:
> 
> I noticed from comments in one of the Radars that the patch may result in an 
> additional “fake paint”, so it should probably be performance tested. Have 
> you done any testing?
> I've tested it locally, I haven't noticed any significant side effect, 
> because in complex situations the fake paint only happens once per page and 
> bails early once contentfulness is detected. but I can run any additional 
> test needed.
>  
> We’ll likely want to A/B some of Apple’s page load speed benchmarks.
> A/B testing load speed sounds sensible. How do we go about doing that?

Unfortunately our page load speed benchmarks are not public because they 
incorporate captured page content, which we can’t freely redistribute.

A helpful person from Apple may be able to set up an A/B test for this patch.

 - Maciej

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

Re: [webkit-dev] Suggesting to enable paint timing by default

[Maciej Stachowiak]

I noticed from comments in one of the Radars that the patch may result in an 
additional “fake paint”, so it should probably be performance tested. Have you 
done any testing? We’ll likely want to A/B some of Apple’s page load speed 
benchmarks.

I’d like to hear from others on maturity of the spec and readiness of the code.

 - Maciej

> On May 11, 2020, at 11:44 AM, Noam Rosenthal  wrote:
> 
> Following the discussion with Simon in 
> https://bugs.webkit.org/show_bug.cgi?id=78011 
> 
> 
> Since we have a pretty stable spec (https://w3c.github.io/paint-timing/ 
> ), lots of passing web platform tests, 
> other browser vendor support and a working implementation of first contentful 
> paint, I am planning to submit a patch to enable paint timing by default. 
> 
> https://bugs.webkit.org/show_bug.cgi?id=211736 
> 
> 
> Any objections? Other thoughts?
> ___
> 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] Platform.h vs. makefiles

[Maciej Stachowiak]

I guess it depends on value of this (and feasibility of IDE highlighting based 
on a generated source file) vs value of having a common approach for 
compile-time and runtime flags. Runtime flags and their default values likely 
can’t be effectively expressed in headers.

Separate file also lets us do things like make build systems exclude files 
based on feature flag values, though of course, an alternative is to surround 
whole files with #include guards and always build everything.

> On May 11, 2020, at 9:34 AM, Alexey Proskuryakov  wrote:
> 
> 
> I see substantial appeal in having a separate data file, however I'm not sure 
> if it can inform IDE parsing and syntax highlighting for code 
> enabled/disabled at compile time. Header files seem like they would get that 
> right more often.
> 
> - Alexey
> 
> 
>> 10 мая 2020 г., в 10:07 PM, Maciej Stachowiak > <mailto:m...@apple.com>> написал(а):
>> 
>> 
>> I think the best way to configure WebKit is to use a separate data file, 
>> neither a header nor a makefile or similar, that defines the options in a 
>> single place with clear syntax. Then everything else is generated from that. 
>> Such a system could cover runtime flags as well, which are even more 
>> scattered around the project than compile-time flags.
>> 
>> Moving logic from build files to the header is probably a move in the right 
>> direction, though of course it carries risk, particularly for less tested 
>> configurations.
>> 
>> -  Maciej
>> 
>>> On May 10, 2020, at 5:13 PM, Darin Adler >> <mailto:da...@apple.com>> wrote:
>>> 
>>> Hi folks.
>>> 
>>> The Platform.h configuration file family has been useful for WebKit for a 
>>> long time. We created it to try to organize configuration options in WebKit 
>>> so the would not be spread out through the whole project.
>>> 
>>> One way to look at these, particularly the ENABLE options, is as a set of 
>>> configuration options that let each consumer of the WebKit source code 
>>> create a unique flavor of WebKit with the particular features they want 
>>> enabled turned on and others turned off. Another is to think of this as a 
>>> mechanism for keeping decisions made by the WebKit contributors organized 
>>> and easy to understand.
>>> 
>>> If these truly are WebKit consumer options, then it’s important they be set 
>>> as part of the build process. The macros can be defined with a build and 
>>> configuration system outside WebKit, and the Platform.h headers should 
>>> interpret those values correctly.
>>> 
>>> On the other hand, if we are just trying to keep our decisions straight, 
>>> then it would be best if the logic for what is on and what is off by in the 
>>> header files, written with preprocessor macro logic, and not spread across 
>>> multiple make files and scripts.
>>> 
>>> Thus I think the pattern on macOS, for example, of setting these in 
>>> .xcconfig files doesn’t make a lot of sense. I think the .xcconfig files 
>>> should compute the things that need to be determined about the build 
>>> environment, but the configuration decisions should be in files like 
>>> PlatformHaveCocoa.h, for example.
>>> 
>>> I think the guideline should be like this:
>>> 
>>> All code to compute configuration should be in the Platform.h files, not in 
>>> makefiles, with only the following exceptions:
>>> 
>>> 1) Options like ENABLE(XXX) that some ports wish to offer as options to 
>>> people building WebKit can have overridden values in makefiles. But even 
>>> these options should have sensible defaults in the Platform.h headers that 
>>> express the current status of the port from the point of view of the port’s 
>>> maintainers. Ideally we’d find a way to not repeat these default settings 
>>> twice.
>>> 
>>> 2) In some cases, the build machinery needs to contribute to things like 
>>> feature detection. So on some platforms, things like HAVE(READLINE) would 
>>> be set correctly by the build system.
>>> 
>>> Options intended to be set by the environment would carefully be wrapped in 
>>> #ifndef.
>>> 
>>> But other options, which simply express relationships between configuration 
>>> elements, are designed to be set by Platform.h and not overridden by the 
>>> environment, and so they would not be wrapped in #ifndef. Many HAVE options 
>>> and most USE options would fall into this category.
>>> 
>>> What do you all think?
>>> 
>>> — Darin
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto: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] Platform.h vs. makefiles

[Maciej Stachowiak]

> On May 10, 2020, at 11:11 PM, Darin Adler  wrote:
> 
>> On May 10, 2020, at 10:07 PM, Maciej Stachowiak  wrote:
>> 
>> I think the best way to configure WebKit is to use a separate data file, 
>> neither a header nor a makefile or similar, that defines the options in a 
>> single place with clear syntax. Then everything else is generated from that. 
>> Such a system could cover runtime flags as well, which are even more 
>> scattered around the project than compile-time flags.
> 
> Sounds OK. I worry a little about defining yet another language, but 
> otherwise I do find this appealing. Perhaps some people would say that 
> FeatureDefines.props from cmake could be that file?
> 
> Not sure literally a single data file is the best way to do this across 
> multiple platforms/ports. I think PlatformEnableCocoa.h shows us that 
> breaking this down can be helpful.

> 
> One file that has the master list of all the settings, and all the default 
> values. Then other files that contain overlays for each port/configuration 
> where they are different from the default.


Yes, this is what I’d imagine. We could also add ability to inherit if we have 
configurations that want to share most but not all of their flag values. 
Additionally, we might need a way to express conditionals.

> My worry is that it could become complicated, like our TestExpectations 
> files, which were once simple.

It’s possible, but hopefully it could be limited to only necessary complexity.

>> Moving logic from build files to the header is probably a move in the right 
>> direction, though of course it carries risk, particularly for less tested 
>> configurations.
> 
> Yes, I’m not suggesting rushing to do it all at once in a mass change.
> 
> But for new things especially on Apple’s Cocoa platforms, I’d like to avoid 
> FeatureDefines.xcconfig and see new things in the PlatformEnableCocoa.h 
> header file instead. Unless the defines need to affect the build system and 
> not just the C++ code, I think the header file is superior.

That seems like a good direction.

 - Maciej

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

Re: [webkit-dev] Platform.h vs. makefiles

[Maciej Stachowiak]

I think the best way to configure WebKit is to use a separate data file, 
neither a header nor a makefile or similar, that defines the options in a 
single place with clear syntax. Then everything else is generated from that. 
Such a system could cover runtime flags as well, which are even more scattered 
around the project than compile-time flags.

Moving logic from build files to the header is probably a move in the right 
direction, though of course it carries risk, particularly for less tested 
configurations.

-  Maciej

> On May 10, 2020, at 5:13 PM, Darin Adler  wrote:
> 
> Hi folks.
> 
> The Platform.h configuration file family has been useful for WebKit for a 
> long time. We created it to try to organize configuration options in WebKit 
> so the would not be spread out through the whole project.
> 
> One way to look at these, particularly the ENABLE options, is as a set of 
> configuration options that let each consumer of the WebKit source code create 
> a unique flavor of WebKit with the particular features they want enabled 
> turned on and others turned off. Another is to think of this as a mechanism 
> for keeping decisions made by the WebKit contributors organized and easy to 
> understand.
> 
> If these truly are WebKit consumer options, then it’s important they be set 
> as part of the build process. The macros can be defined with a build and 
> configuration system outside WebKit, and the Platform.h headers should 
> interpret those values correctly.
> 
> On the other hand, if we are just trying to keep our decisions straight, then 
> it would be best if the logic for what is on and what is off by in the header 
> files, written with preprocessor macro logic, and not spread across multiple 
> make files and scripts.
> 
> Thus I think the pattern on macOS, for example, of setting these in .xcconfig 
> files doesn’t make a lot of sense. I think the .xcconfig files should compute 
> the things that need to be determined about the build environment, but the 
> configuration decisions should be in files like PlatformHaveCocoa.h, for 
> example.
> 
> I think the guideline should be like this:
> 
> All code to compute configuration should be in the Platform.h files, not in 
> makefiles, with only the following exceptions:
> 
> 1) Options like ENABLE(XXX) that some ports wish to offer as options to 
> people building WebKit can have overridden values in makefiles. But even 
> these options should have sensible defaults in the Platform.h headers that 
> express the current status of the port from the point of view of the port’s 
> maintainers. Ideally we’d find a way to not repeat these default settings 
> twice.
> 
> 2) In some cases, the build machinery needs to contribute to things like 
> feature detection. So on some platforms, things like HAVE(READLINE) would be 
> set correctly by the build system.
> 
> Options intended to be set by the environment would carefully be wrapped in 
> #ifndef.
> 
> But other options, which simply express relationships between configuration 
> elements, are designed to be set by Platform.h and not overridden by the 
> environment, and so they would not be wrapped in #ifndef. Many HAVE options 
> and most USE options would fall into this category.
> 
> What do you all think?
> 
> — Darin
> ___
> 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] Position on User-Agent Client Hints

[Maciej Stachowiak]

Accidentally removed Yoav from Cc and I’m not sure if he is on this list.

> On May 8, 2020, at 12:04 AM, Maciej Stachowiak  wrote:
> 
> 
> I would consider myself mildly positive as to the direction, but that’s my 
> personal view for the moment, absent consultation with my colleagues. I will 
> solicit more viewpoints.
> 
> I particularly appreciate the responsiveness to feedback and that Yoav in 
> particular has been willing to iterate.
> 
> I think there’s a number of things in the spec that should be cleaned up 
> before an implementation ships enabled by default, specifically around 
> interop, privacy, and protection against UA lockouts. I know there are PRs in 
> flight for some of these issues. I think it would be good to get more of the 
> open issues to resolution before actually shipping this.
> 
> Regards,
> Maciej
> 
>> On May 7, 2020, at 4:22 PM, Michael Catanzaro  wrote:
>> 
>> My personal $0.02: I'm mildly supportive of this spec. It's certainly an 
>> improvement on existing HTTP user agent headers. I appreciate that you 
>> worked to incorporate feedback into the spec and considered the concerns of 
>> small browsers.
>> 
>> Is it going to solve all the problems caused by user agent headers? No. If 
>> WebKit implements the spec, we're surely going to eventually need a quirks 
>> list for user agent client hints to decide which websites to lie to, just 
>> like we already have quirks for the user agent header. And as long as Chrome 
>> sends a user agent header that includes the string "Chrome", it's unlikely 
>> we'll be able to get rid of the existing quirks list. But I think client 
>> hints will probably reduce the amount of websites that *accidentally* break 
>> WebKit, by replacing wild west UA header parsing with well-defined APIs, and 
>> adding some GREASE for good measure. The promise of freezing Chrome's UA 
>> header sounds nice, as it makes quirks easier to maintain. And being able to 
>> ration entropy by revealing details about the platform on an active rather 
>> than passive basis is quite appealing.
>> 
>> The spec attracted some misplaced concern about negative impact to small 
>> browsers, which I've rebutted in [1]. I'm not quite so enthusiastic about 
>> this spec as I was initially, especially after I was convinced that the 
>> GREASE is never going to be enough to remove our quirks list, but it's 
>> certainly not going to *hurt* small browsers.
>> 
>> This spec has received some pretty harsh criticism from the user tracking 
>> industry (some call it the "ad industry"). Not historically a friend of 
>> WebKit, so sounds good to me. ;)
>> 
>> One concern I haven't mentioned elsewhere is that frozen UA header might 
>> encourage deeper levels of fingerprinting than are currently used, e.g. for 
>> ad fraud prevention. caddy has started blocking WebKitGTK users based on TLS 
>> handshake fingerprint (yes, really!) [1]. If techniques like that take off 
>> as a result of this, that could potentially backfire on us quite badly. But 
>> websites could choose to do such things today anyway, client hints or no, 
>> and if so, the solution will be for us to just try even harder to look more 
>> like Chrome.
>> 
>> Seems like a net positive overall. I don't work for Apple and can't say 
>> whether it might be implemented by WebKit.
>> 
>> Michael
>> 
>> [1] 
>> https://github.com/w3ctag/design-reviews/issues/467#issuecomment-583104002
>> [2] https://mitm.watch/
>> 
>> 
>> ___
>> 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 mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Position on User-Agent Client Hints

[Maciej Stachowiak]

I would consider myself mildly positive as to the direction, but that’s my 
personal view for the moment, absent consultation with my colleagues. I will 
solicit more viewpoints.

I particularly appreciate the responsiveness to feedback and that Yoav in 
particular has been willing to iterate.

I think there’s a number of things in the spec that should be cleaned up before 
an implementation ships enabled by default, specifically around interop, 
privacy, and protection against UA lockouts. I know there are PRs in flight for 
some of these issues. I think it would be good to get more of the open issues 
to resolution before actually shipping this.

Regards,
Maciej

> On May 7, 2020, at 4:22 PM, Michael Catanzaro  wrote:
> 
> My personal $0.02: I'm mildly supportive of this spec. It's certainly an 
> improvement on existing HTTP user agent headers. I appreciate that you worked 
> to incorporate feedback into the spec and considered the concerns of small 
> browsers.
> 
> Is it going to solve all the problems caused by user agent headers? No. If 
> WebKit implements the spec, we're surely going to eventually need a quirks 
> list for user agent client hints to decide which websites to lie to, just 
> like we already have quirks for the user agent header. And as long as Chrome 
> sends a user agent header that includes the string "Chrome", it's unlikely 
> we'll be able to get rid of the existing quirks list. But I think client 
> hints will probably reduce the amount of websites that *accidentally* break 
> WebKit, by replacing wild west UA header parsing with well-defined APIs, and 
> adding some GREASE for good measure. The promise of freezing Chrome's UA 
> header sounds nice, as it makes quirks easier to maintain. And being able to 
> ration entropy by revealing details about the platform on an active rather 
> than passive basis is quite appealing.
> 
> The spec attracted some misplaced concern about negative impact to small 
> browsers, which I've rebutted in [1]. I'm not quite so enthusiastic about 
> this spec as I was initially, especially after I was convinced that the 
> GREASE is never going to be enough to remove our quirks list, but it's 
> certainly not going to *hurt* small browsers.
> 
> This spec has received some pretty harsh criticism from the user tracking 
> industry (some call it the "ad industry"). Not historically a friend of 
> WebKit, so sounds good to me. ;)
> 
> One concern I haven't mentioned elsewhere is that frozen UA header might 
> encourage deeper levels of fingerprinting than are currently used, e.g. for 
> ad fraud prevention. caddy has started blocking WebKitGTK users based on TLS 
> handshake fingerprint (yes, really!) [1]. If techniques like that take off as 
> a result of this, that could potentially backfire on us quite badly. But 
> websites could choose to do such things today anyway, client hints or no, and 
> if so, the solution will be for us to just try even harder to look more like 
> Chrome.
> 
> Seems like a net positive overall. I don't work for Apple and can't say 
> whether it might be implemented by WebKit.
> 
> Michael
> 
> [1] https://github.com/w3ctag/design-reviews/issues/467#issuecomment-583104002
> [2] https://mitm.watch/
> 
> 
> ___
> 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] Support "registerProtocolHandler" in WebKit2

[Maciej Stachowiak]

Looking at my old email, I think it’s worth supporting for Mail clients for 
example, but I think it would require some OS-level engineering as well to have 
it work on macOS. (Other Apple platforms currently don’t support customizing 
the default mail client).

And I do still think that allow list is safer than block list.

 - Maciej

> On Apr 20, 2020, at 3:27 AM, Frédéric Wang  wrote:
> 
> Hi,
> 
> I'm just bumping this old thread, not because I plan to implement it but
> because I was mentioning it on slack the other day and realized not
> everybody is #standards:
> 
> https://webkit.slack.com/archives/CTY7Z24RZ/p1587142539064000
> 
> In particular, my question was related to safelist VS blocklist
> discussion from https://github.com/whatwg/html/issues/3998
> 
> From the slack replies as well as
> https://lists.webkit.org/pipermail/webkit-dev/2019-November/030967.html
> it seems a complete switch to blocklist is not the option preferred for
> WebKit (if we ever decide to implement this API) so that's what I
> commented on the spec / blink-dev discussions.
> 
> -- 
> Frédéric Wang
> 
> 
> On 04/07/2015 19:24, Sam Weinig wrote:
>> (Sorry, had this sitting in my drafts).
>> 
>> My concern with the registerProtocolHandler() API is that it complicates an 
>> already the very complicated area of custom protocols and a good 
>> implementation requires configuration UI (to choose which of potentially 
>> multiple apps/websites you want a specific protocol to go to) that I am not 
>> sure users are in the position make.  
>> 
>> That, coupled with the small existing usage on the web and very few (if any) 
>> reports from developers that they want this, leads me to think it isn’t a 
>> good API for us to support.
>> 
>> From an implementation perspective I also have concerns.  How is this should 
>> the registration data be managed? Can it fit in the WebSiteData model we are 
>> using for other data? Does it account for non-persistent sessions?  And 
>> lastly, can we get the code size of supporting a feature like this to be 
>> smaller?   
>> 
>> - Sam
>> 
>>> On Jun 7, 2015, at 5:39 PM, Darin Adler  wrote:
>>> 
>>> Are we making progress in this discussion?
>>> 
>>> Maciej stated that he thinks this is useful for mailto and I think that 
>>> Gyuyoung Kim and Michael Catanzaro stated that they want to do this.
>>> 
>>> As one next step in the discussion, is there anyone that wants to present a 
>>> use case for a protocol other than mailto?
>>> 
>>> Sam, Anders, you haven’t replied to the thread since Maciej made his 
>>> remarks two weeks ago. He asked what you dislike about the API.
>>> 
>>> — Darin
>>> ___
>>> 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 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] Support for scrolling=off and scrolling=noscroll

[Maciej Stachowiak]

Seems like a reasonable change.

> On Mar 17, 2020, at 7:19 AM, Frédéric Wang  wrote:
> 
> The spec  
> says that iframe and frame elements have a "scrolling" attribute that can be 
> set to "no", "off", or "noscroll" to disable scrollbars. Until now, WebKit 
> has only supported the "no" value but I opened 
> https://bugs.webkit.org/show_bug.cgi?id=208570 
>  for the remaining ones.
> 
> Gecko supports both and intent-to-ship was sent for Chromium too: 
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/qBQCKhzbIRc/RsfZQmf3AQAJ
>  
> 
> -- 
> Frédéric Wang
> ___
> 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] Same-Site cookies by default

[Maciej Stachowiak]

> On Mar 6, 2020, at 6:58 PM, Patrick Griffis  wrote:
> 
> On 2020-03-06 6:51 pm, John Wilander wrote:
>> Hi Patrick!
>> 
>> Thanks for bringing this up. I’ll share my view of where we are.
>> 
>> First of all, cookies mostly live in the http layer so the various
>> WebKit ports would have to work this out independently to some extent.
>> Maybe libcurl and libsoup have readily available APIs for this?
> 
> libsoup added samesite support this cycle implemented as the spec
> describes so I was wondering if we should add a toggle for this new
> behavior.
> 
>> Second, we have communicated tentative support for SameSite=lax by
>> default, but in terms of its privacy protections, WebKit is far ahead
>> with its Intelligent Tracking Prevention (ITP, or Resource Load
>> Statistics in open source). Servers that expect to get default
>> third-party cookie access merely through a SameSite=none; Secure
>> configuration will find that such an option does not exist under ITP.
>> Instead, third-parties who need cookie access can make use of the
>> Storage Access API which gives users control and transparency.
> 
> There are still ports without ITP; I understand the solution there is to
> implement ITP though :)

In current trunk, if your port has ITP fully supported, "SameSite=Lax by 
default” would be a no-op. If you don’t have ITP, then it is a good fallback. 
If your port has a history of using ITP, or the older Safari/WebKit third-party 
cookie policy, then you will probably face lower compatibility risk than 
Chrome. If not, then watch out for compat issues.

I would urge ports to enable ITP if at all possible, and if you need help from 
Apple folks, we’re happy to advise or otherwise help.


A thought I had while writing this: how should SameSite=Lax interact with 
Storage Access API? Can sites get access to Lax cookies using SAA, or do they 
need to be SameSite=None *and* you have to use SAA to get them? (I should 
probably file this as a spec issue against SAA).


> 
>> Finally, as far as I know, Chrome is still the only browser to try out
>> SameSite=lax plus forced TLS for SameSite=none and they seem to be at
>> 10% rollout at this moment. We’d like to hear some lessons learned
>> from them since it may be a tough rollout, at least for a browser that
>> has historically allowed all cookies in third-party contexts by
>> default. Safari is among a few browsers that has not allowed that. I
>> do not know what default cookie policies the other WebKit browsers
>> have.
>> 
>>   Regards, John
>> 
>>> On Mar 6, 2020, at 1:07 PM, Patrick Griffis  wrote:
>>> 
>>> Chromium has had the idea to treat all cookies as SameSite=Lax by
>>> default as well as blocking SameSite=None over HTTP for a while now,
>>> hidden behind a flag, and seem to be rolling this out soon.
>>> 
>>> The topic is discussed in detail here:
>>> https://web.dev/samesite-cookies-explained/#changes-to-the-default-behavior-without-samesite
>>> 
>>> I just wondered if other developers had any thoughts on this move and
>>> if/when WebKit should follow. The downside is of course compatibility
>>> but the upside is improved privacy.
>>> ___
>>> 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 mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Terminology: Could we change 'roll out' to 'roll back'?

[Maciej Stachowiak]

I agree this usage of “roll out” is potentially confusing.

I think people say “roll out” for the symmetry to “check in”. It also creates 
the convenient term “roll back in” for when a rollout is undone.

Personally, I think we should say “revert” and avoid use of roll-phrases 
entirely. “unrevert” isn’t quite as natural as “roll back in”, but it’s good 
enough. Or you could say “re-land”.

Regards,
Maciej

> On Mar 6, 2020, at 6:14 PM, Kirsling, Ross  wrote:
> 
> Greetings WebKittens,
>  
> Late on Friday seems like a good time for a terminological debate (), so I’d 
> like to propose we revisit one of the strangest items of WebKit-specific 
> terminology: the phrase ‘roll out’.
>  
> In our industry, the typical meaning of the phrase ‘roll out’ is, of course, 
> ‘deploy’ or ‘launch’; this corresponds with the colloquial usage of ‘roll 
> out’ to mean ‘depart (for a destination)’. In WebKit, we use ‘roll out’ to 
> mean the exact opposite, ‘revert’ or ‘roll back’.
>  
> In terms of metaphors: The typical meaning of ‘roll out’ is synonymous with 
> ‘roll forward’, hence the opposite being ‘roll back’. The way that I came to 
> explain to myself and others what WebKit means by ‘roll out’ is that it’s 
> movement along the other axis. There is a tree (SVN trunk) which is built up 
> from disc-shaped slices (revisions), and these slices are rolled sideways in 
> and out of the tree. Needless to say, this is not obvious to a newcomer, and 
> it’s not even accurate to how SVN works—rollouts don’t remove an old 
> revision, they add a new revision to perform the revert!
>  
> This term is confusing enough for native English speakers outside our 
> community, let alone non-natives (since phrasal verbs are notoriously tricky 
> as it is). Having heard complaints about this from people in both of these 
> groups within the last few weeks, I hereby propose that we start using ‘roll 
> back’ instead. Given the string similarity between the two, I hope that this 
> will be a relatively easy change to enact, if folks are onboard with it.
>  
> Thanks for your consideration!
>  
> Ross
> ___
> 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] Same-Site cookies by default

[Maciej Stachowiak]

Current WebKit trunk blocks all third party cookies (with ITP enabled), which 
is a more extreme version of the same thing. We’re currently testing the 
compatibility fallout.

Treating cookies as SameSite=Lax by default is moot when third-party cookies 
are blocked, as the SameSite=None behavior would not be permitted at all.

Chromium has been just about to roll out their change for a while now, but my 
understanding is that it’s still only applied to a low percentage of users.

Regards,
Maciej

> On Mar 6, 2020, at 1:07 PM, Patrick Griffis  wrote:
> 
> Chromium has had the idea to treat all cookies as SameSite=Lax by
> default as well as blocking SameSite=None over HTTP for a while now,
> hidden behind a flag, and seem to be rolling this out soon.
> 
> The topic is discussed in detail here:
> https://web.dev/samesite-cookies-explained/#changes-to-the-default-behavior-without-samesite
> 
> I just wondered if other developers had any thoughts on this move and
> if/when WebKit should follow. The downside is of course compatibility
> but the upside is improved privacy.
> ___
> 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] Content-DPR: Image resolution optimization at CDN/transport layer

[Maciej Stachowiak]

> On Mar 2, 2020, at 11:22 PM, Noam Rosenthal  wrote:
> 
> 
> 
> On Mon, Nov 11, 2019 at 10:13 PM Maciej Stachowiak  <mailto:m...@apple.com>> wrote:
> 
> 
>> On Nov 11, 2019, at 4:37 AM, Noam Rosenthal > <mailto:n...@webkit.org>> wrote:
>> 
>> 
>> 
>> On Mon, Nov 11, 2019 at 12:13 AM Maciej Stachowiak > <mailto:m...@apple.com>> wrote:
>> - Is there a specification for Content-DPR? All I could find in bugzila and 
>> elsewhere is links to <https://httpwg.org/http-extensions/client-hints.html 
>> <https://httpwg.org/http-extensions/client-hints.html>>, which does not 
>> mention Content-DPR at all).
>> In a nutshell, the spec is in transition from IETF to HTML/fetch, and the 
>> client-hints aspects of it are still in progress (unlike conent-dpr, which 
>> is much simpler hasn't changed since introduced). It's documented here: 
>> https://github.com/yoavweiss/client-hints-infrastructure/blob/master/specification_situation.md
>>  
>> <https://github.com/yoavweiss/client-hints-infrastructure/blob/master/specification_situation.md>.
>> I will answer more about this separately if required, waiting for some info 
>> from the people working on the spec originally.
> 
> It looks like these are the relevant Pull Requests:
> 
> 
> HTML: https://github.com/whatwg/html/pull/3774 
> <https://github.com/whatwg/html/pull/3774> | 
> https://whatpr.org/fetch/773/6a644c6...5067615.html#concept-response-image-density
>  
> <https://whatpr.org/fetch/773/6a644c6...5067615.html#concept-response-image-density>
> Fetch: https://github.com/whatwg/fetch/pull/773 
> <https://github.com/whatwg/fetch/pull/773> | 
> https://whatpr.org/html/3774/e32a6f8...ddb0544/images.html#current-pixel-density
>  
> <https://whatpr.org/html/3774/e32a6f8...ddb0544/images.html#current-pixel-density>
> 
> It looks like these are in a somewhat messy state. For example, Fetch places 
> the Content-DPR value in an “image density” variable, but it doesn’t look 
> like the Pull Request to HTML doesn’t use it anywhere. As another example, 
> HTML directly references Content-DPR as setting the “current pixel density”, 
> but does not specify that it would take priority over a density derived from 
> srcset. There are also no diffs to CSS Images or to SVG, which provide 
> distinct ways to reference images and which presumably should respect 
> Content-DPR.
> 
>  
> 
>>  
>> - Can you give us some examples of how the CDN would make the decision of 
>> what density of image to serve without knowing the client’s DPR via  
>> client-hints? 
>>  Some examples from  https://github.com/eeeps/content-dpr-explainer 
>> <https://github.com/eeeps/content-dpr-explainer>:
>> - making decisions by user agent, like choosing to cap certain images for 
>> user-agents known to have smaller displays
>> - making decisions by traffic/geo, like serving lower-resolution images when 
>> traffic is bogged down
>> - A client may ask for "placeholder image" (e.g. ?placeholder=true in the 
>> URL), and the CDN would decide whether to serve a lower-quality JPEG or to 
>> scale it down, or do both.
> 
> These seem like reasonable use cases.
> 
>> 
>> - Is this presuming situations where the CDN serves the images but not the 
>> markup or CSS (which presumably could be rewritten to account for DPR)?
>> Correct.
>>  
>> - What happens if Content-DPR is provided, but the markup or CSS has 
>> conflicting explicit info? For example, > image.jpg 1x”>, and image-2x.jpg is served with a Content-DPR header of 3x. 
>> Or the analogous thing with CSS.
>> When image size is decided, css/markup takes precedence, then content DPR, 
>> and finally srcset-selection DPR. This is actually a bonus value of this 
>> feature - if the server happens to serve an image that differs from the 
>> ratio requested in the srcset tag, the intrinsic size match the served 
>> content and not the request (which is more of a recommendation).
>> 
>> - Does Content-DPR have any effect on images where an explicit size is 
>> provided, either in markup or in CSS? (I’m assuming no.)
>> No, it only has effect on intrinsic size. 
> 
> Overall, this seems like a feature with valid use cases. But unfortunately, 
> it’s a (currently) Blink-only feature with no clear specification. To the 
> extent there is a spec, it’s mixed in with multiple Pull Requests. These pull 
> requests mix in Client Hints, a feature unlikely to gain multi implementor 
> support, so they probably won’t land any time soon. And the language about 
> C

Re: [webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)

[Maciej Stachowiak]

> On Mar 3, 2020, at 12:44 AM, Noam Rosenthal  wrote:
> 
> 
> 
> On Tue, Mar 3, 2020 at 10:36 AM Ryosuke Niwa  > wrote:
> 
> By the way, do you know what the status / interests at Mozilla? Given 
> WebKit's painting / navigation behavior / implementation is still pretty 
> close to Blink, it would be a good idea to reach out to Mozilla to make sure 
> whatever in the spec is something they can also implement.
> 
> Mozilla have a bug open on this: 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1518999 
> , but unfortunately it 
> is not prioritized.
> Since they're mainly a desktop browser web developers currently don't 
> prioritize them for a performance metric. I hope that changes.

This explains a lot about the performance of desktop websites…

(Though in fairness, many mobile sites are not so great either).

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

Re: [webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)

[Maciej Stachowiak]

> On Mar 1, 2020, at 4:19 PM, Noam Rosenthal  wrote:
> 
> 
> 
> On Mon, Mar 2, 2020 at 1:18 AM Maciej Stachowiak  <mailto:m...@apple.com>> wrote:
> 
> 
>> On Mar 1, 2020, at 2:57 PM, Noam Rosenthal > <mailto:n...@webkit.org>> wrote:
>> 
>> 
>> 
>> On Mon, Mar 2, 2020 at 12:21 AM Maciej Stachowiak > <mailto:m...@apple.com>> wrote:
>> 
>> 
>>> On Mar 1, 2020, at 2:07 PM, Noam Rosenthal >> <mailto:n...@webkit.org>> wrote:
>>> 
>>> 
>>> The first visually non-empty milestone almost always happens way before 
>>> this point. The above is just a fallback to make sure we eventually hit 
>>> this milestone. For example, if a document is totally blank even after 
>>> loading the document and all subresources, we want to paint it instead of 
>>> waiting forever.
>>> 
>>> The visually non-empty heuristic is elsewhere.
>>> 
>>> Note that WebKit would consider the paint triggered by the above fallback 
>>> code to be both a first paint and “first visually non-empty paint” or 
>>> “first meaningful paint”, which somewhat corresponds to Chrome’s notion of 
>>> “first contentful paint”.
>>> 
>>> First paint can only happen earlier under even more unusual circumstances, 
>>> I believe there is a timeout after which we will paint even if all we can 
>>> paint is blank white or background color.
>>> 
>>>> 
>>>> But let's take the specifics to Slack/bugzilla?
>>> 
>>> I think it would be good for you to talk to people who understand WebKit’s 
>>> layout/paint milestones in detail before taking things to bugzilla. Ask on 
>>> Slack, and I’ll point you to the right people.
>>> Oops, just saw this, an initial (not for review) patch is already in 
>>> bugzilla :)
>>> But I'll continue the discussion - I have better idea of what to ask now.
>>> Who would be the right people to ask?
>> 
>> Alan, Simon, and Ryosuke should all know about this.
>> Awesomeness.
>>  
>> 
>> A few of us sat down and reviewed this spec. We think that, as written, the 
>> definition of “first contentful paint” is underspecified and in some cases 
>> buggy. For example, it says a “non-white canvas” should count as contentful. 
>> But canvases don’t start as white, they start as fully transparent black 
>> (all zeros). And checking the color of every pixel in a canvas is expensive. 
>> The intent here is probably that a canvas that has ever been painted into is 
>> contentful (or one that has been painted into more recently than the last 
>> time it was cleared).
>> Yes, I also thought that part of the spec was strange. I'll help revise it.
>> btw the FirstMeaningfulPaint in webkit doesn't look at canvas content at all 
>> - rather on the creation of a RenderCanvasElement... maybe being closer to 
>> the spec here would be better rendering-wise? Also, the current layout 
>> milestones doen't consider background images as "rendered pixels". Is that 
>> on purpose?
> 
> We think background images (and SVG, if not included yet) should count as 
> meaningful content. And canvases should probably be limited to non-empty ones.
> OK - that's more like the spec.
>  
> 
>>  
>> 
>> In any case, it definitely does not match the WebKit notion of first 
>> visually non-empty layout / first meaningful paint, in some cases in ways 
>> that we regret.
>> Regret, as in - it was better if the spec was closer to what webkit was 
>> doing?
> 
> No, I mean in some cases we think we should do what the spec says.
> 
>> I think it's OK if the spec's FCP and webkit's FMP are not the same, and if 
>> FCP is fired according to spec, and after the actual painting in webkit was 
>> done. 
> 
> I think we should try to align with the spec. Otherwise, because WebKit 
> usually won’t paint at all until webkit-FMP time, FCP won’t fire until that 
> time (since it is only fired when an actual paint happens).
>  
> 
>> 
>> Spec issues to follow.
>> 
>> We also think exposing “first paint” is harmful and we’d rather not 
>> implement it. We don’t agree that painting non-contentful content quickly is 
>> a good idea, either for browsers or for websites. And this API will 
>> inevitably be used to compare browsers, regardless of disclaimers that it 
>> shouldn’t be.
>> Harmful in the sense of comparing browsers? I don't think it can, regardless 
>> of disclaimers - since the hardware used for the browsers (at least on 
>&g

Re: [webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)

[Maciej Stachowiak]

> On Mar 1, 2020, at 2:57 PM, Noam Rosenthal  wrote:
> 
> 
> 
> On Mon, Mar 2, 2020 at 12:21 AM Maciej Stachowiak  <mailto:m...@apple.com>> wrote:
> 
> 
>> On Mar 1, 2020, at 2:07 PM, Noam Rosenthal > <mailto:n...@webkit.org>> wrote:
>> 
>> 
>> The first visually non-empty milestone almost always happens way before this 
>> point. The above is just a fallback to make sure we eventually hit this 
>> milestone. For example, if a document is totally blank even after loading 
>> the document and all subresources, we want to paint it instead of waiting 
>> forever.
>> 
>> The visually non-empty heuristic is elsewhere.
>> 
>> Note that WebKit would consider the paint triggered by the above fallback 
>> code to be both a first paint and “first visually non-empty paint” or “first 
>> meaningful paint”, which somewhat corresponds to Chrome’s notion of “first 
>> contentful paint”.
>> 
>> First paint can only happen earlier under even more unusual circumstances, I 
>> believe there is a timeout after which we will paint even if all we can 
>> paint is blank white or background color.
>> 
>>> 
>>> But let's take the specifics to Slack/bugzilla?
>> 
>> I think it would be good for you to talk to people who understand WebKit’s 
>> layout/paint milestones in detail before taking things to bugzilla. Ask on 
>> Slack, and I’ll point you to the right people.
>> Oops, just saw this, an initial (not for review) patch is already in 
>> bugzilla :)
>> But I'll continue the discussion - I have better idea of what to ask now.
>> Who would be the right people to ask?
> 
> Alan, Simon, and Ryosuke should all know about this.
> Awesomeness.
>  
> 
> A few of us sat down and reviewed this spec. We think that, as written, the 
> definition of “first contentful paint” is underspecified and in some cases 
> buggy. For example, it says a “non-white canvas” should count as contentful. 
> But canvases don’t start as white, they start as fully transparent black (all 
> zeros). And checking the color of every pixel in a canvas is expensive. The 
> intent here is probably that a canvas that has ever been painted into is 
> contentful (or one that has been painted into more recently than the last 
> time it was cleared).
> Yes, I also thought that part of the spec was strange. I'll help revise it.
> btw the FirstMeaningfulPaint in webkit doesn't look at canvas content at all 
> - rather on the creation of a RenderCanvasElement... maybe being closer to 
> the spec here would be better rendering-wise? Also, the current layout 
> milestones doen't consider background images as "rendered pixels". Is that on 
> purpose?

We think background images (and SVG, if not included yet) should count as 
meaningful content. And canvases should probably be limited to non-empty ones.

>  
> 
> In any case, it definitely does not match the WebKit notion of first visually 
> non-empty layout / first meaningful paint, in some cases in ways that we 
> regret.
> Regret, as in - it was better if the spec was closer to what webkit was doing?

No, I mean in some cases we think we should do what the spec says.

> I think it's OK if the spec's FCP and webkit's FMP are not the same, and if 
> FCP is fired according to spec, and after the actual painting in webkit was 
> done. 

I think we should try to align with the spec. Otherwise, because WebKit usually 
won’t paint at all until webkit-FMP time, FCP won’t fire until that time (since 
it is only fired when an actual paint happens).

> 
> Spec issues to follow.
> 
> We also think exposing “first paint” is harmful and we’d rather not implement 
> it. We don’t agree that painting non-contentful content quickly is a good 
> idea, either for browsers or for websites. And this API will inevitably be 
> used to compare browsers, regardless of disclaimers that it shouldn’t be.
> Harmful in the sense of comparing browsers? I don't think it can, regardless 
> of disclaimers - since the hardware used for the browsers (at least on 
> mobile) is vastly different, and also the networks. How about exposing a 
> prefixed entry? e.g. "-webkit-first-paint" - something that doesn't try to 
> seem comparable? The goal here is to help people optimize their site and make 
> sure it doesn't regress on webkit, rather than create meaningless 
> cross-browser comparisons... 

We will probably take up our complaint in the form of a spec issue. In the 
meantime, it would be nice if first paint was controlled by a separate flag.

> 
> In any case even having first-contentful-paint would be useful - with or 
> without first-paint.
> 
> 
> It’s probably unw

Re: [webkit-dev] Proposal: add Privacy to WebKit Project Goals

[Maciej Stachowiak]

New version, with Oxford comma everywhere. I didn’t add the use of “itself” 
because I don’t think the sentence is ambiguous as written, given the second 
clause. And if it is ambiguous, “itself” would not remove the ambiguity.

Below the diff, there’s the full text of the page as it would appear with these 
diffs applied (though without styling).



project-new.html
  WebKit is an open source Web content engine for browsers and other 
applications.
1212
1313
14 We value real-world web compatibility, standards compliance, stability, 
performance, security, portability, usability, and relative ease of 
understanding and modifying the code (hackability).
 14We value real-world web compatibility, standards compliance, stability, 
performance, battery life, security, privacy, portability, usability, and 
relative ease of understanding and modifying the code (hackability).
1515Project Goals
1616Web Content Engine
17 The project’s primary focus is content deployed on the World Wide Web, 
using standards-based technologies such as HTML, CSS, JavaScript and the DOM. 
However, we also want to make it possible to embed WebKit in other 
applications, and to use it as a general-purpose display and interaction 
engine.
 17The project’s primary focus is content deployed on the World Wide Web, 
using standards-based technologies such as HTML, CSS, JavaScript, and DOM. 
However, we also want to make it possible to embed WebKit in other 
applications, and to use it as a general-purpose display and interaction 
engine.
1818Open Source
19 WebKit should remain freely usable for both open source and proprietary 
applications. To that end, we use BSD-style and LGPL licenses. Specifically, we 
aim for licensing compatible with LGPL 2.1+. We do not currently plan to move 
to LGPL 3. In addition, we strive to create a courteous, welcoming environment 
that feels approachable to newcomers. WebKit maintains a public IRC chat room 
and a public mailing list where the ideas of contributors both new and old are 
heard and discussed with equal weight.
 19WebKit should remain freely usable for both open source and proprietary 
applications. To that end, we use BSD-style and LGPL licenses. Specifically, we 
aim for licensing compatible with LGPL 2.1+. We do not currently plan to move 
to LGPL 3. In addition, we strive to create a courteous, welcoming environment 
that feels approachable to newcomers. WebKit maintains a public chat room and a 
public mailing list where the ideas of contributors both new and old are heard 
and discussed with equal weight.
2020Compatibility
2121For users browsing the web, compatibility with their existing sites is 
essential. We strive to maintain and improve compatibility with existing web 
content, sometimes even at the expense of standards. We use regression testing 
to maintain our compatibility gains.
Standards Compliance
23 WebKit aims for compliance with relevant web standards, and support for 
new standards In addition to improving compliance, we participate in the web 
standards community to bring new technologies into standards, and to make sure 
new standards are practical to implement in our engine. We use regression 
testing to maintain our standards compliance gains.
 23WebKit aims for compliance with relevant web standards, and support for 
new standards. In addition to improving compliance, we participate in the web 
standards community to bring new technologies into standards, and to make sure 
new standards are practical to implement in our engine. We use regression 
testing to maintain our standards compliance gains.
2424Stability
25 The main WebKit code base should always maintain a high degree of 
stability. This means that crashes, hangs and regressions should be dealt with 
promptly, rather than letting them pile up.
 25The main WebKit code base should always maintain a high degree of 
stability. This means that crashes, hangs, and regressions should be dealt with 
promptly, rather than letting them pile up.
2626Performance
27 Maintaining and improving speed and memory use is an important goal. We 
never consider performance “good enough”, but strive to constantly improve. As 
web content becomes richer and more complex, and as web browsers run on more 
limited devices, performance gains continue to have value even if normal 
browsing seems fast enough.
 27Maintaining and improving speed, memory use, responsiveness, and 
consistent frame rate is an important goal. We never consider performance “good 
enough”, but strive to constantly improve. As web content becomes richer and 
more complex, and as web browsers run on more limited devices, performance 
gains continue to have value even if normal browsing seems fast enough.
 28Battery Life
 29In addition to traditional performance metrics, we aim to minimize power 
consumption to maximize browsing battery life for portable devices.
2830Security
2931Protecting users from security violations is critical. We fix security 
issues 

Re: [webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)

[Maciej Stachowiak]

> On Mar 1, 2020, at 2:07 PM, Noam Rosenthal  wrote:
> 
> 
> The first visually non-empty milestone almost always happens way before this 
> point. The above is just a fallback to make sure we eventually hit this 
> milestone. For example, if a document is totally blank even after loading the 
> document and all subresources, we want to paint it instead of waiting forever.
> 
> The visually non-empty heuristic is elsewhere.
> 
> Note that WebKit would consider the paint triggered by the above fallback 
> code to be both a first paint and “first visually non-empty paint” or “first 
> meaningful paint”, which somewhat corresponds to Chrome’s notion of “first 
> contentful paint”.
> 
> First paint can only happen earlier under even more unusual circumstances, I 
> believe there is a timeout after which we will paint even if all we can paint 
> is blank white or background color.
> 
>> 
>> But let's take the specifics to Slack/bugzilla?
> 
> I think it would be good for you to talk to people who understand WebKit’s 
> layout/paint milestones in detail before taking things to bugzilla. Ask on 
> Slack, and I’ll point you to the right people.
> Oops, just saw this, an initial (not for review) patch is already in bugzilla 
> :)
> But I'll continue the discussion - I have better idea of what to ask now.
> Who would be the right people to ask?

Alan, Simon, and Ryosuke should all know about this.

A few of us sat down and reviewed this spec. We think that, as written, the 
definition of “first contentful paint” is underspecified and in some cases 
buggy. For example, it says a “non-white canvas” should count as contentful. 
But canvases don’t start as white, they start as fully transparent black (all 
zeros). And checking the color of every pixel in a canvas is expensive. The 
intent here is probably that a canvas that has ever been painted into is 
contentful (or one that has been painted into more recently than the last time 
it was cleared).

In any case, it definitely does not match the WebKit notion of first visually 
non-empty layout / first meaningful paint, in some cases in ways that we regret.

Spec issues to follow.

We also think exposing “first paint” is harmful and we’d rather not implement 
it. We don’t agree that painting non-contentful content quickly is a good idea, 
either for browsers or for websites. And this API will inevitably be used to 
compare browsers, regardless of disclaimers that it shouldn’t be.

It’s probably unwise to implement this until the spec is fixed. And once it is, 
we should change our “first visually non-empty layout” notion to match it 
before exposing the corresponding paint timing milestone.

I think Ryosuke took notes on the spec issues we need to file.

Regards,
Maciej___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)

[Maciej Stachowiak]

> On Feb 27, 2020, at 3:41 AM, Noam Rosenthal  wrote:
> 
> 
> 
> On Thu, Feb 27, 2020 at 12:46 PM Noam Rosenthal  > wrote:
> 
> 
> On Thu, Feb 27, 2020 at 12:17 PM Yoav Weiss  > wrote:
> 
> 
> On Wed, Feb 26, 2020 at 11:33 PM Ryosuke Niwa  > wrote:
> 
> I don't think we should do that. For starters, Chrome's painting strategy 
> while loading a web page is very different from that of Safari / WebKit. We 
> would freeze the painting of the previous page at the moment a new navigation 
> is committed, and we wouldn't update the painting until the destination page 
> has a meaningful content in it. This is a very much different from Chrome's 
> model where the moment a new navigation is committed, Chrome will show a 
> blank page then start incrementally painting the page throughout the 
> navigation.
> Body background color is still painted before any contentful paint... Is this 
> a bug?
> Also, a web page might not have content at all (e.g. a bunch of divs with 
> bgcolors). Would webkit not render that web page at all? 
> 
> It seems like the code in FrameView does this:
> // Ensure that we always fire visually non-empty milestone eventually.
> if (finishedParsingMainDocument && frame().loader().isComplete())
> return true;
> 
> I suggest splitting this to two milestones - the current one, that triggers 
> when the main document finished loading, and another one that only triggers 
> when content has actually been painted (which may never happen). I think this 
> would be a good split for first-paint/first-contentful-paint in WebKit.

The first visually non-empty milestone almost always happens way before this 
point. The above is just a fallback to make sure we eventually hit this 
milestone. For example, if a document is totally blank even after loading the 
document and all subresources, we want to paint it instead of waiting forever.

The visually non-empty heuristic is elsewhere.

Note that WebKit would consider the paint triggered by the above fallback code 
to be both a first paint and “first visually non-empty paint” or “first 
meaningful paint”, which somewhat corresponds to Chrome’s notion of “first 
contentful paint”.

First paint can only happen earlier under even more unusual circumstances, I 
believe there is a timeout after which we will paint even if all we can paint 
is blank white or background color.

> 
> But let's take the specifics to Slack/bugzilla?

I think it would be good for you to talk to people who understand WebKit’s 
layout/paint milestones in detail before taking things to bugzilla. Ask on 
Slack, and I’ll point you to the right people.

> 
> ___
> 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] Proposal for an "intent to" process for web-exposed features

[Maciej Stachowiak]

I think we should have some structure, not just freeform emails. We can start 
with a simple template, but there’s some info that folks almost always want, so 
it’s easier if it’s included in the first place, rather than needing 
predictable follow-up questions

I also like having a title pattern, because that makes it easier to search 
email to find all things that fit the category.

Basically, since for any given feature email, there’s many potential readers 
and only one sender, so it seems reasonable to ask the sender to do a little 
extra 

I had some sample templates (much simpler than the ones used by Chrome) which I 
will dig out and send here.

> On Feb 26, 2020, at 11:08 PM, Ryosuke Niwa  wrote:
> 
> Thanks for starting this discussion.
> 
> On Wed, Feb 26, 2020 at 10:33 PM Frédéric Wang  > wrote:
> 
> The idea of an "intent to" process has been raised several times in the past 
> (e.g. in our 2020 goals [1]) and some people already use it informally, but 
> it does not seem that we have any agreement right now. Such a process would 
> help to coordinate changes internally (between port maintainers and 
> contributors) and externally (with standard groups, users and other 
> implementers). For the former point, see [2][3][4] for examples of how 
> coordination is not smooth right now. The latter point will give a better 
> understanding of what's happening in WebKit and help web developer advocacy.
> 
> Having some kind of a process to announce a new Web facing API or behavior 
> change is a good idea. In fact, we technically still have such a process 
> although nobody seems to be using these days: 
> https://trac.webkit.org/wiki/AddingFeatures 
> 
> 
> The Mozilla and Chromium projects have their own process [5] [6]. We can 
> probably start with minimal rules and refine them in the future. We can even 
> make it mandatory only for new web platform features developed under a 
> runtime preference for now (i.e. excluding small features for which it's not 
> worth introducing a flag, behavior changes or deprecation/removal). Below is 
> a proposal based on Mozilla's one.
> 
> WebKit tends to err on the side of simpler rules so let's stick with that. I 
> don't think we need an email template for example (I hate templates; all 
> those intent to X emails on other engines' mailing lists look so silly).
> 
> 1. Email webkit-dev with an intent to prototype.
> 
> I really dislike the idea of putting features into different stages like 
> prototyping, etc... I'd prefer a much simpler approach in which a new feature 
> or any behavior chance being worked on is announced on webkit-dev.
> 
> In fact, I don't think we should have any rule about how emails are titled, 
> etc... Emails just need to contain a certain set of information we need to 
> evaluate whether a given feature / behavior change is good or not.
> 
> Rather, what we need a guidance on is at which point something becomes a 
> feature or a behavior change significant enough that an announcement on 
> webkit-dev is necessary. For example, one could argue that any bug fix in Web 
> facing API will affect its behavior. However, I don't think we want to be 
> tracking every one of those behavior changes in WebKit on webkit-dev.
> 
> Similarly, adding a new API has multitude of scales. On one hand, there is 
> ResizeObserver and there is adding pointerLockElement on ShadowRoot 
> . At which point, should we 
> be making webkit-dev announcement. Again, I don't think we want to be 
> tracking the addition of every new DOM property, JS API, etc... on webkit-dev.

I personally think every web platform facing change should be announced, but 
it’s ok if some broader feature announcements cover every property and 
attribute in the spec at the time, even if they don’t land all at once. On the 
other hand, in specs like HTML or DOM, many individual new markup attributes or 
DOM properties are a feature in themselves.


> 
>  2. Implement the feature normally behind a off-by-default preference.
> 
> This is not a preference, it's a WebKit policy: 
> https://webkit.org/feature-policy/ 
I think he was using “preference” to mean “setting”, not to suggest that this 
is merely a preference and not required.

> 
> 3. Email webkit-dev with an intent to ship.
> 
> I don't think this makes much sense in WebKit since there is no such a thing 
> as shipping in WebKit. Each port maintainers decide which set of features 
> will be enabled at when.
> 
> Or do you mean that we enabling new feature / behavior by default? If so, 
> then making such an announcement on webkit-dev requirement for Web facing 
> feature / behavior change makes sense to me. But we should never use term 
> such as "shipping".
> 
> 4. If there's no negative feedback, ship (ports maintainer can still disable 
> the feature if they want to).
> 

Re: [webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)

[Maciej Stachowiak]

> On Feb 26, 2020, at 2:25 PM, Ryosuke Niwa  wrote:
> 
> 
> On Wed, Feb 26, 2020 at 11:29 AM Maciej Stachowiak  <mailto:m...@apple.com>> wrote:
> 
> 
>> On Feb 26, 2020, at 10:51 AM, Noam Rosenthal > <mailto:noam.j.rosent...@gmail.com>> wrote:
>> 
>> 
>> 
>> On Wed, Feb 26, 2020 at 8:08 PM Maciej Stachowiak > <mailto:m...@apple.com>> wrote:
>> 
>> Some quick comments: 
>> 
>> the definition of First Contentful Paint here in the spec: 
>> <https://www.w3.org/TR/paint-timing/#sec-terminology 
>> <https://www.w3.org/TR/paint-timing/#sec-terminology>> does not match the 
>> definition stated at <https://web.dev/first-contentful-paint/ 
>> <https://web.dev/first-contentful-paint/>>. The Chrome definition on web.dev 
>> <http://web.dev/> specifies that iframe content is not included, the spec 
>> does not have this limitation. Would an implementation that matches the spec 
>> match Chrome?
>> The draft version of the spec specifies that iframe content is not included 
>> in FCP:  https://w3c.github.io/paint-timing/#sec-reporting-paint-timing 
>> <https://w3c.github.io/paint-timing/#sec-reporting-paint-timing>, and has a 
>> few more comprehensive details about this. I think it's a good place to 
>> start.
>> 
>> I am also not sure this matches the layout milestones that already exist in 
>> non-Blink browser engines. Has this spec been implemented in Gecko, for 
>> example, to verity that it’s not exposing a concept that only exists in 
>> Blink?
>> No, this has not been implemented in Gecko, I'm tracking the bug on this: 
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1518999 
>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1518999>, there was some 
>> movement recently.
>> 
>> I suggest to start from "first-paint", and to try to match chrome as much as 
>> possible in how FCP is implemented, in the cases where the spec doesn't give 
>> enough detail, if such places exist. I think that for the main use-case of 
>> catching regressions for website code, it's ok (and almost unpreventable) if 
>> the implementations have some variances between them, what matters is that 
>> the metric is reliable for the particular browser. 
>> I also suggest to start with "first-paint" as it's perhaps a bit less 
>> "internal" than FCP, and can provide a performance-regression metric with a 
>> lesser degree of risk regarding exposing internals / privacy.
> 
> First paint that’s not first meaningful/contentful paint is not a very good 
> performance metric IMO. Who cares that a paint happened if it doesn’t have 
> any image or text content?
> 
> I also don’t think this exposes less. The privacy risk here is exposing 
> timing data that might be usable for fingerprinting.
> 
>>  
>> 
>> Chrome team themselves have been telling web developers that First 
>> Contentful Paint is deprecated in favor of Largest Contentful Paint. Should 
>> we concerned about this? It seems even harder to define LCP in an 
>> engine-independent way.
>> What was deprecated was "first meaningful paint" (FMP). FCP was not 
>> deprecated and has been in wide use for some time.
> 
> What’s the difference between First Meaningful and First Contentful?
> 
> There is no difference in Safari because we don't do any painting of a newly 
> navigated until the first meaningful paint happens.

WebKit’s notion of First Meaningful Paint is not the same as Chrome’s, from the 
sound of it. It sounds closer to Chrome’s First Contentful Paint, which makes 
no attempt to exclude sidebars or navigation bars or the like. (But it does 
exclude iframe).

> 
> - R. Niwa
> 
>> 
>> Finally, we should do a privacy review to consider whether exposing this 
>> info to webpages creates fingerprinting risk or otherwise exposes user data.
>> Great, what is needed for such review?
> 
> We will discuss with Apple’s privacy experts what they think of the privacy 
> risk. I’m just giving you a rain check for results of this discussion.
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> <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] WebKit position on Paint Timing / (first paint, first contentful paint)

[Maciej Stachowiak]

> On Feb 26, 2020, at 10:51 AM, Noam Rosenthal  
> wrote:
> 
> 
> 
> On Wed, Feb 26, 2020 at 8:08 PM Maciej Stachowiak  <mailto:m...@apple.com>> wrote:
> 
> Some quick comments: 
> 
> the definition of First Contentful Paint here in the spec: 
> <https://www.w3.org/TR/paint-timing/#sec-terminology 
> <https://www.w3.org/TR/paint-timing/#sec-terminology>> does not match the 
> definition stated at <https://web.dev/first-contentful-paint/ 
> <https://web.dev/first-contentful-paint/>>. The Chrome definition on web.dev 
> <http://web.dev/> specifies that iframe content is not included, the spec 
> does not have this limitation. Would an implementation that matches the spec 
> match Chrome?
> The draft version of the spec specifies that iframe content is not included 
> in FCP:  https://w3c.github.io/paint-timing/#sec-reporting-paint-timing 
> <https://w3c.github.io/paint-timing/#sec-reporting-paint-timing>, and has a 
> few more comprehensive details about this. I think it's a good place to start.
> 
> I am also not sure this matches the layout milestones that already exist in 
> non-Blink browser engines. Has this spec been implemented in Gecko, for 
> example, to verity that it’s not exposing a concept that only exists in Blink?
> No, this has not been implemented in Gecko, I'm tracking the bug on this: 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1518999 
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1518999>, there was some 
> movement recently.
> 
> I suggest to start from "first-paint", and to try to match chrome as much as 
> possible in how FCP is implemented, in the cases where the spec doesn't give 
> enough detail, if such places exist. I think that for the main use-case of 
> catching regressions for website code, it's ok (and almost unpreventable) if 
> the implementations have some variances between them, what matters is that 
> the metric is reliable for the particular browser. 
> I also suggest to start with "first-paint" as it's perhaps a bit less 
> "internal" than FCP, and can provide a performance-regression metric with a 
> lesser degree of risk regarding exposing internals / privacy.

First paint that’s not first meaningful/contentful paint is not a very good 
performance metric IMO. Who cares that a paint happened if it doesn’t have any 
image or text content?

I also don’t think this exposes less. The privacy risk here is exposing timing 
data that might be usable for fingerprinting.

>  
> 
> Chrome team themselves have been telling web developers that First Contentful 
> Paint is deprecated in favor of Largest Contentful Paint. Should we concerned 
> about this? It seems even harder to define LCP in an engine-independent way.
> What was deprecated was "first meaningful paint" (FMP). FCP was not 
> deprecated and has been in wide use for some time.

What’s the difference between First Meaningful and First Contentful?

>  
> 
> Finally, we should do a privacy review to consider whether exposing this info 
> to webpages creates fingerprinting risk or otherwise exposes user data.
> Great, what is needed for such review?

We will discuss with Apple’s privacy experts what they think of the privacy 
risk. I’m just giving you a rain check for results of this discussion.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)

[Maciej Stachowiak]

Some quick comments:

I am concerned that the definitions of these paint milestones have 
engine-dependent assumptions, and some may not be spelled out in the spec.

For example, the definition of First Contentful Paint here in the spec: 
 does not match the 
definition stated at . The Chrome 
definition on web.dev specifies that iframe content is not included, the spec 
does not have this limitation. Would an implementation that matches the spec 
match Chrome?

I am also not sure this matches the layout milestones that already exist in 
non-Blink browser engines. Has this spec been implemented in Gecko, for 
example, to verity that it’s not exposing a concept that only exists in Blink?

Chrome team themselves have been telling web developers that First Contentful 
Paint is deprecated in favor of Largest Contentful Paint. Should we concerned 
about this? It seems even harder to define LCP in an engine-independent way.

Finally, we should do a privacy review to consider whether exposing this info 
to webpages creates fingerprinting risk or otherwise exposes user data.

Regards,
Maciej

> On Feb 26, 2020, at 3:32 AM, Noam Rosenthal  wrote:
> 
> Hola
> I was approached by the Wikimedia foundation to implement the paint timing 
> API for WebKit (yay).
> I think this is a good feature to have for webkit, and I wanted to hear 
> thoughts about it before I begin.
> 
> The feature was enabled in Chrome for quite a while, and is potentially very 
> useful for real user monitoring to see if changes to the code of the website 
> create performance regressions on different browsers.
> We've been using it extensively (on Chrome) when I worked at Wix.com, and 
> always hoped that "some day" it will be available in other browsers.
> 
> I think it's a pretty lean spec and was stable since 2017, and that it fits 
> with the WebKit project goals, by allowing web developers to better optimize 
> their content and catch Safari/WebKit-specific regressions early.
> 
> I would like to get feedback on whether it's a desired feature for WebKit, if 
> there are caveats/pitfalls I should be thinking about, and anything else 
> that's worth mentioning at this point.
> 
> There are of course delicate decisions to be made as to the choice of timing 
> indicator, but I will get to that once we've sorted out the position in 
> general.
> 
> Bug: https://bugs.webkit.org/show_bug.cgi?id=78011 
> 
> Spec: https://www.w3.org/TR/paint-timing/ 
> 
> 
> Thanks!
> Noam
> ___
> 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] Proposal: add Privacy to WebKit Project Goals

[Maciej Stachowiak]

V2, with stronger privacy language.


project-new.html
  WebKit is an open source Web content engine for browsers and other 
applications.
1212
1313
14 We value real-world web compatibility, standards compliance, stability, 
performance, security, portability, usability, and relative ease of 
understanding and modifying the code (hackability).
 14We value real-world web compatibility, standards compliance, stability, 
performance, battery life, security, privacy, portability, usability, and 
relative ease of understanding and modifying the code (hackability).
1515Project Goals
1616Web Content Engine
17 The project’s primary focus is content deployed on the World Wide Web, 
using standards-based technologies such as HTML, CSS, JavaScript and the DOM. 
However, we also want to make it possible to embed WebKit in other 
applications, and to use it as a general-purpose display and interaction 
engine.
 17The project’s primary focus is content deployed on the World Wide Web, 
using standards-based technologies such as HTML, CSS, JavaScript and DOM. 
However, we also want to make it possible to embed WebKit in other 
applications, and to use it as a general-purpose display and interaction 
engine.
1818Open Source
1919WebKit should remain freely usable for both open source and proprietary 
applications. To that end, we use BSD-style and LGPL licenses. Specifically, we 
aim for licensing compatible with LGPL 2.1+. We do not currently plan to move 
to LGPL 3. In addition, we strive to create a courteous, welcoming environment 
that feels approachable to newcomers. WebKit maintains a public IRC chat room 
and a public mailing list where the ideas of contributors both new and old are 
heard and discussed with equal weight.
2020Compatibility

2424Stability
2525The main WebKit code base should always maintain a high degree of 
stability. This means that crashes, hangs and regressions should be dealt with 
promptly, rather than letting them pile up.
2626Performance
27 Maintaining and improving speed and memory use is an important goal. We 
never consider performance “good enough”, but strive to constantly improve. As 
web content becomes richer and more complex, and as web browsers run on more 
limited devices, performance gains continue to have value even if normal 
browsing seems fast enough.
 27Maintaining and improving speed and memory use is an important goal. We 
never consider performance “good enough”, but strive to constantly improve. As 
web content becomes richer and more complex, and as web browsers run on more 
limited devices, performance gains continue to have value even if normal 
browsing seems fast enough. We consider speed, memory use, responsiveness and 
frame rate to be important aspects of performance.
 28Battery Life
 29In addition to traditional performance metrics, we aim to minimize power 
consumption to maximize browsing battery life for portable devices.
2830Security
2931Protecting users from security violations is critical. We fix security 
issues promptly to protect users and maintain their trust.
 32Privacy
 33We believe privacy is a human right. WebKit code won't track the user or 
otherwise violate their privacy. And we will strive to prevent websites and 
other parties from doing so.
3034Portability
3135The WebKit project seeks to address a variety of needs. We want to make 
it reasonable to port WebKit to a variety of desktop, mobile, embedded and 
other platforms. We will provide the infrastructure to do this with tight 
platform integration, reusing native platform services where appropriate and 
providing friendly embedding APIs.
3236Usability___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for position on Badging API

[Maciej Stachowiak]

> On Feb 19, 2020, at 4:35 PM, Maciej Stachowiak  wrote:
> 
> 
> 
>> On Feb 19, 2020, at 4:31 PM, Matt Giuca > <mailto:mgi...@chromium.org>> wrote:
>> 
>> 
>> 
>> On Thu, 20 Feb 2020 at 11:18, Ryosuke Niwa > <mailto:rn...@webkit.org>> wrote:
>> 
>> On Wed, Feb 19, 2020 at 3:29 PM Matt Giuca > <mailto:mgi...@chromium.org>> wrote:
>> On Wed, 19 Feb 2020 at 18:14, Ryosuke Niwa > <mailto:rn...@webkit.org>> wrote:
>> 
>> On Tue, Feb 18, 2020 at 4:02 PM Matt Giuca > <mailto:mgi...@chromium.org>> wrote:
>> Thanks for the replies. Folding both Dean and Ryosuke's emails into one.
>> 
>> On Mon, 17 Feb 2020 at 03:03, Dean Jackson > <mailto:d...@apple.com>> wrote:
>> Not speaking for all of WebKit, and definitely not all of Apple, but I think 
>> this seems like a good idea.
>> 
>> I'm not sure I get the distinction between app badges and document badges 
>> though. I'd also like to see some specification text describing how the 
>> browser should ignore multiple set/clear operations executed in rapid 
>> succession (e.g. to create a blinking badge) - maybe the limit is one badge 
>> operation per minute or something?
>> 
>> Good suggestion. Filed an issue: https://github.com/WICG/badging/issues/68 
>> <https://github.com/WICG/badging/issues/68>
>> 
>> Also, given that the main use case for this would be alerting the user to a 
>> notification, it seems like it should be able to link it directly to that. 
>> This would provide the ability for a push notification to trigger the badge 
>> without ever firing up the page context.
>> 
>> I'm not sure what you mean by "link directly to that". We've deliberately 
>> specified this as separate to notifications (since you may or may not want 
>> the badge to be set without one). If you want to show a notification and a 
>> badge at the same time, you can use both APIs together. If you want to have 
>> a push notification set the badge when the service worker runs, you can do 
>> that (but as has been discussed at length: 
>> https://github.com/WICG/badging/issues/28 
>> <https://github.com/WICG/badging/issues/28>, you can't currently set a badge 
>> without a notification from a push message).
>> 
>> On Mon, 17 Feb 2020 at 03:49, Ryosuke Niwa > <mailto:rn...@webkit.org>> wrote:
>> For the record, we have two concerns raised internally at Apple:
>>  * The integration of this API with push service worker would require 
>> running scripts in order to update the badge. This will pose a serious power 
>> consumption issue.
>> 
>> That isn't a feature of the current proposal. The spec doesn't give service 
>> worker push any new capabilities that it didn't already have (in particular, 
>> if the browser requires the push message to show a notification, that is 
>> still true; you simply cannot set a badge from a push message without 
>> showing a notification). See https://github.com/WICG/badging/issues/28 
>> <https://github.com/WICG/badging/issues/28>and 
>> https://github.com/WICG/badging/blob/master/explainer.md#background-updates 
>> <https://github.com/WICG/badging/blob/master/explainer.md#background-updates>.
>> 
>> This is something we've given some thought to. We (Google) would like to 
>> eventually see it possible to set a badge in the background without a 
>> notification. But the power consumption and privacy issues are well known, 
>> and at this stage, it is not being proposed.
>> 
>> Because all background processes (including non-foreground tabs) are suspend 
>> on iOS, this makes this feature pretty much useless. If the user is 
>> currently seeing a website, then there is no need for updating the badge 
>> since the user is already there. On the other hand, if the user isn't 
>> currently seeing the website, then the website' scripts are never gonna run.
>> 
>> I see. So it sounds like this API would be useful but only once combined 
>> with a future proposal to let badges be set via push.
>>  
>> 
>>  * We don’t want every website to start using this API to increase 
>> “engagement”.
>> 
>> Do you mean as a way of drawing additional attention to itself? Well, the 
>> setAppBadge API can only be used by installed applications, so that doesn't 
>> apply to every site the user might visit. And the user agent / OS can 
>> provide the user with UI to suppress badges on a per-app basis if an app is 
>> too spammy. The setClientBadge API could be used by any website to draw 

Re: [webkit-dev] Request for position on Badging API

[Maciej Stachowiak]

> On Feb 19, 2020, at 4:31 PM, Matt Giuca  wrote:
> 
> 
> 
> On Thu, 20 Feb 2020 at 11:18, Ryosuke Niwa  > wrote:
> 
> On Wed, Feb 19, 2020 at 3:29 PM Matt Giuca  > wrote:
> On Wed, 19 Feb 2020 at 18:14, Ryosuke Niwa  > wrote:
> 
> On Tue, Feb 18, 2020 at 4:02 PM Matt Giuca  > wrote:
> Thanks for the replies. Folding both Dean and Ryosuke's emails into one.
> 
> On Mon, 17 Feb 2020 at 03:03, Dean Jackson  > wrote:
> Not speaking for all of WebKit, and definitely not all of Apple, but I think 
> this seems like a good idea.
> 
> I'm not sure I get the distinction between app badges and document badges 
> though. I'd also like to see some specification text describing how the 
> browser should ignore multiple set/clear operations executed in rapid 
> succession (e.g. to create a blinking badge) - maybe the limit is one badge 
> operation per minute or something?
> 
> Good suggestion. Filed an issue: https://github.com/WICG/badging/issues/68 
> 
> 
> Also, given that the main use case for this would be alerting the user to a 
> notification, it seems like it should be able to link it directly to that. 
> This would provide the ability for a push notification to trigger the badge 
> without ever firing up the page context.
> 
> I'm not sure what you mean by "link directly to that". We've deliberately 
> specified this as separate to notifications (since you may or may not want 
> the badge to be set without one). If you want to show a notification and a 
> badge at the same time, you can use both APIs together. If you want to have a 
> push notification set the badge when the service worker runs, you can do that 
> (but as has been discussed at length: 
> https://github.com/WICG/badging/issues/28 
> , you can't currently set a badge 
> without a notification from a push message).
> 
> On Mon, 17 Feb 2020 at 03:49, Ryosuke Niwa  > wrote:
> For the record, we have two concerns raised internally at Apple:
>  * The integration of this API with push service worker would require running 
> scripts in order to update the badge. This will pose a serious power 
> consumption issue.
> 
> That isn't a feature of the current proposal. The spec doesn't give service 
> worker push any new capabilities that it didn't already have (in particular, 
> if the browser requires the push message to show a notification, that is 
> still true; you simply cannot set a badge from a push message without showing 
> a notification). See https://github.com/WICG/badging/issues/28 
> and 
> https://github.com/WICG/badging/blob/master/explainer.md#background-updates 
> .
> 
> This is something we've given some thought to. We (Google) would like to 
> eventually see it possible to set a badge in the background without a 
> notification. But the power consumption and privacy issues are well known, 
> and at this stage, it is not being proposed.
> 
> Because all background processes (including non-foreground tabs) are suspend 
> on iOS, this makes this feature pretty much useless. If the user is currently 
> seeing a website, then there is no need for updating the badge since the user 
> is already there. On the other hand, if the user isn't currently seeing the 
> website, then the website' scripts are never gonna run.
> 
> I see. So it sounds like this API would be useful but only once combined with 
> a future proposal to let badges be set via push.
>  
> 
>  * We don’t want every website to start using this API to increase 
> “engagement”.
> 
> Do you mean as a way of drawing additional attention to itself? Well, the 
> setAppBadge API can only be used by installed applications, so that doesn't 
> apply to every site the user might visit. And the user agent / OS can provide 
> the user with UI to suppress badges on a per-app basis if an app is too 
> spammy. The setClientBadge API could be used by any website to draw 
> attention, but the user agent should make the badge sufficiently subtle that 
> this is no more abusive than a favicon, which can already be used to show a 
> pseudo-badge.
> 
> Since there is not a concept of installed web apps in Safari on macOS, this 
> isn't going to work there.
> 
> The setClientBadge API still makes sense on Safari on macOS.
> 
> It doesn't because we don't have a concept of installed apps, and we don't 
> want to let any website use this API as that may annoy users.
> 
> I just want to be clear about what setClientBadge is for. (And note that 
> nobody has implemented this yet; it's just in the draft spec as proposed by 
> Marcos Caceres from Firefox.)
> 
> This has nothing to do with installed apps. It's just about being able to 
> badge the 

Re: [webkit-dev] Note regarding wording of MacOS X on webkit.org

[Maciej Stachowiak]

The correct current spelling is macOS, please report any other places you know 
if that have an older or incorrect spelling.

> On Feb 18, 2020, at 9:50 AM, Oliver Propst  wrote:
> 
> 
> While this is not a major issue I have noticed that webkit.org makes several 
> references to "Mac OSX" while I assume the website just state "Mac OS". 
> See [0] and [1] for exemples.
> 
> 0 https://webkit.org/getting-started/
> 1 https://webkit.org/build-tools/
> 
> *I mention this because I think that Webkit as such a large and active 
> project should strive towards having correct and updated wording on its main 
> website.
> -- 
> -mvh Oliver Propst
> ___
> 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] Proposal: add Privacy to WebKit Project Goals

[Maciej Stachowiak]

> On Feb 16, 2020, at 8:43 PM, Brent Fulgham  wrote:
> 
> 
> 
>> On Feb 16, 2020, at 12:39 PM, Maciej Stachowiak > <mailto:m...@apple.com>> wrote:
>> 
>> 
>> There hasn’t been any feedback on this, so below is a proposed change (in 
>> PrettyPatch HTML format) to <https://webkit.org/project/ 
>> <https://webkit.org/project/>>.
>> 
>> In addition to adding Privacy as a goal, I also added Battery Life, and 
>> tweaked a few of the existing goals.
>> 
>> Thoughts?
>> 
>> 
>> project-new.html
>> 
>>  32Privacy
>>  33Users want their privacy respected. We avoid directly violating the 
>> user's privacy, and strive to prevent websites and other parties from doing 
>> so.
> 
> The term “directly violating” sounds a little soft. Do we not care about 
> indirect privacy violations?

My intent was to express that the browser engine itself will not spy on you, in 
addition to our measures to prevent websites from doing so. I’m not sure what 
you think would count as indirectly violating the users privacy which would not 
be websites or other parties violating the user’s privacy, but I’ll try to 
reword it.

> 
> I don’t know the right wording to use, but I would like to say something 
> along the lines of:
> 
> “Users want their privacy respected. We avoid violating the user’s privacy, 
> and strive to prevent websites and other parties form doing so, too. We view 
> the UserAgent’s primary responsibility to be protecting the interests of the 
> user. We therefore do not support or intend to implement web standards that 
> are at odds with these goals, or that create mechanisms to fingerprint or 
> otherwise monitor user behavior.”

This seems unnecessarily combative. Also perhaps not entirely true. There’s 
lots of fingerprinting surface in the web platform, and we have not removed all 
of it.

I’ll make an attempt to write this more clearly.

 - Maciej

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

Re: [webkit-dev] Proposal: add Privacy to WebKit Project Goals

[Maciej Stachowiak]

There hasn’t been any feedback on this, so below is a proposed change (in 
PrettyPatch HTML format) to .

In addition to adding Privacy as a goal, I also added Battery Life, and tweaked 
a few of the existing goals.

Thoughts?


project-new.html
  WebKit is an open source Web content engine for browsers and other 
applications.
1212
1313
14 We value real-world web compatibility, standards compliance, stability, 
performance, security, portability, usability, and relative ease of 
understanding and modifying the code (hackability).
 14We value real-world web compatibility, standards compliance, stability, 
performance, battery life, security, privacy, portability, usability, and 
relative ease of understanding and modifying the code (hackability).
1515Project Goals
1616Web Content Engine
17 The project’s primary focus is content deployed on the World Wide Web, 
using standards-based technologies such as HTML, CSS, JavaScript and the DOM. 
However, we also want to make it possible to embed WebKit in other 
applications, and to use it as a general-purpose display and interaction 
engine.
 17The project’s primary focus is content deployed on the World Wide Web, 
using standards-based technologies such as HTML, CSS, JavaScript and DOM. 
However, we also want to make it possible to embed WebKit in other 
applications, and to use it as a general-purpose display and interaction 
engine.
1818Open Source
1919WebKit should remain freely usable for both open source and proprietary 
applications. To that end, we use BSD-style and LGPL licenses. Specifically, we 
aim for licensing compatible with LGPL 2.1+. We do not currently plan to move 
to LGPL 3. In addition, we strive to create a courteous, welcoming environment 
that feels approachable to newcomers. WebKit maintains a public IRC chat room 
and a public mailing list where the ideas of contributors both new and old are 
heard and discussed with equal weight.
2020Compatibility

2424Stability
2525The main WebKit code base should always maintain a high degree of 
stability. This means that crashes, hangs and regressions should be dealt with 
promptly, rather than letting them pile up.
2626Performance
27 Maintaining and improving speed and memory use is an important goal. We 
never consider performance “good enough”, but strive to constantly improve. As 
web content becomes richer and more complex, and as web browsers run on more 
limited devices, performance gains continue to have value even if normal 
browsing seems fast enough.
 27Maintaining and improving speed and memory use is an important goal. We 
never consider performance “good enough”, but strive to constantly improve. As 
web content becomes richer and more complex, and as web browsers run on more 
limited devices, performance gains continue to have value even if normal 
browsing seems fast enough. We consider speed, memory use, responsiveness and 
frame rate to be important aspects of performance.
 28Battery Life
 29In addition to traditional performance metrics, we aim to minimize power 
consumption to maximize browsing battery life for portable devices.
2830Security
2931Protecting users from security violations is critical. We fix security 
issues promptly to protect users and maintain their trust.
 32Privacy
 33Users want their privacy respected. We avoid directly violating the 
user's privacy, and strive to prevent websites and other parties from doing 
so.
3034Portability
3135The WebKit project seeks to address a variety of needs. We want to make 
it reasonable to port WebKit to a variety of desktop, mobile, embedded and 
other platforms. We will provide the infrastructure to do this with tight 
platform integration, reusing native platform services where appropriate and 
providing friendly embedding APIs.
3236Usability___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Step 1 of Plugin removal: Deleting NPAPI (and thus Flash support)

[Maciej Stachowiak]

I discussed this some with Apple folks internally. Besides the PDF plugin 
mentioned by Dean, macOS apps using the WebKit API have the ability to embed 
NPAPI plugins in their app bundle and register them for WebView use. We are not 
sure if this is currently in use by any important apps, but we feel obligated 
to do some compatibility testing before we fully rip things out.

> On Feb 6, 2020, at 12:25 AM, Carlos Garcia Campos  wrote:
> 
> El mar, 14-01-2020 a las 05:06 +1100, Dean Jackson escribió:
>> 
>> 
>>> On 13 Jan 2020, at 20:14, Carlos Garcia Campos >>> wrote:
>>> 
>>> El lun, 13-01-2020 a las 05:30 +1100, Dean Jackson escribió:
 Dear Non-Apple ports,
 
 Running Flash has been more difficult over the past few years as
 part
 of a (semi-) coordinated effort by browsers and Adobe. The plan
 is to
 remove support for Flash + NPAPI by the end of this year. See the
 links below. 
 
 I'd like to remove our NPAPI code soon, but I want to make sure
 the
 other ports are ok with this. Please speak up if you have a
 reason to
 keep it in.
>>> 
>>> WPE has never supported NPAPI plugins and the GTK port removed the
>>> support for GTK2 plugins (flash) already in our current stable
>>> version.
>>> Plugins not using GTK at all (or using GTK3) are still supported by
>>> GTK
>>> port (some of them only under X11, though). I'm ok with removing
>>> the
>>> NPAPI plugins support in the GTk port, but we are at the end of the
>>> release cycle, so I prefer if we remove the feature right after we
>>> branch for the next stable version (scheduled for the 1st
>>> February). I
>>> could even branch earlier if needed.
>> 
>> Waiting until February is totally ok with me. Good luck with your
>> release.
> 
> We have already branched, so we can start removing NPAPI plugins from
> trunk :-)
> 
>> Dean
>> 
 [Note that we will still have some plugin code e.g. our internal
 PDFPlugin, just no support for externally installed plugins]
 
 Dean
 
 * Adobe's end of life for Flash - 
 https://theblog.adobe.com/adobe-flash-update/
 * Chrome removing Flash support by end of 2020 - 
 https://sites.google.com/a/chromium.org/dev/flash-roadmap
 * Google removing support for Flash by end of 2020 - 
 https://www.blog.google/products/chrome/saying-goodbye-flash-chrome/
 * Mozilla removing NPAPI by end of 2020 - 
 https://developer.mozilla.org/en-US/docs/Plugins/Roadmap
 * Mozilla only uses NPAPI for Flash - 
 https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
 
>>> 
>>> Thanks!
>>> 
>>> ___
>>> 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 mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Proposal: add Privacy to WebKit Project Goals

[Maciej Stachowiak]

I came across an old post that links this WebKit Project Goes page: 
https://webkit.org/project/  (it’s also linked 
from the webkit.org front page, though perhaps not many notice).

These goals, originally written in 2007, hold up surprisingly well in 2020. The 
most obvious omission is Privacy. I think we should add it. It seems clearly a 
project goal to protect user privacy, and it’s not really covered by the other 
goals. If folks agree, I’ll propose a diff.

While we’re at it, we could make other updates. Are there other worthwhile 
goals to add? Should we make changes to existing goals?

Regards,
Maciej



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

Re: [webkit-dev] WebKit position on Web NFC

[Maciej Stachowiak]

We oppose this feature and will not implement it.

We do not believe a permission prompt is a sufficient mitigation for the 
serious security and privacy risks raised by this specification. In addition, 
we think exposing direct hardware access to the web is a bad idea and 
compromises the device-independence of the web platform.

We can provide more details if desired but it may take a few days.

> On Jan 5, 2020, at 11:40 PM, François Beaufort   
> wrote:
> 
> Hello WebKit Dev folks,
> 
> Following Maciej's invitation to send requests for positions on Web API 
> proposals to webkit-dev, we would like to know WebKit's position on Web NFC: 
> https://w3c.github.io/web-nfc/ 
> 
> Web NFC aims to provide sites the ability to read and write to nearby NFC 
> devices. The current scope is limited to NDEF, a lightweight binary message 
> format. Low-level I/O operations with the ISO-DEP protocol and Host-based 
> Card Emulation (HCE) are not supported.
> 
> FYI, an intent to experiment will be posted soon on blink-dev.
> I'll update this webkit-dev thread with the URL when done.
> 
> TAG Review: https://github.com/w3ctag/design-reviews/issues/461 
> 
> Chromestatus URL: https://www.chromestatus.com/features/6261030015467520 
> 
> Mozilla standards-positions: 
> https://github.com/mozilla/standards-positions/issues/238 
> 
> 
> Thank you,
> Francois.
> ___
> 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] Feedback on Blink's text fragment directive proposal

[Maciej Stachowiak]

> On Dec 11, 2019, at 12:48 PM, Nick Burris  wrote:
> 
> Hi Maciej,
> Thanks for the reply! David's away this week, my responses are inline:
> (1) We’re concerned about compatibility issues in a world where some browsers 
> support this but not all. Aware browsers will strip `:~:`, but unaware 
> browsers won’t. I saw that on the blink-dev ItS thread, it was mentioned that 
> at least one site (webmd.com ) totally breaks if any 
> fragment ID is exposed to the page. This makes it difficult to create a link 
> that uses this feature but which is safe in all browsers:
>   - Since there is no feature detection mechanism, it’s hard for a 
> webpage to know whether it should issue such a link. It would have to be 
> based on UA string checks, which is regrettable.
>   - A link meant for a supporting browser can end up in a non-supporting 
> browser, at the very least by copy paste from the URL field, and perhaps 
> through other features to share a link. 
>  
> It seems like the spec doesn’t provide a solution for this. We think some 
> form of feature detection would slightly improve the situation. Other than 
> that, We're not sure how to avoid potential breakage. Maybe evangelize WebMD 
> if that’s the only major site that breaks on unexpected fragments?
> 
> There is a feature detection mechanism that we have 
> [specified](https://wicg.github.io/ScrollToTextFragment/#feature-detectability
>  ) and 
> implemented, see [#19](https://github.com/WICG/ScrollToTextFragment/issues/19 
> ). Feature detection 
> can be done by checking `typeof(window.location.fragmentDirective) == 
> 'object'`. Indeed, there is still a compat concern as described in the intent 
> to ship, since these links will exist in the wild. Since WebMD is the only 
> broken site we've come across, I agree it would be good to make sure they're 
> aware of this. I'll reach out.

Great. (Why only add it to the Location interface and not also URL?
> 
> (2) The portions of this Community Group report that monkey patch other 
> standards (HTML, URL and CSSOM View I think?) should be turned into PRs 
> against those specifications. Monkeypatching other specs is not a good way to 
> build specifications for the long term.
> 
> Agreed - we're wrapping up on some smaller remaining issues and our next step 
> is to turn this into PRs.

Glad to hear it.
> 
> (3) Text fragment trumping a regular fragment ID seems a bit strange. The 
> more natural semantic would be that the text search starts at the fragment, 
> so if there are multiple matches it’s possible to scroll to a more specific 
> one. It’s not clear why the fragment is instead entirely ignored.
> 
> We wanted to keep this simple to ensure links are robust (generally they will 
> be generated algorithmically, where one can ensure the text directive is 
> unique in the page). If we add the dimension of relying on starting at a 
> fragment, that fragment or the text could move in the page and break the 
> link, even if the desired text is still present on the page. Feel free to 
> open a Github issue if you think this is worth discussing more!
https://github.com/WICG/ScrollToTextFragment/issues/75


> 
> Thanks,
> Nick
> ___
> 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] WebKit position on Wake Lock API

[Maciej Stachowiak]

Is there a Blink Intent thread currently running on this or about to start?  
And do you happen to know if there is a Mozilla standards-positions issue on 
this? (We like to take into consideration whet the other browser engines are 
thinking.)


> On Dec 10, 2019, at 11:46 PM, Thomas Steiner  wrote:
> 
> Hello WebKit Dev,
> 
> Following Maciej's invitation to send requests for positions on API proposals 
> to this very mailing list, I would like to gauge WebKit's position on the 
> Wake Lock API: https://bugs.webkit.org/show_bug.cgi?id=205104 
> . Nota bene, this is an API 
> that is potentially useful for a "document web" even, not just an 
> "application web".
> 
> Thanks,
> Tom
> 
> ___
> 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] Feedback on Blink's text fragment directive proposal

[Maciej Stachowiak]

Hi David,

Apple folks have discussed this internally. In general, we think this is useful 
functionality to expose. Some points of feedback (let me know if any of these 
should be filed as an issue against the spec):

(1) We’re concerned about compatibility issues in a world where some browsers 
support this but not all. Aware browsers will strip `:~:`, but unaware browsers 
won’t. I saw that on the blink-dev ItS thread, it was mentioned that at least 
one site (webmd.com) totally breaks if any fragment ID is exposed to the page. 
This makes it difficult to create a link that uses this feature but which is 
safe in all browsers:
- Since there is no feature detection mechanism, it’s hard for a 
webpage to know whether it should issue such a link. It would have to be based 
on UA string checks, which is regrettable.
- A link meant for a supporting browser can end up in a non-supporting 
browser, at the very least by copy paste from the URL field, and perhaps 
through other features to share a link.

It seems like the spec doesn’t provide a solution for this. We think some form 
of feature detection would slightly improve the situation. Other than that, 
We're not sure how to avoid potential breakage. Maybe evangelize WebMD if 
that’s the only major site that breaks on unexpected fragments?

(2) The portions of this Community Group report that monkey patch other 
standards (HTML, URL and CSSOM View I think?) should be turned into PRs against 
those specifications. Monkeypatching other specs is not a good way to build 
specifications for the long term.

(3) Text fragment trumping a regular fragment ID seems a bit strange. The more 
natural semantic would be that the text search starts at the fragment, so if 
there are multiple matches it’s possible to scroll to a more specific one. It’s 
not clear why the fragment is instead entirely ignored.

We would frame these more as points of concern than opposition to the whole 
idea, but it seems wise to address them before shipping.

Regards,
Maciej


> On Dec 2, 2019, at 12:22 PM, David Bokan  wrote:
> 
> Hello webkit-dev,
> 
> I'd like to solicit feedback as well as an official position from Webkit on 
> our proposal for the text fragment directive: 
> https://github.com/WICG/ScrollToTextFragment 
> .
> 
> In summary: this is a feature that allows authors and users to craft URLs to 
> pages and specify a snippet of text on the page as a subresource (visually 
> highlighting it and scrolling it into view). Analogous to element-id based 
> fragment anchors but for text.
> 
> You can try this out today in Chrome Beta by enabling 
> chrome://flags/#enable-text-fragment-anchor. Here's an example link: <>
> 
> https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#:~:text=An%20optional%20fragment,element%20into%20view
>  
> 
> 
> Relevant Links:
> 
>  
> Explainer 
> Spec 
> TAG Review 
> (Currently Suspended) Blink Intent Thread 
> 
> Issue on Mozilla standards-positions 
> 
> 
> We've been using the GitHub repo for issue tracking but happy to take 
> feedback (official or otherwise) in any form.
> 
> Thank you!
> David
> ___
> 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] Safari Tech Preview 96 available on wpt.fyi!

[Maciej Stachowiak]

There’s a number of mysterious timeouts with 96. Not sure if flakiness or real?

The new WebCrypto failures are surprising, but likely real and should be 
investigated: 
https://wpt.fyi/results/WebCryptoAPI/wrapKey_unwrapKey?diff=ADC=is%3Adifferent_id=347530011_id=381930013
 


Many large new chunks of not-run tests are caused by a harness error or 
timeout. E.g. html/ and webauthn/


> On Nov 27, 2019, at 7:07 AM, Stephen Mcgruer  wrote:
> 
> Excited to announce that Safari Tech Preview 96 is now available on wpt.fyi 
> !
> 
> Example run: 
> https://wpt.fyi/results/?label=master=experimental=chrome=firefox=safari
>  
> 
> 
> Diff against Safari Tech Preview 95 (not at exactly the same WPT sha, but 
> very close): 
> https://wpt.fyi/results/?diff=ADC=is%3Adifferent_id=347530011_id=381930013
>  
> 
> 
> If you are surprised by the results in the diff view, I would love to hear 
> about it. One thing that surprised me is that the release blog post[0] 
> mentioned Web Animations being enabled by default, but we see no differences 
> in the test diff for web-animations/. It's possible we enable some flag that 
> turned on Web Animations already, but I can't see it obviously in our safari 
> setup[1].
> 
> [0]: 
> https://webkit.org/blog/9658/release-notes-for-safari-technology-preview-96/ 
> 
> [1]: 
> https://github.com/web-platform-tests/wpt/blob/master/tools/ci/azure/install_safari.yml
>  
> ___
> 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] Removing WebSQL support

[Maciej Stachowiak]

I tend to agree. Do any other ports want it? (Besides the small compatibility 
stub to avoid breaking metered paywalls.)

> On Nov 22, 2019, at 12:35 AM, Ryosuke Niwa  wrote:
> 
> Hi all,
> 
> It looks like we've successfully shipped iOS 13 and Safari 13 with WebSQL 
> disabled. I think it's time to remove the WebSQL support from WebKit entirely.
> 
> - R. Niwa
> 
> ___
> 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] WebKit team feedback on proposal to limit registerProtocolHandler API to secure contexts?

[Maciej Stachowiak]

Hi Eric,

Thanks for asking for our input. I’ve discussed this with experts on this area 
at Apple. WebKit does not currently support `registerProtocolHander` and likely 
will not. It’s a powerful capability, and hard to use sensibly in practice 
(except perhaps the `mailto:` scheme in particular). Even opening a URL with a 
custom URL scheme is a dangerous powerful capability that we’ve gated with a 
permission in Safari (in addition to banning specific extra-dangerous schemes). 
Apple’s Universal Links and Android App Links seem like a better technical 
solution for links that link sometimes to websites and sometimes to native apps.

All that said, if `registerProtocolHandler` is implemented at all, it seems 
better to limit it to secure contexts. It might be worth reviewing what schemes 
get registered to see if it’s possible to limit to a very short known-safe list.

Regards,
Maciej


> On Nov 20, 2019, at 9:12 AM, Eric Lawrence  wrote:
> 
> The Blink team has requested that I inquire whether the WebKit team has a 
> point-of-view about the upcoming change to limit HTML's 
> registerProtocolHandler API to use from secure contexts: 
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/1AOWqzgFQiw 
> .
>  This will disallow use of that API from non-secure (HTTP) contexts.
> 
> As I understand it, Safari does not implement the registerProtocolHandler 
> API. In the past, WebKit contained the IDL for the API in 
> (WebCore::NavigatorContentUtils::registerProtocolHandler),
> but this was removed earlier this year: 
> https://trac.webkit.org/changeset/243433/webkit 
> .
> 
> Would anyone from WebKit like to express support or objection to the Blink 
> I2I?
> ___
> 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] Content-DPR: Image resolution optimization at CDN/transport layer

[Maciej Stachowiak]

> On Nov 11, 2019, at 4:37 AM, Noam Rosenthal  wrote:
> 
> 
> 
> On Mon, Nov 11, 2019 at 12:13 AM Maciej Stachowiak  <mailto:m...@apple.com>> wrote:
> - Is there a specification for Content-DPR? All I could find in bugzila and 
> elsewhere is links to <https://httpwg.org/http-extensions/client-hints.html 
> <https://httpwg.org/http-extensions/client-hints.html>>, which does not 
> mention Content-DPR at all).
> In a nutshell, the spec is in transition from IETF to HTML/fetch, and the 
> client-hints aspects of it are still in progress (unlike conent-dpr, which is 
> much simpler hasn't changed since introduced). It's documented here: 
> https://github.com/yoavweiss/client-hints-infrastructure/blob/master/specification_situation.md
>  
> <https://github.com/yoavweiss/client-hints-infrastructure/blob/master/specification_situation.md>.
> I will answer more about this separately if required, waiting for some info 
> from the people working on the spec originally.

It looks like these are the relevant Pull Requests:


HTML: https://github.com/whatwg/html/pull/3774 | 
https://whatpr.org/fetch/773/6a644c6...5067615.html#concept-response-image-density
Fetch: https://github.com/whatwg/fetch/pull/773 | 
https://whatpr.org/html/3774/e32a6f8...ddb0544/images.html#current-pixel-density

It looks like these are in a somewhat messy state. For example, Fetch places 
the Content-DPR value in an “image density” variable, but it doesn’t look like 
the Pull Request to HTML doesn’t use it anywhere. As another example, HTML 
directly references Content-DPR as setting the “current pixel density”, but 
does not specify that it would take priority over a density derived from 
srcset. There are also no diffs to CSS Images or to SVG, which provide distinct 
ways to reference images and which presumably should respect Content-DPR.

>  
> - Can you give us some examples of how the CDN would make the decision of 
> what density of image to serve without knowing the client’s DPR via  
> client-hints? 
>  Some examples from  https://github.com/eeeps/content-dpr-explainer 
> <https://github.com/eeeps/content-dpr-explainer>:
> - making decisions by user agent, like choosing to cap certain images for 
> user-agents known to have smaller displays
> - making decisions by traffic/geo, like serving lower-resolution images when 
> traffic is bogged down
> - A client may ask for "placeholder image" (e.g. ?placeholder=true in the 
> URL), and the CDN would decide whether to serve a lower-quality JPEG or to 
> scale it down, or do both.

These seem like reasonable use cases.

> 
> - Is this presuming situations where the CDN serves the images but not the 
> markup or CSS (which presumably could be rewritten to account for DPR)?
> Correct.
>  
> - What happens if Content-DPR is provided, but the markup or CSS has 
> conflicting explicit info? For example,  image.jpg 1x”>, and image-2x.jpg is served with a Content-DPR header of 3x. 
> Or the analogous thing with CSS.
> When image size is decided, css/markup takes precedence, then content DPR, 
> and finally srcset-selection DPR. This is actually a bonus value of this 
> feature - if the server happens to serve an image that differs from the ratio 
> requested in the srcset tag, the intrinsic size match the served content and 
> not the request (which is more of a recommendation).
> 
> - Does Content-DPR have any effect on images where an explicit size is 
> provided, either in markup or in CSS? (I’m assuming no.)
> No, it only has effect on intrinsic size. 

Overall, this seems like a feature with valid use cases. But unfortunately, 
it’s a (currently) Blink-only feature with no clear specification. To the 
extent there is a spec, it’s mixed in with multiple Pull Requests. These pull 
requests mix in Client Hints, a feature unlikely to gain multi implementor 
support, so they probably won’t land any time soon. And the language about 
Content-DPR is broken and does not not seem to match Chrome’s actual 
implementation.

So in summary, there is no proper spec, and Chrome has shown willingness to 
have their implementation change faster than even draft spec language in PRs 
can keep up with.

Although the use case seems valid, I don’t think it’s a good idea for WebKit to 
implement the feature in this state. It seems likely to cause interop headaches 
and a need to reverse engineer Blink rather than developing against specs and 
test cases.

I would like to see a clean spec, either separating Content-DPR PRs from 
client-hints or making a standalone spec. And either way it should be fixed to 
match what Chrome has implemented, and have WPT tests that reflect the spec and 
intended behavior.

Regards,
Maciej




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

Re: [webkit-dev] Content-DPR: Image resolution optimization at CDN/transport layer

[Maciej Stachowiak]

> On Nov 10, 2019, at 2:13 PM, Maciej Stachowiak  wrote:
> 
> 
> 
>> On Nov 10, 2019, at 12:05 PM, Noam Rosenthal > <mailto:n...@webkit.org>> wrote:
>> 
>> 
>> 
>> On Sun, Nov 10, 2019 at 9:41 PM Maciej Stachowiak > <mailto:m...@apple.com>> wrote:
>> 
>> Is this header useful without the DPR client-hint?
>> Absolutely. 
>> A server/CDN can decide to serve an image with a particular content-dpr 
>> without knowing the client's actual DPR.
> 
> A few more questions (apologies if there are basic things that would be 
> explained by a spec somewhere).

Following up on one of these questions...

> 
> - Is there a specification for Content-DPR? All I could find in bugzila and 
> elsewhere is links to <https://httpwg.org/http-extensions/client-hints.html 
> <https://httpwg.org/http-extensions/client-hints.html>>, which does not 
> mention Content-DPR at all).

Looks like the ChangeLog links here: 
https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-06#section-3.1.1 
<https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-06#section-3.1.1> 
which is an expired Internet-Draft for Client Hints. The latest Internet-Draft 
(-07, as well was the in-progress -08) no longer mentions Content-DPR. Is there 
a new place where this is specified?

> - Can you give us some examples of how the CDN would make the decision of 
> what density of image to serve without knowing the client’s DPR via  
> client-hints? 
> - Is this presuming situations where the CDN serves the images but not the 
> markup or CSS (which presumably could be rewritten to account for DPR)?
> - What happens if Content-DPR is provided, but the markup or CSS has 
> conflicting explicit info? For example,  image.jpg 1x”>, and image-2x.jpg is served with a Content-DPR header of 3x. 
> Or the analogous thing with CSS.
> - Does Content-DPR have any effect on images where an explicit size is 
> provided, either in markup or in CSS? (I’m assuming no.)
> 
> Cheers,
> Maciej
> 
> 
>> 
>> 
>>> On Nov 10, 2019, at 1:16 AM, Noam Rosenthal >> <mailto:n...@webkit.org>> wrote:
>>> 
>>> Hola
>>> 
>>> I would like to open a discussion that has started a few years back and has 
>>> never reached a consensus: https://bugs.webkit.org/show_bug.cgi?id=145380 
>>> <https://bugs.webkit.org/show_bug.cgi?id=145380>
>>> 
>>> In a nutshell: content-dpr is a response-only header for images, that 
>>> allows servers at transient layers (CDNs/proxies) to optimize images by 
>>> changing their resolution, allowing the user agents to compensate for the 
>>> change in intrinsic size caused by the resolution change - thus making the 
>>> resolution change transparent to users. It's the header that makes the 
>>> resolution-encoding transparent.
>>> 
>>> The feature is already up and running in chrome since version 67, and is 
>>> used by some CDNs.
>>> 
>>> Since there was lack of consensus in the bug discussion, I wanted to make 
>>> the case for it here, and see if opinions about the subject can be voiced 
>>> before we reach a decision/consensus. I tried to find a good balance 
>>> between being detailed and being concise. 
>>> 
>>> —
>>> 
>>> Players in CDN, proxy and other transient parts of the internet world have 
>>> innovated a lot in the past few years. There are lots of interesting 
>>> companies and competition there. One of the areas of this innovation is in 
>>> optimizing images in a transparent way at transient layers (proxy/CDN). 
>>> This makes a lot of sense considering how much of internet traffic is taken 
>>> by image download.
>>> 
>>> What the research at the CDN companies found, was that modifying resolution 
>>> at the transient layer can have a tremendous effect on 
>>> performance/user-experience balance, for example by serving 
>>> lower-resolution versions of the images when network traffic is costly/slow 
>>> (the exact formula for that is part of where the CDN can innovate). More 
>>> details on that innovation in the links below.
>>> 
>>> The thing is, that modifying image resolution at the CDN/proxy is not 
>>> inherently transparent, due to one reason - layout is affected by the 
>>> image’s intrinsic size, and changing the image’s resolution inadvertently 
>>> changes the image’s intrinsic size. To make this transparent, the user 
>>> agent has to be involved, to compensate for this optimization when reading 
>>> the

Re: [webkit-dev] Content-DPR: Image resolution optimization at CDN/transport layer

[Maciej Stachowiak]

> On Nov 10, 2019, at 12:05 PM, Noam Rosenthal  wrote:
> 
> 
> 
> On Sun, Nov 10, 2019 at 9:41 PM Maciej Stachowiak  <mailto:m...@apple.com>> wrote:
> 
> Is this header useful without the DPR client-hint?
> Absolutely. 
> A server/CDN can decide to serve an image with a particular content-dpr 
> without knowing the client's actual DPR.

A few more questions (apologies if there are basic things that would be 
explained by a spec somewhere).

- Is there a specification for Content-DPR? All I could find in bugzila and 
elsewhere is links to <https://httpwg.org/http-extensions/client-hints.html 
<https://httpwg.org/http-extensions/client-hints.html>>, which does not mention 
Content-DPR at all).
- Can you give us some examples of how the CDN would make the decision of what 
density of image to serve without knowing the client’s DPR via  client-hints? 
- Is this presuming situations where the CDN serves the images but not the 
markup or CSS (which presumably could be rewritten to account for DPR)?
- What happens if Content-DPR is provided, but the markup or CSS has 
conflicting explicit info? For example, , and image-2x.jpg is served with a Content-DPR header of 3x. Or the 
analogous thing with CSS.
- Does Content-DPR have any effect on images where an explicit size is 
provided, either in markup or in CSS? (I’m assuming no.)

Cheers,
Maciej


> 
> 
>> On Nov 10, 2019, at 1:16 AM, Noam Rosenthal > <mailto:n...@webkit.org>> wrote:
>> 
>> Hola
>> 
>> I would like to open a discussion that has started a few years back and has 
>> never reached a consensus: https://bugs.webkit.org/show_bug.cgi?id=145380 
>> <https://bugs.webkit.org/show_bug.cgi?id=145380>
>> 
>> In a nutshell: content-dpr is a response-only header for images, that allows 
>> servers at transient layers (CDNs/proxies) to optimize images by changing 
>> their resolution, allowing the user agents to compensate for the change in 
>> intrinsic size caused by the resolution change - thus making the resolution 
>> change transparent to users. It's the header that makes the 
>> resolution-encoding transparent.
>> 
>> The feature is already up and running in chrome since version 67, and is 
>> used by some CDNs.
>> 
>> Since there was lack of consensus in the bug discussion, I wanted to make 
>> the case for it here, and see if opinions about the subject can be voiced 
>> before we reach a decision/consensus. I tried to find a good balance between 
>> being detailed and being concise. 
>> 
>> —
>> 
>> Players in CDN, proxy and other transient parts of the internet world have 
>> innovated a lot in the past few years. There are lots of interesting 
>> companies and competition there. One of the areas of this innovation is in 
>> optimizing images in a transparent way at transient layers (proxy/CDN). This 
>> makes a lot of sense considering how much of internet traffic is taken by 
>> image download.
>> 
>> What the research at the CDN companies found, was that modifying resolution 
>> at the transient layer can have a tremendous effect on 
>> performance/user-experience balance, for example by serving lower-resolution 
>> versions of the images when network traffic is costly/slow (the exact 
>> formula for that is part of where the CDN can innovate). More details on 
>> that innovation in the links below.
>> 
>> The thing is, that modifying image resolution at the CDN/proxy is not 
>> inherently transparent, due to one reason - layout is affected by the 
>> image’s intrinsic size, and changing the image’s resolution inadvertently 
>> changes the image’s intrinsic size. To make this transparent, the user agent 
>> has to be involved, to compensate for this optimization when reading the 
>> image’s intrinsic size.
>> 
>> The main case against this feature was that image resolution is a feature 
>> that should be handled at the markup layer and not at the transport layer 
>> (https://bugs.webkit.org/show_bug.cgi?id=145380#c7 
>> <https://bugs.webkit.org/show_bug.cgi?id=145380#c7>).
>> I would argue that http-headers are not a transport layer (TCP/UDP etc.), 
>> but rather part of an application-layer protocol that is designed, in part, 
>> to pass information to the transient layers such as CDNs, and that 
>> resolution compression is a (new, image-specific) equivalent of 
>> transfer-encoding. 
>> 
>> Also, as a response to the view that this should be part of markup, I would 
>> argue that those transparent decisions by the servers should not concern web 
>> authors at all. It’s an optimization decision to be handled by

Re: [webkit-dev] Content-DPR: Image resolution optimization at CDN/transport layer

[Maciej Stachowiak]

Is this header useful without the DPR client-hint?

> On Nov 10, 2019, at 1:16 AM, Noam Rosenthal  wrote:
> 
> Hola
> 
> I would like to open a discussion that has started a few years back and has 
> never reached a consensus: https://bugs.webkit.org/show_bug.cgi?id=145380 
> 
> 
> In a nutshell: content-dpr is a response-only header for images, that allows 
> servers at transient layers (CDNs/proxies) to optimize images by changing 
> their resolution, allowing the user agents to compensate for the change in 
> intrinsic size caused by the resolution change - thus making the resolution 
> change transparent to users. It's the header that makes the 
> resolution-encoding transparent.
> 
> The feature is already up and running in chrome since version 67, and is used 
> by some CDNs.
> 
> Since there was lack of consensus in the bug discussion, I wanted to make the 
> case for it here, and see if opinions about the subject can be voiced before 
> we reach a decision/consensus. I tried to find a good balance between being 
> detailed and being concise. 
> 
> —
> 
> Players in CDN, proxy and other transient parts of the internet world have 
> innovated a lot in the past few years. There are lots of interesting 
> companies and competition there. One of the areas of this innovation is in 
> optimizing images in a transparent way at transient layers (proxy/CDN). This 
> makes a lot of sense considering how much of internet traffic is taken by 
> image download.
> 
> What the research at the CDN companies found, was that modifying resolution 
> at the transient layer can have a tremendous effect on 
> performance/user-experience balance, for example by serving lower-resolution 
> versions of the images when network traffic is costly/slow (the exact formula 
> for that is part of where the CDN can innovate). More details on that 
> innovation in the links below.
> 
> The thing is, that modifying image resolution at the CDN/proxy is not 
> inherently transparent, due to one reason - layout is affected by the image’s 
> intrinsic size, and changing the image’s resolution inadvertently changes the 
> image’s intrinsic size. To make this transparent, the user agent has to be 
> involved, to compensate for this optimization when reading the image’s 
> intrinsic size.
> 
> The main case against this feature was that image resolution is a feature 
> that should be handled at the markup layer and not at the transport layer 
> (https://bugs.webkit.org/show_bug.cgi?id=145380#c7 
> ).
> I would argue that http-headers are not a transport layer (TCP/UDP etc.), but 
> rather part of an application-layer protocol that is designed, in part, to 
> pass information to the transient layers such as CDNs, and that resolution 
> compression is a (new, image-specific) equivalent of transfer-encoding. 
> 
> Also, as a response to the view that this should be part of markup, I would 
> argue that those transparent decisions by the servers should not concern web 
> authors at all. It’s an optimization decision to be handled by the servers, 
> with the user agent doing nothing about it but allow that decision to be 
> transparent in terms of layout (the same way gzip and cache-control are 
> transparent).
> 
> What is offered here is a win-win in terms of delivering images, and would 
> allow webkit-browser users to enjoy some of the innovations in the image 
> delivery world without modifying their HTML content and without concern of 
> breaking their layouts. Less battery and data used for downloading big images 
> at certain situations, for example.
> 
> I hope this provides enough background without being too tedious. I would be 
> happy to shed more light on whatever is missing in this longish essay :)
> 
> Additional info:
> https://github.com/eeeps/content-dpr-explainer 
> 
> https://cloudinary.com/blog/client_hints_and_responsive_images_what_changed_in_chrome_67
>  
> 
> https://www.chromestatus.com/metrics/feature/timeline/popularity/906 
> ___
> 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] EWS Comments on Bugzilla (Was: EWS now parses error logs in case of build failure)

[Maciej Stachowiak]

I think they are useful to actual and potential reviewers. Direct email to the 
patch author is not something anyone can Cc themselves on, and is not archived, 
so seems like a strictly worse form of communication.

> On Nov 2, 2019, at 9:34 AM, Alexey Proskuryakov  wrote:
> 
> 
> My preference is still e-mailing the patch author directly (possibly, also 
> having an option to opt in for anyone). Bugzilla comments will always be 
> irrelevant for most people CC'ed on the bug, and they are almost always 
> undesirable to keep within the discussion flow.
> 
> - Alexey
> 
>> 1 нояб. 2019 г., в 18:28, Aakash Jain  написал(а):
>> 
>> Sounds good. I prefer the single comment when the first failure occur. That 
>> way notification would be sent as soon as the first failure happens.
>> 
>> I'll implement that (assuming it's acceptable to everyone).
>> 
>> Thanks
>> Aakash
>> 
>>> On Nov 1, 2019, at 8:35 PM, Maciej Stachowiak  wrote:
>>> 
>>> 
>>> How about only a single comment when the first failure occurs? (Or else 
>>> when all bots pass, if there is never a failure.)
>>> 
>>> This should help the author, the reviewer, and anyone else cc’d, without 
>>> being too spammy.
>>> 
>>>> On Nov 1, 2019, at 5:20 PM, Aakash Jain  wrote:
>>>> 
>>>> Hi Ryosuke,
>>>> 
>>>> Many people didn't like the noise by the EWS comments, and we removed the 
>>>> comments as per previous discussion in: 
>>>> https://lists.webkit.org/pipermail/webkit-dev/2019-June/030683.html.
>>>> 
>>>> I agree with your point that having some kind of notification might be 
>>>> useful.
>>>> 
>>>> I proposed some ideas in 
>>>> https://lists.webkit.org/pipermail/webkit-dev/2019-September/030798.html, 
>>>> but didn't get much feedback. If we can all agree on a solution, I can 
>>>> look into implementing it.
>>>> 
>>>> Thanks
>>>> Aakash
>>>> 
>>>>> On Oct 30, 2019, at 1:03 AM, Ryosuke Niwa  wrote:
>>>>> 
>>>>> These enhancements are great. There is one feature of the old EWS that I 
>>>>> really miss, which is that I used to get emails when some EWS failed. 
>>>>> With new EWS, I have to keep checking back the bugzilla to see if any of 
>>>>> them have failed periodically.
>>>>> 
>>>>> Can we add a feature to opt into such an email notification? Maybe a flag 
>>>>> on a patch or JSON configuration file somewhere.
>>>>> 
>>>>> - R. Niwa
>>>>> 
>>>>> On Tue, Oct 29, 2019 at 4:05 PM Aakash Jain  wrote:
>>>>> Hi Everyone,
>>>>> 
>>>>> I am happy to announce another EWS feature.
>>>>> 
>>>>> From now on, in case of build failure, EWS will parse the errors and 
>>>>> display them in a separate 'errors' log. You wouldn't have to search 
>>>>> through thousands of lines of logs to find the error message.
>>>>> 
>>>>> For example, in https://ews-build.webkit.org/#/builders/16/builds/6054, 
>>>>> in step #7 WebKit failed to compile. Complete logs (stdio) are 38,000+ 
>>>>> lines, and the error is not at the end of the logs. Normally, it requires 
>>>>> some searching through the logs to find the relevant errors. But now, 
>>>>> there is another 'errors' log, which contains just the relevant 11 lines 
>>>>> (containing error and few related lines to provide additional context).
>>>>> 
>>>>> Hopefully this would save some time and efforts previously spent on 
>>>>> searching through the large logs.
>>>>> 
>>>>> Note that this information is not displayed in status-bubble tool-tip, 
>>>>> since this might be lot of text to display in the tooltip. My further 
>>>>> plan is to make this information more readily available, by adding it to 
>>>>> a custom designed page which will open on clicking the status bubble 
>>>>> https://webkit.org/b/197522
>>>>> 
>>>>> Please let me know if you notice any issues or have any feedback.
>>>>> 
>>>>> Thanks
>>>>> Aakash
>>>>> 
>>>>> Reference: https://webkit.org/b/203418
>>>>> ___
>>>>> webkit-dev mailing list
>>>>> webkit-dev@lists.webkit.org
>>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>>> -- 
>>>>> - R. Niwa
>>>> 
>>>> ___
>>>> 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
> 
> - Alexey
> 

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

Re: [webkit-dev] EWS Comments on Bugzilla (Was: EWS now parses error logs in case of build failure)

[Maciej Stachowiak]

How about only a single comment when the first failure occurs? (Or else when 
all bots pass, if there is never a failure.)

This should help the author, the reviewer, and anyone else cc’d, without being 
too spammy.

> On Nov 1, 2019, at 5:20 PM, Aakash Jain  wrote:
> 
> Hi Ryosuke,
> 
> Many people didn't like the noise by the EWS comments, and we removed the 
> comments as per previous discussion in: 
> https://lists.webkit.org/pipermail/webkit-dev/2019-June/030683.html.
> 
> I agree with your point that having some kind of notification might be useful.
> 
> I proposed some ideas in 
> https://lists.webkit.org/pipermail/webkit-dev/2019-September/030798.html, but 
> didn't get much feedback. If we can all agree on a solution, I can look into 
> implementing it.
> 
> Thanks
> Aakash
> 
>> On Oct 30, 2019, at 1:03 AM, Ryosuke Niwa  wrote:
>> 
>> These enhancements are great. There is one feature of the old EWS that I 
>> really miss, which is that I used to get emails when some EWS failed. With 
>> new EWS, I have to keep checking back the bugzilla to see if any of them 
>> have failed periodically.
>> 
>> Can we add a feature to opt into such an email notification? Maybe a flag on 
>> a patch or JSON configuration file somewhere.
>> 
>> - R. Niwa
>> 
>> On Tue, Oct 29, 2019 at 4:05 PM Aakash Jain  wrote:
>> Hi Everyone,
>> 
>> I am happy to announce another EWS feature.
>> 
>> From now on, in case of build failure, EWS will parse the errors and display 
>> them in a separate 'errors' log. You wouldn't have to search through 
>> thousands of lines of logs to find the error message.
>> 
>> For example, in https://ews-build.webkit.org/#/builders/16/builds/6054, in 
>> step #7 WebKit failed to compile. Complete logs (stdio) are 38,000+ lines, 
>> and the error is not at the end of the logs. Normally, it requires some 
>> searching through the logs to find the relevant errors. But now, there is 
>> another 'errors' log, which contains just the relevant 11 lines (containing 
>> error and few related lines to provide additional context).
>> 
>> Hopefully this would save some time and efforts previously spent on 
>> searching through the large logs.
>> 
>> Note that this information is not displayed in status-bubble tool-tip, since 
>> this might be lot of text to display in the tooltip. My further plan is to 
>> make this information more readily available, by adding it to a custom 
>> designed page which will open on clicking the status bubble 
>> https://webkit.org/b/197522
>> 
>> Please let me know if you notice any issues or have any feedback.
>> 
>> Thanks
>> Aakash
>> 
>> Reference: https://webkit.org/b/203418
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> -- 
>> - R. Niwa
> 
> ___
> 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] Lazy loading

[Maciej Stachowiak]

> On Oct 28, 2019, at 3:08 PM, Rob Buis  wrote:
> 
> On 10/28/19 9:07 PM, Maciej Stachowiak wrote:
> 
>>> Yet another possible task is making lazy loading work for CSS backgrounds, 
>>> this is implemented in the prototype but I don't think there are many tests 
>>> for it.
>> Is there a way for content authors to opt in/out (depending on the default), 
>> or does this just always follow what the default lazy loading setting is?
> 
> From reading the chromium code, it seems to use a combination of feature 
> policy and the loading attribute to decide whether to enable CSS backgrounds 
> lazy loading or not. Hopefully a chromium developer can confirm.

Per the PR for lazy loading[1], the `loading` attribute applies only to `` 
and `` elements. Most CSS background images are not on either of these 
specific elements. I can imagine one of the following:

- Chromium has a nonstandard extension beyond what is in the PR to make 
`loading` a global/superglobal attribute (in which case we probably shouldn’t 
implement that until spec’d)
- The attribute only applies to CSS backgrounds on specifically the `` and 
`` elements, which would be weirdly limited, and also would be a 
nonstandard extension to the PR
- CSS backgrounds (and other CSS images?) don’t have an individual override, 
only the global override via Feature Policy.

This raises two further concerns though:
- Lazy loading for CSS images is not specified in the lazy loading PR[1]. Is it 
specified elsewhere, or is it a nonstandard Chromium extension?
- I couldn’t find a spec for a lazy loading feature policy either, and the 
Chrome Platform Status page for it gives the status as “removed”[2] so this too 
might be a nonstandard thing. Or maybe there is a newer  (Doesn’t look like the 
feature policy aspect is in your patch though.)

I hope I am not being too nitpicky. I do think this is a great feature. I just 
want to make sure we’re cautious about the line between implementing 
standards-track stuff vs copying things from Chromium that are nonstandard or 
unspecified (so far).

It’s also really worrisome if Chrome implemented semantics for the “loading” 
attribute beyond what is in the PR, as that will make interop a challenge.

Regards,
Maciej

[1] <https://github.com/whatwg/html/pull/3752>
[2] <https://www.chromestatus.com/feature/5641405942726656>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Lazy loading

[Maciej Stachowiak]

> On Oct 28, 2019, at 11:39 AM, Rob Buis  wrote:
> 
> Hi,
> 
> I made a lazy image loading prototype earlier this year 
> (https://bugs.webkit.org/show_bug.cgi?id=196698) and have been splitting it 
> up into reviewable patches. The main implementation part landed recently so I 
> am wondering about the next steps.
> 
> One thing left to do for sure is cleaning up/adding tests. For one there are 
> tests in http/tests/lazyload which can just be WPT tests, so I'll work in 
> this area for sure. As usual, while adding new tests bugs may show up and 
> more patches will be needed.
> 
> Another possible task is implementing metadata fetch, but it makes the code 
> more complex and chromium has backtracked from it.
> 
> Changing the behavior of loading=auto to make lazy loading the default seems 
> risky and should possibly only be done when lazy image loading is deemed 
> stable enough.
> 
> Yet another possible task is making lazy loading work for CSS backgrounds, 
> this is implemented in the prototype but I don't think there are many tests 
> for it.

Is there a way for content authors to opt in/out (depending on the default), or 
does this just always follow what the default lazy loading setting is?

> 
> A related task is implementing lazy loading for iframe's, I took a quick look 
> and this looks like similar work to lazy image loading, but should be much 
> easier to implement now the building blocks are there.
> 
> Finally there is the task of setting threshold viewport distance values for 
> triggering deferred loads. I only have access to iOS simulator, so I wonder 
> if that is something Apple could help with?
> 
> I do not have a strong preference among these tasks. Thoughts?
> Cheers,
> 
> Rob.
> 
> P.S: I intend to attend the WebKit Contributors meeting, so feel free to chat 
> with me there about lazy loading.
> 
> ___
> 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] Can the WebKit logo be used for WebKit ports? (like WebKitGTK)

[Maciej Stachowiak]

> On Oct 11, 2019, at 9:38 AM, Konstantin Tokarev  wrote:
> 
> 
> 
> 10.10.2019, 23:10, "Ryosuke Niwa" :
>> People often associate the term "WebKit" with Apple's WebKit port in 
>> practice. The risk here is really about people not understanding the nuance 
>> of port specific bugs & set of features. 
> 
> However, Safari has its own column in the table, and its logo is very 
> different.

In the past, people used to think that “WebKit” was a separate browser based on 
WebKit nightlies. People get confused about this stuff easily. So it’s good to 
go for maximum clarity.

I think the recolored logo, a WebKit logo with a somewhat bigger Gtk+ logo 
overlaid, or WebKit with a little banner saying "GTk+” similar to the Edge Dev 
icon on the current wit.fyi dashboard would be good.

That would minimize risk of confusion, I think.

Regards,
Maciej

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

Re: [webkit-dev] Can the WebKit logo be used for WebKit ports? (like WebKitGTK)

[Maciej Stachowiak]

> On Oct 10, 2019, at 9:02 AM, Carlos Alberto Lopez Perez  
> wrote:
> 
> On 09/10/2019 21:53, Maciej Stachowiak wrote:
>> In terms of legalities:
>> 
>> The WebKit logo (as well as the term WebKit) is trademarked by Apple, but 
>> there are acceptable use guidelines in the Terms of Use: 
>> https://webkit.org/terms-of-use/ . I am not a lawyer and cannot give legal 
>> advice, but my interpretation is that it’s OK to use the WebKit logo in 
>> association with WebKitGTK. As far as alterations, I think a WebKit logo 
>> with a GTK+ logo next to it (or Linux logo, whatever), or badging it in the 
>> corner, would be more in line with the guidelines than a recolor. i.e. 
>> putting another logo/mark next to the WebKit logo seems more appropriate 
>> than directly altering the logo.
> 
> 
> So, if I understand right... something like this would be more
> acceptable? https://people.igalia.com/clopez/webkit_gtk_corner_logo.png
> 
> Personally, i think that is more likely to cause confusion than using a
> logo with different colors, check:
> 
> https://people.igalia.com/clopez/wpt_fyi_logo_test.png
> vs
> https://people.igalia.com/clopez/wpt_fyi_logo_test2.png

I see what you mean. The second version is hard to see at that size.

> 
> 
> But if that is ok for you, then for my part is also fine... in the end
> webkitgtk is webkit, right?
> 
> 
> And if someone doesn't like this, please let me know, we may try to come
> with a new logo for webkitgtk (that is not simply changing the colors).
> I just want to know how to best proceed in this regard.
> 
> 
> Regards.
> 

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

Re: [webkit-dev] Implementing OffscreenCanvas

[Maciej Stachowiak]

> On Oct 10, 2019, at 10:18 AM, John Wilander  wrote:
> 
>> On Oct 10, 2019, at 9:42 AM, Maciej Stachowiak  wrote:
>> 
>> For clarity, it’s already possible to render to a regular canvas offscreen. 
>> The  can be hidden using any of the techniques that can make any 
>> other canvas invisible. Name notwithstanding, OffscreenCanvas is mainly 
>> about being able to render from a Worker, not about enabling rendering 
>> offscreen.
>> 
>> Thus, I would not expect it to make it easier to invisibly fingerprint using 
>> canvas.
> 
> My thinking here is that viable mitigations for device fingerprinting could 
> be requiring a Canvas to be visible on screen or even for it to get user 
> interaction before it’ll get access to hardware acceleration. Such 
> restrictions would make it harder for tracking scripts to get away with GPU 
> fingerprinting that the site owner never wanted or accepted. If we allow 
> offscreen Canvas in workers, site owners will stay in the dark and we can’t 
> tie user interaction to it.

That is neat thinking. If a mitigation like this was effective, and we did it 
across the board, that would mean OffscreenCanvas is basically always disabled.

But I’m not sure it’s viable. A few concerns:
- It’s notoriously hard to tell if an element is really visible onscreen.
- Canvas backing store size is independent of its layout size, so even if we 
could solve the visibility problem, a rather small canvas could still get all 
the fingerprinting bits. (And the minimum size can’t be too low.)
- Rendering offscreen for multiple buffering or to to implement sprites is a 
legit use case and necessary for games.
- Rendering a canvas that’s currently scrolled below the fold is valuable. 
Otherwise you get a scrolling glitch later, or show the user blank content.
- Even software rendering is fingerprintable.
- Drawing itself isn’t even the fingerprinting step, it’s the readback.

I think canvas fingerprinting mitigations will have to be more along the lines 
of identifying the true source of the script attempting to perform readback and 
returning fake values, injecting noise (either into drawing or into readback), 
or things along these lines. It might also be possible to specifically block 
readback from invisible/offscreen canvases (as long as copying directly to 
another canvas is still allowed).

Thus, on reflection, I still do not think OffscreenCanvas hurts our ability to 
do fingerprinting mitigations.

But it is very good to consider tracking and fingerprinting risk for every 
feature, so I’m glad you brought this up!

Regards,
Maciej


> 
>   Regards, John
> 
>>> On Oct 10, 2019, at 9:32 AM, Chris Lord  wrote:
>>> 
>>> Hi John,
>>> 
>>> I don't know what the current state is of counter-measures for such an
>>> attack, but I don't immediately imagine OffscreenCanvas would make them
>>> more effective. The patch series doesn't add any new rendering paths, so
>>> whatever was possible before will likely still be possible and whatever
>>> wasn't will hopefully still not be possible. That said, I'll look into
>>> this and discuss it with some people that will know better than me and
>>> try to get a better picture.
>>> 
>>> Thanks,
>>> 
>>> Chris
>>> 
>>> On 2019-10-10 17:32, John Wilander wrote:
>>>> Hi Chris!
>>>> 
>>>> Canvas is a very popular GPU fingerprinting vector and allowing it
>>>> offscreen sounds like a more convenient way to perform such an attack
>>>> on user privacy. Do you know if Blink or Gecko have elaborated on
>>>> this? What is your assessment?
>>>> 
>>>> Given the cross-engine effort to fight device fingerprinting and
>>>> WebKit and Gecko’s recently published tracking prevention policies, we
>>>> should do a threat analysis of this feature.
>>>> 
>>>> Regards, John
>>>> 
>>>>> On Oct 10, 2019, at 4:24 AM, Chris Lord  wrote:
>>>>> 
>>>>> Hi all,
>>>>> 
>>>>> I've spent the last month or so 'finishing' the implementation of
>>>>> OffscreenCanvas[1], based on Žan Doberšek's work from a year ago[2].
>>>>> OffscreenCanvas is an API for being able to use canvas drawing without a
>>>>> visible canvas, and from within Workers. It's supported by Blink and has
>>>>> partial support in Gecko.
>>>>> 
>>>>> It's at the point now where I'd consider it a finished draft - it is
>>>>> almost fully implemented and passes the majority of relevant tests in a
>>>>> debug build withou

Re: [webkit-dev] Implementing OffscreenCanvas

[Maciej Stachowiak]

For clarity, it’s already possible to render to a regular canvas offscreen. The 
 can be hidden using any of the techniques that can make any other 
canvas invisible. Name notwithstanding, OffscreenCanvas is mainly about being 
able to render from a Worker, not about enabling rendering offscreen.

Thus, I would not expect it to make it easier to invisibly fingerprint using 
canvas.

> On Oct 10, 2019, at 9:32 AM, Chris Lord  wrote:
> 
> Hi John,
> 
> I don't know what the current state is of counter-measures for such an
> attack, but I don't immediately imagine OffscreenCanvas would make them
> more effective. The patch series doesn't add any new rendering paths, so
> whatever was possible before will likely still be possible and whatever
> wasn't will hopefully still not be possible. That said, I'll look into
> this and discuss it with some people that will know better than me and
> try to get a better picture.
> 
> Thanks,
> 
> Chris
> 
> On 2019-10-10 17:32, John Wilander wrote:
>> Hi Chris!
>> 
>> Canvas is a very popular GPU fingerprinting vector and allowing it
>> offscreen sounds like a more convenient way to perform such an attack
>> on user privacy. Do you know if Blink or Gecko have elaborated on
>> this? What is your assessment?
>> 
>> Given the cross-engine effort to fight device fingerprinting and
>> WebKit and Gecko’s recently published tracking prevention policies, we
>> should do a threat analysis of this feature.
>> 
>>   Regards, John
>> 
>>> On Oct 10, 2019, at 4:24 AM, Chris Lord  wrote:
>>> 
>>> Hi all,
>>> 
>>> I've spent the last month or so 'finishing' the implementation of
>>> OffscreenCanvas[1], based on Žan Doberšek's work from a year ago[2].
>>> OffscreenCanvas is an API for being able to use canvas drawing without a
>>> visible canvas, and from within Workers. It's supported by Blink and has
>>> partial support in Gecko.
>>> 
>>> It's at the point now where I'd consider it a finished draft - it is
>>> almost fully implemented and passes the majority of relevant tests in a
>>> debug build without crashing, but has some areas that need completion on
>>> other platforms (async drawing on non-Linux) and some missing parts (Web
>>> Inspector, ImageBitmapRenderingContext). It almost certainly needs
>>> reworking in places.
>>> 
>>> My work is on GitHub[3] - I'd like to solicit reviews and comment. Some
>>> of the bugs hanging off [2] have patches that need review and I think
>>> are near ready to being landable as the foundation of this work. It is
>>> broadly split up like so:
>>> 
>>> - Refactor to move functionality from HTMLCanvasElement to CanvasBase
>>> - Refactor to not unnecessarily require HTMLCanvasElement in places
>>> - Implement OffscreenCanvas functionality
>>> - Make font loading/styling usable from a Worker and without a Document
>>> - Implement AnimationFrameProvider on DedicatedWorkerGlobalScope
>>> - Implement asynchronous drawing updates on placeholder canvases
>>> 
>>> I expect the font-related stuff to be the most contentious, and my
>>> AnimationFrameProvider implementation may be too trivial (but might be
>>> ok for a first go?)
>>> 
>>> All feedback appreciated. Best regards,
>>> 
>>> Chris
>>> 
>>> [1]
>>> https://html.spec.whatwg.org/multipage/canvas.html#the-offscreencanvas-interface
>>> [2] https://bugs.webkit.org/show_bug.cgi?id=183720
>>> [3] https://github.com/Cwiiis/webkit/tree/offscreen-canvas
>>> ___
>>> 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 mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Can the WebKit logo be used for WebKit ports? (like WebKitGTK)

[Maciej Stachowiak]

> On Oct 9, 2019, at 5:43 AM, Carlos Alberto Lopez Perez  
> wrote:
> 
> On 03/10/2019 00:43, Ryosuke Niwa wrote:
>> I don't know the rules regarding the logo use but it might be a bit
>> misleading to use WebKit logo without any qualification for GTK+ port on
>> wpt.fyi.
>> 
>> I'd imagine people who visiting wpt.fyi may not realize how different GTK+
>> and Apple's WebKit ports are in terms of set of features being enabled, and
>> which sets of tests pass in each port.
>> 
>> So at minimum, we may want to add some kind of indication that it's GTK+
>> port; or that it's distinct from Apple's WebKit ports if you were to use
>> WebKit's logo somehow.
> 
> I agree that its important to not confuse users and make clearer that
> the results are for the WebKitGTK port.
> 
> On one hand the name would be WebKitGTK and the platform Linux, and on
> the other hand it would have on the smaller icon at the left a Tux (the
> classic Linux penguin).
> 
> See this example of how it would look (without logo still):
> 
> https://wpt.fyi/results/?run_id=334360001_id=336100010_id=322590004_id=332480002_id=332480003
> 
> 
> However, I agree that still can be confusing if we use the WebKit logo
> as is. So, let's discard doing that.
> 
> But, I wonder if it would be OK to use a variation of the WebKit logo
> with some clearly visible modifications like different colors.
> 
> For example: https://cloud.igalia.com/index.php/s/y4xrKBYBY8t643D
> (Its the WebKit logo but with the GTK colors)
> 
> 
> Would be using this variation of the logo OK?

In terms of legalities:

The WebKit logo (as well as the term WebKit) is trademarked by Apple, but there 
are acceptable use guidelines in the Terms of Use: 
https://webkit.org/terms-of-use/ . I am not a lawyer and cannot give legal 
advice, but my interpretation is that it’s OK to use the WebKit logo in 
association with WebKitGTK. As far as alterations, I think a WebKit logo with a 
GTK+ logo next to it (or Linux logo, whatever), or badging it in the corner, 
would be more in line with the guidelines than a recolor. i.e. putting another 
logo/mark next to the WebKit logo seems more appropriate than directly altering 
the logo.




> 
> 
> Thanks
> 
> ___
> 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] Having trouble building

[Maciej Stachowiak]

> On Oct 5, 2019, at 9:36 PM, Ken Russell  wrote:
> 
> On Sat, Oct 5, 2019 at 1:11 AM Tim Horton  > wrote:
> 
> 
> > On Oct 4, 2019, at 8:55 PM, Ken Russell  > > wrote:
> > 
> > Hi,
> > 
> > Recently I upgraded to Xcode 11.0 and re-synced to top-of-tree WebKit. With 
> > a clean WebKitBuild directory I'm seeing the following build error:
> 
> What OS are you on?
> 
> You might want to peek at https://bugs.webkit.org/show_bug.cgi?id=199705 
> 
> 
> macOS 10.14.6, Xcode 11.0 from the App Store.
> 
> Looks like the same problem. Could anyone from Apple please try to help fix 
> this? I posted a hack workaround on the bug but don't know enough Objective-C 
> to guess at a correct fix.

Does the new patch from Mitz fix the build for you?

 - Maciej

> 
> Thanks,
> 
> -Ken
> 
>  
> > $ ./Tools/Scripts/build-webkit --release > build-log.txt
> > 
> > ...
> > 
> > In file included from 
> > /Users/kbr/src/WebKit/WebKitBuild/Release/DerivedSources/WebKitLegacy/unified-sources/UnifiedSource20-mm.mm:4:
> > /Users/kbr/src/WebKit/Source/WebKitLegacy/mac/WebView/WebHTMLView.mm:222:5: 
> > error: use of undeclared identifier '_subviews'; did you mean 'subviews'?
> > _subviews = subviews;
> > ^
> > subviews
> > /Users/kbr/src/WebKit/Source/WebKitLegacy/mac/WebView/WebHTMLView.mm:220:63:
> >  note: 'subviews' declared here
> > - (void)_setSubviewsIvar:(NSMutableArray<__kindof NSView *> *)subviews {
> >   ^
> > /Users/kbr/src/WebKit/Source/WebKitLegacy/mac/WebView/WebHTMLView.mm:222:15:
> >  error: explicitly assigning value of variable of type 
> > 'NSMutableArray<__kindof NSView *> *' to itself [-Werror,-Wself-assign]
> > _subviews = subviews;
> > ~ ^ 
> > /Users/kbr/src/WebKit/Source/WebKitLegacy/mac/WebView/WebHTMLView.mm:228:30:
> >  error: use of undeclared identifier '_subviews'
> > return (NSMutableArray *)_subviews;
> >  ^
> > 3 errors generated.
> > 
> > 
> > 
> > Has anyone else run into this?
> > 
> > Thanks,
> > 
> > -Ken
> > 
> > ___
> > 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 mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Moving to Python 3

[Maciej Stachowiak]

> On Jul 13, 2019, at 7:26 PM, Maciej Stachowiak  wrote:
> 
> 
> 
>> On Jul 13, 2019, at 4:14 PM, Michael Catanzaro  wrote:
>> 
>> On Sat, Jul 13, 2019 at 6:02 PM, Maciej Stachowiak  wrote:
>>> This is exactly what virtualenvs can do. And this is how we should do it 
>>> IMO, even for systems that natively have some version of Python 3.
>> 
>> I guess that's fine for everything not required by the CMake build, e.g. 
>> build-webkit and webkitpy. That's probably 99% of our python code.
>> 
>> Scripts required by the CMake build should use system python3 though, not 
>> the virtualenv. I guess that's 1% or less of our python. OK?
> 
> Can you clarify why this is needed?

(Also which specific Python scripts are needed by the CMake build?)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Moving to Python 3

[Maciej Stachowiak]

> On Jul 13, 2019, at 4:14 PM, Michael Catanzaro  wrote:
> 
> On Sat, Jul 13, 2019 at 6:02 PM, Maciej Stachowiak  wrote:
>> This is exactly what virtualenvs can do. And this is how we should do it 
>> IMO, even for systems that natively have some version of Python 3.
> 
> I guess that's fine for everything not required by the CMake build, e.g. 
> build-webkit and webkitpy. That's probably 99% of our python code.
> 
> Scripts required by the CMake build should use system python3 though, not the 
> virtualenv. I guess that's 1% or less of our python. OK?

Can you clarify why this is needed?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Moving to Python 3

[Maciej Stachowiak]

> On Jul 13, 2019, at 3:44 PM, Ryosuke Niwa  wrote:
> 
> 
> 
> 
>> On Fri, Jul 12, 2019 at 11:22 PM Jonathan Bedard  wrote:
>> I would agree that if we move to Python 3, we need a script which installs 
>> Python 3 in an impossible to mess-up way on Mojave and High Sierra.
>> 
>> I don’t think the clang comparison is fair here. Python 2 is officially 
>> deprecated in 2020, we can’t expect security updates to the language or any 
>> libraries we depend on 6 months from now. It’s not really a question of if 
>> we stop supporting Python 2, but rather, when we stop supporting Python 2.
> 
> I don’t think anyone is arguing that we’d eventually need to move to Python3. 
> I’m arguing that it’s not okay to require random WebKit contributor to know 
> some obscure python insanity to install Python 3, or have a script that 
> installs Python 3 and breaks all other python scripts in the system.
> 
>> 
>> It’s also worth noting that in Catalina, we will need some script to install 
>> XCode Command Line Tools since SVN, Python 2.7 and Python 3 are no longer 
>> included by default in the new Xcode. Given this, it doesn’t seem terrible 
>> if the script responsible for installing XCode CL tools also installs Python 
>> 3 for older Mac versions.
> 
> Yes, as long as it doesn’t replace or break existing Python2.7 and/or other 
> python scripts in the system.

This is exactly what virtualenvs can do. And this is how we should do it IMO, 
even for systems that natively have some version of Python 3.

> 
>> 
 On Jul 12, 2019, at 7:34 PM, Ryosuke Niwa  wrote:
 
>>> 
>> 
>>> 
 On Fri, Jul 12, 2019 at 7:03 PM Michael Catanzaro  
 wrote:
 On Fri, Jul 12, 2019 at 5:22 PM, Ryosuke Niwa  wrote:
 > I frequently do WebKit development in older versions of macOS to 
 > diagnose old OS specific regressions, and having to install Python 3 
 > each time I install an old OS is too much of a trouble.
 
 I understand it would be a hassle. :/ But please consider it relative 
 to the additional difficulty of rewriting all of webkitpy to support 
 multiple versions of python at the same time, or setting up a wrapper 
 layer of bash scripts around all of our python scripts to enter a 
 virtualenv before executing the real script.
>>> 
>>> Yeah, and it sounds strictly better that the trouble is handled by people 
>>> who maintain Python code who presumably more about Python than a random 
>>> WebKit contributor who may not know how to setup virtual environment in 
>>> Python, etc... 
>>> 
>>> Again, the argument that the difficulty can be overcome and it's a minor 
>>> inconvenience isn't convincing. I can, for example, suggest that we should 
>>> just build WebKit using the latest version of clang. Anyone who uses a 
>>> system that doesn't come with the latest release of clang should just build 
>>> clang instead. There is a significant cost in having to support MSVC and 
>>> GC++ so we should just use clang everywhere and only the latest version 
>>> like Chromium does.
>>> 
>>> Each team & person has a different preference & perspective when it comes 
>>> to tooling. Please don't break someone else's working workflow based on 
>>> your preference.
>>> 
>>> - R. Niwa
>>> 
> -- 
> - R. Niwa
> ___
> 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] Moving to Python 3

[Maciej Stachowiak]

> On Jul 12, 2019, at 3:23 PM, Ryosuke Niwa  wrote:
> 
> 
>> On Fri, Jul 12, 2019 at 1:04 PM Jonathan Bedard  wrote:
> 
>> 
>> > On Jul 12, 2019, at 12:49 PM, Michael Catanzaro  
>> > wrote:
>> > 
>> > On Fri, Jul 12, 2019 at 2:18 PM, Jonathan Bedard  wrote:
>> >> The trouble I foresee us encountering with any scheme which attempts a 
>> >> conversion which retains both Python 2.7 and Python 3 compatibility is 
>> >> code like this:
>> > 
>> > Is python2 support required for a well-motivated transitional purpose?
>> > 
>> > I had previously proposed making all our scripts work with both python2 
>> > and python3 only because I thought Apple was going to require python2 
>> > indefinitely. Now that you're interested in this transition, there's 
>> > probably no need to continue python2 support. Anyone building WebKit on 
>> > older versions of macOS can reasonably be expected to manually install 
>> > python3, right? And it's clear that you're prepared to do this for 
>> > infrastructure/bots already.
>> 
>> We still need to figure out whether (and for how long) we intend to retain 
>> Python 2 support. Over the last few months, opinions on this have changed 
>> quite a bit, so I’m trying to determine what our path forward is going to be.
>> 
>> In my opinion, a few months after Catalina GMs, we no longer need to 
>> maintain Python 2 support, assuming that we provide adequate automation for 
>> installing Python 3 on pre-Catalina macOS (ie, Mojave, High Sierra) and are 
>> explicit about shebangs.
> 
> I don't think it's acceptable to require installation of Python 3 just to 
> build & run tests on WebKit unless the installation itself is automated and 
> compartmentalized to WebKit's development given how bad Python is with 
> respect to having multiple versions of Python's and managing packages between 
> them.
> 
> I frequently do WebKit development in older versions of macOS to diagnose old 
> OS specific regressions, and having to install Python 3 each time I install 
> an old OS is too much of a trouble.

It’s possible install a python without installing it on the system, and install 
modules and any needed additions, using virtualenv: 
https://virtualenv.pypa.io/en/stable/

This is the pro way to use python without caring about what happens to be on 
the system. 

 I suggest we proceed by gradually converting our scripts to use a Python 3 
virtualenv. This will also spare us the need to install Python modules onto the 
system. The tricky part will be that webkitpy would have to work both ways 
until conversion is complete (or at the extreme I guess we could fork it).

> - R. Niwa
> 
> ___
> 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] Remove SVGTests.hasExtension?

[Maciej Stachowiak]

The one remaining thing we could potentially worry about is platform-specific 
content, like books or content embedded in apps. But given what 
SVGTests.hasExtension() is supposed to do, that seems very unlikely.

Since SVG WG resolved to remove it, has it in fact been removed from the SVG 
spec?

Regards,
Maciej



> On Jun 10, 2019, at 2:12 AM, Philip Jägenstedt  wrote:
> 
> FWIW, here's the original intent to remove it from Chromium:
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/Ae_lmov16_o/Wa5XhHFoAAAJ
>  
> 
> 
> We had use counters, and I wrote "Usage is zero for all of them."
> 
> When concerned about usage in the wild, the tool we usually use for Chromium 
> is httparchive, currently containing ~460k pages. I just did a quick search 
> and found 230 matches for ".hasExtension(". But most are ".hasExtension()" 
> and obviously not use of this API. A search for the regexp 
> r'\.hasExtension\([^)]' gives only 34 matches, listed here:
> https://gist.github.com/foolip/5081f13794baafcd400d8630778dad86 
> 
> 
> A larger CSV with the bodies included:
> https://drive.google.com/file/d/1neFKBtmyjOLaRb_sppP3cmMeFEXfiGqr/view?usp=sharing
>  
> 
> 
> Skimming that, I can't find any real usage of SVG's hasExtension, it seems to 
> be mostly utility code around file extensions.
> 
> Ryosuke, does that address the concern of existing content, or is there 
> anything else you'd check?
> 
> Note that in the case of Range's detach, I don't think anyone made an attempt 
> to remove it:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14591 
> 
> 
> There are 865,911 resources (more than there are pages) matching ".detach()" 
> in httparchive, probably also mostly not real usage, but still putting it in 
> a very different situation than hasExtension :)
> 
> HTH
> 
> On Sat, Jun 8, 2019 at 12:42 AM Ryosuke Niwa  > wrote:
> The concern here isn't with the future versions of Edge or Firefox but rather 
> with the content that may be relying on this feature even unintentionally.
> Removing a JS method or object is very high risk because that could result in 
> an immediate JS exception and break a key functionality of a website.
> 
> This is why HTML and DOM standards has a bunch of methods that don't do 
> anything like Range's detach: https://dom.spec.whatwg.org/#dom-range-detach 
> 
> 
> - R. Niwa
> 
> On Fri, Jun 7, 2019 at 11:54 AM Frédéric Wang  > wrote:
> Patch for Firefox was uploaded 4 years ago and they announced plan for 
> removal at that time. We pinged Mozilla some weeks ago about it, they landed 
> the patch and announced it:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1133175 
> 
> https://www.fxsitecompat.com/en-CA/docs/2019/hasextension-has-been-removed-from-some-svg-interfaces/
>  
> 
> https://www.fxsitecompat.com/en-CA/docs/2015/several-properties-will-be-removed-from-svgsvgelement/
>  
> 
> 
> I didn't check Edge, but Microsoft is migrating to Chromium so that's not 
> going to be there in future versions.
> 
> On 07/06/2019 20:40, Ryosuke Niwa wrote:
>> Does Edge support it? When did Firefox remove this feature?
>> 
>> On Fri, Jun 7, 2019 at 1:55 AM Frédéric Wang > > wrote:
>> Hi,
>> 
>> 4 years ago, the SVG WG resolved to remove SVGTests.hasExtension due to lack 
>> of use and being a poor API.
>> It was removed from Chromium at that time and has been removed from Firefox 
>> recently.
>> 
>> I'm not sure whether the WebKit community is willing to keep that feature. 
>> Anyway I opened a bug entry to track possible removal: 
>> 
>> https://bugs.webkit.org/show_bug.cgi?id=198652 
>> 
>> -- 
>> Frédéric Wang
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org 
>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>> 
>> -- 
>> - R. Niwa
> 
> -- 
> Frédéric Wang
> ___
> 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
> 

Re: [webkit-dev] MathML Refresh Heads up

[Maciej Stachowiak]

> On Mar 15, 2019, at 3:33 PM, Frédéric Wang  wrote:
> 
> Hi Ryosuke and Myles,
> 
> Thank you for your reply. First, the exact thing about what will be in MathML 
> Core is still open, people are welcome to join and participate to the MathML 
> CG [1] or comment on the GitHub tracker [2].
> 
> Our plan was also to remove features from WebKit but of course ultimately the 
> consensus has to be made in the WebKit community (hence our heads up email). 
> What do you suggest? Should we send "intent to remove" to this mailing list? 
> Or is it enough to cc' Apple reviewers on bugs in order to get the approval? 
> Something else?

It’s easier for us to check Apple Books and iOS App compatibility for a batch 
of possible removals at once, instead of one at a time. We can start by looking 
at the set of items below.

It’s helpful to give a heads-up other than the normal review process, because 
our main concern is compatibility, and not all reviewers will be able to easily 
access the corpus of app-specific or books-specific content that may be 
affected. 

We assume web compatibility is not a major issue since MathML isn’t in all 
browsers and in general is not widely used on websites, but there might also be 
some value in doing web usage analysis for these features if there’s any 
meaningful web usage of MathML at all.

> 
> For now, these are the features the CG has already agreed to not include in 
> MathML Core (more to come). We would like to propose to remove them from 
> WebKit:
> 
> * "thin", "thick", "medium" values of mfrac's linethickness attribute ( 
> https://github.com/mathml-refresh/mathml/issues/4 
>  )
> * "small" "normal" "big" values of mathsize attribute ( 
> https://github.com/mathml-refresh/mathml/issues/7 
>  )
> * nonzero unitless values for MathML lengths ( 
> https://github.com/mathml-refresh/mathml/issues/24 
>  )
> * fontfamily, fontweight, fontstyle, fontsize, color, background MathML 
> attributes ( https://github.com/mathml-refresh/mathml/issues/5 
>  )
> 
> In any case, it would be very appreciated to get some analysis about the 
> usage of MathML markup used in Apple's product. How can we proceed to obtain 
> it?
> 
> Thanks,
> 
> [1] https://www.w3.org/community/mathml4/ 
> 
> [2] https://github.com/mathml-refresh/mathml/issues/ 
> 
> 
> On 15/03/2019 22:33, Myles C. Maxfield wrote:
>> 
>> 
>>> On Mar 15, 2019, at 11:29 AM, Ryosuke Niwa >> > wrote:
>>> 
>>> 
>>> On Fri, Mar 15, 2019 at 3:08 AM Frédéric Wang >> > wrote:
>>> Hello WebKit developers,
>>> 
>>> As some of you may know, Igalia is working on MathML support in Chromium
>>> this year [1]. As part of that effort we joined a new MathML Refresh
>>> Community Group [2] and one goal is to focus on a core spec for browser
>>> implementations [3] to:
>>> - Remove deprecated/uncommon/duplicate math features that could be
>>> implemented by polyfills (relying on MathML core and other web
>>> technologies).
>>> 
>>> I'd be very much concerned about backwards compatibility here when it come 
>>> to removing any features.
>>> It's important to notice that WebKit is also used by hundreds of thousands 
>>> of iOS apps and macOS apps.
>>> How do we know we won't break those applications?
>>> 
>>> In general, I don't agree with whatever Google said about MathML being too 
>>> complex, etc…
>> 
>> The original sentence doesn’t say they will be removing anything in WebKit. 
>> There are plenty of features that have been removed from specs that we 
>> continue supporting in WebKit for backwards compatibility.
>> 
>> We could also consider migrating our implementation to a JS polyfill if one 
>> exists.
>> 
>> Is there a characterization of which features are planned for deprecation? 
>> We might be able to do some analysis on iBooks' and iOS apps’ content.
>> 
>>> 
>>> - Add more detailed algorithms (based on TeX/OpenType/CSS layout) to
>>> help implementation and conformance testing.
>>> - Align MathML with CSS/HTML (parsing, layout...), introducing new web
>>> platform features (CSS, fonts...) for math if necessary.
>> 
>> This sounds wonderful! A more coherent MathML story going forward would be 
>> fantastic.
>> 
>>> 
>>> On the other hand, these seem like very valuable improvements.
>>> 
>>> We expect that this effort will improve browser interoperability and
>>> reduce complexity of current implementations.
>>> 
>>> Given there aren't too many websites that deploy MathML directly on 
>>> production, my concerns are more about existing iOS and madOS apps that 
>>> embed WKWebView or WebView / UIWebView and use MathML.
>>> 
>>> - R. Niwa
>>> 
>>> ___

Re: [webkit-dev] Filtering results on wpt.fyi, Safari-specific failures

[Maciej Stachowiak]

> On Feb 25, 2019, at 1:57 PM, Philip Jägenstedt  wrote:
> 
> I think I know what's going on there. When drilling down into tests and 
> subtests, only those matching the filter are shown. Clearing the filter 
> things look a bit different in the directories you mentioned:
> https://wpt.fyi/results/ambient-light?label=master=experimental=chrome%5Btaskcluster%5D=firefox%5Btaskcluster%5D=safari%5Bazure%5D
>  
> <https://wpt.fyi/results/ambient-light?label=master=experimental=chrome%5Btaskcluster%5D=firefox%5Btaskcluster%5D=safari%5Bazure%5D>
> https://wpt.fyi/results/bluetooth?label=master=experimental=chrome%5Btaskcluster%5D=firefox%5Btaskcluster%5D=safari%5Bazure%5D
>  
> <https://wpt.fyi/results/bluetooth?label=master=experimental=chrome%5Btaskcluster%5D=firefox%5Btaskcluster%5D=safari%5Bazure%5D>
> 
> In particular for idlharness.js tests some subtests will pass because they're 
> preconditions for the real tests.

OK.

> There will also be tests that check that something doesn't work, which will 
> pass even if the feature is entirely unsupported if "not working" results in 
> the same thing, e.g. throwing an exception. Sometimes tests can be tweaked to 
> fail if the feature is unsupported.

It would be helpful for clarity if “feature not supported at all” resulted in 
zero tests passing, but perhaps it is challenging to stick to writing tests 
that way.

> 
> Drilling down into a directory somewhat at random and clearing filters, it 
> does look like this is legit:
> https://wpt.fyi/results/fetch/api/cors?label=master=experimental=chrome%5Btaskcluster%5D=firefox%5Btaskcluster%5D=safari%5Bazure%5D
>  
> <https://wpt.fyi/results/fetch/api/cors?label=master=experimental=chrome%5Btaskcluster%5D=firefox%5Btaskcluster%5D=safari%5Bazure%5D>
>  

There’s definitely lots of failures that look legit.

> 
> On Mon, Feb 25, 2019 at 8:31 PM Maciej Stachowiak  <mailto:m...@apple.com>> wrote:
> 
> Neat.
> 
> I see some obvious areas for focus, where Safari fails lots of tests that the 
> other browser don’t. 
> 
> For context, I tried looking at this view, which shows all tests that Safari 
> and Firefox pass with Safari results regardless of result:
> https://wpt.fyi/results/?label=master=experimental=chrome%5Btaskcluster%5D=firefox%5Btaskcluster%5D=safari%5Bazure%5D=%28chrome%3Apass%7Cchrome%3Aok%29+%28firefox%3Apass%7Cfirefox%3Aok%29
>  
> <https://wpt.fyi/results/?label=master=experimental=chrome[taskcluster]=firefox[taskcluster]=safari[azure]=(chrome:pass%7Cchrome:ok)+(firefox:pass%7Cfirefox:ok)>
> 
> I noticed some puzzling results there: Safari passes all the ambient-light 
> and bluetooth tests that Chrome and Firefox do, despite not supporting these 
> standards at all. (For that matter I’m not sure Firefox supports these specs 
> either.) Not sure if harness problem, or dubious tests that don’t actually 
> test the standard.
> 
> Regards,
> Maciej
> 
>> On Feb 25, 2019, at 5:48 AM, Philip Jägenstedt > <mailto:foo...@chromium.org>> wrote:
>> 
>> I'd like to point out right away that diagnosing reftest failures is
>> currently cumbersome because we don't store the screenshots. This is
>> also a work in progress:
>> https://docs.google.com/document/d/1IhZa4mrjK1msUMhtamKwKJ_HhXD-nqh_4-BcPWM6soQ/edit?usp=sharing
>>  
>> <https://docs.google.com/document/d/1IhZa4mrjK1msUMhtamKwKJ_HhXD-nqh_4-BcPWM6soQ/edit?usp=sharing>
>> 
>> Until that has launched, I would recommend ignoring reftest failures
>> if the cause of failure isn't obvious.
>> 
>> On Mon, Feb 25, 2019 at 2:30 PM Philip Jägenstedt > <mailto:foo...@chromium.org>> wrote:
>>> 
>>> Hi all,
>>> 
>>> Following the improved Safari results last year [1] and the discussion
>>> that generated, I'm happy to announce that the filtering requested as
>>> now available in the search box. The full syntax is documented [2] but
>>> there's also a new insights view [3] with some useful searches.
>>> 
>>> Especially interesting for this list could be this view, of Chrome
>>> Dev, Firefox Nightly and Safari Technology Preview, filtered to the
>>> Safari-specific failures:
>>> https://wpt.fyi/results/?label=master=experimental=chrome%5Btaskcluster%5D=firefox%5Btaskcluster%5D=safari%5Bazure%5D=%28chrome%3Apass%7Cchrome%3Aok%29+%28firefox%3Apass%7Cfirefox%3Aok%29+%28safari%3A%21pass%26safari%3A%21ok%29
>>>  
>>> <https://wpt.fyi/results/?label=master=experimental=chrome%5Btaskcluster%5D=firefox%5Btaskcluster%5D=safari%5Bazure%5D=%28chrome%3Apass%7Cchrome%3Aok%29+%28firefox%3Apass%7Cfirefox%3Aok%29+%28safari%3A%21pass%26safari%3A%21ok%29>
>>> 
&g

Re: [webkit-dev] Filtering results on wpt.fyi, Safari-specific failures

[Maciej Stachowiak]

Neat.

I see some obvious areas for focus, where Safari fails lots of tests that the 
other browser don’t. 

For context, I tried looking at this view, which shows all tests that Safari 
and Firefox pass with Safari results regardless of result:
https://wpt.fyi/results/?label=master=experimental=chrome%5Btaskcluster%5D=firefox%5Btaskcluster%5D=safari%5Bazure%5D=%28chrome%3Apass%7Cchrome%3Aok%29+%28firefox%3Apass%7Cfirefox%3Aok%29
 


I noticed some puzzling results there: Safari passes all the ambient-light and 
bluetooth tests that Chrome and Firefox do, despite not supporting these 
standards at all. (For that matter I’m not sure Firefox supports these specs 
either.) Not sure if harness problem, or dubious tests that don’t actually test 
the standard.

Regards,
Maciej

> On Feb 25, 2019, at 5:48 AM, Philip Jägenstedt  wrote:
> 
> I'd like to point out right away that diagnosing reftest failures is
> currently cumbersome because we don't store the screenshots. This is
> also a work in progress:
> https://docs.google.com/document/d/1IhZa4mrjK1msUMhtamKwKJ_HhXD-nqh_4-BcPWM6soQ/edit?usp=sharing
> 
> Until that has launched, I would recommend ignoring reftest failures
> if the cause of failure isn't obvious.
> 
> On Mon, Feb 25, 2019 at 2:30 PM Philip Jägenstedt  wrote:
>> 
>> Hi all,
>> 
>> Following the improved Safari results last year [1] and the discussion
>> that generated, I'm happy to announce that the filtering requested as
>> now available in the search box. The full syntax is documented [2] but
>> there's also a new insights view [3] with some useful searches.
>> 
>> Especially interesting for this list could be this view, of Chrome
>> Dev, Firefox Nightly and Safari Technology Preview, filtered to the
>> Safari-specific failures:
>> https://wpt.fyi/results/?label=master=experimental=chrome%5Btaskcluster%5D=firefox%5Btaskcluster%5D=safari%5Bazure%5D=%28chrome%3Apass%7Cchrome%3Aok%29+%28firefox%3Apass%7Cfirefox%3Aok%29+%28safari%3A%21pass%26safari%3A%21ok%29
>> 
>> Both Google and Mozilla have efforts [4][5] to reduce the number of
>> Chrome/Firefox-specific failures, as this seems like a category of
>> problems which especially valuable, where changing just one browser
>> can remove a pain point for web developers.
>> 
>> No doubt some failures are spurious, but hopefully there is value to
>> be found by looking into where the largest numbers of failures appear
>> to be. If something seems to be wrong with the search/filtering,
>> please file an issue for us! [6]
>> 
>> Credit to Mark Dittmer and Luke Bjerring who owned this project.
>> 
>> P.S. We are also working on triage metadata for wpt.fyi, to make it
>> possible to burn down a list of failures like this and not later have
>> to re-triage to find the new failures. [7]
>> 
>> [1] https://lists.webkit.org/pipermail/webkit-dev/2018-October/030209.html
>> [2] 
>> https://github.com/web-platform-tests/wpt.fyi/blob/master/api/query/README.md
>> [3] https://staging.wpt.fyi/insights
>> [4] https://bugs.chromium.org/p/chromium/issues/detail?id=896242
>> [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1498357
>> [6] 
>> https://github.com/web-platform-tests/wpt.fyi/issues/new?title=Structured+Queries+issue=web-platform-tests/wpt.fyi/8=bug=search.md
>> [7] 
>> https://docs.google.com/document/d/1oWYVkc2ztANCGUxwNVTQHlWV32zq6Ifq9jkkbYNbSAg/edit?usp=sharing
> ___
> 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] Code Style: Opinion on returning void

[Maciej Stachowiak]

It seems like `return foo();` where foo() is a void function can always be 
replaced with `foo(); return;` for greater clarity at the cost of one extra 
line break. For people who prefer the one-line style, can you say why you don’t 
like the other way?

 - Maciej

> On Feb 20, 2019, at 10:33 AM, Simon Fraser  wrote:
> 
> I find it mind bending. It makes me wonder if the author made a coding error.
> 
> Simon
> 
>> On Feb 20, 2019, at 7:48 AM, Daniel Bates > > wrote:
>> 
>> Thanks for the opinion!
>> 
>> Dan
>> 
>> On Feb 20, 2019, at 7:26 AM, Saam Barati > > wrote:
>> 
>>> I prefer it as well.
>>> 
>>> - Saam
>>> 
>>> On Feb 20, 2019, at 6:58 AM, Chris Dumez >> > wrote:
>>> 
 I also prefer allowed returning void. 
 
 Chris Dumez
 
 On Feb 19, 2019, at 10:35 PM, Daniel Bates >>> > wrote:
 
> 
> 
> On Feb 19, 2019, at 9:42 PM, Ryosuke Niwa  > wrote:
> 
>> On Tue, Feb 19, 2019 at 8:59 PM Daniel Bates > > wrote:
>> > On Feb 7, 2019, at 12:47 PM, Daniel Bates > > > wrote:
>> >
>> > Hi all,
>> >
>> > Something bothers me about code like:
>> >
>> > void f();
>> > void g()
>> > {
>> > if (...)
>> > return f();
>> > return f();
>> > }
>> >
>> > I prefer:
>> >
>> > void g()
>> > {
>> > if (...) {
>> > f();
>> > return
>> > }
>> > f();
>> > }
>> >
>> Based on the responses it seems there is sufficient leaning to codify
>> the latter style.
>> 
>> I don't think there is a sufficient consensus as far as I can tell. Geoff
> 
> I didn't get this from Geoff's remark. Geoff wrote:
> 
> ***“return f()” when f returns void is a bit mind bending.***
> Don't want to put words in Geoff's mouth. So, Geoff can you please 
> confirm: for the former style, for the latter style, no strong opinion.
> 
>> and Alex both expressed preferences for being able to return void,
> 
> I got this from Alex's message
> 
>> and Saam pointed out that there is a lot of existing code which does 
>> this.
> 
> I did not get this. He wrote emphasis mine:
> 
> I've definitely done this in JSC. ***I don't think it's super common***, 
> but I've also seen code in JSC not written by me that also does this.
> 
>> Zalan also said he does this in his layout code.
> 
> I did not get this, quoting, emphasis mine:
> 
> I use this idiom too in the layout code. I guess I just prefer a more
> compact code.
> ***(I don't feel too strongly about it though)***
> 
> By the way, you even acknowledged that "WebKit ... tend[s] to have a 
> separate return.". So, I inferred you were okay with it. But from this 
> email I am no longer sure what your position is. Please state it clearly.
> 
>> - R. Niwa
>> 
> ___
> 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 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 mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Moving to Git

[Maciej Stachowiak]

> On Feb 20, 2019, at 12:14 PM, Michael Catanzaro  wrote:
> 
> FWIW, it's not hard to enforce fast-forward merges with a git hook; that way, 
> we can guarantee that the history has no merge commits and is fully linear. 
> GitLab has built-in support to enforce this for merge requests (though not 
> for direct commits). I agree that linear history is a must for a project the 
> size of WebKit. rNN tags would be nice, but hardly essential as long as 
> the history is linear.

I think our concern is not just linearity. The reason Ryosuke suggests 
monotonically increasing revisions is because we often need to answer questions 
like the following:

- This performance graph shows a regression between revision A and revision B, 
I wonder how many revisions are between those?
- I need to manually bisect a regression between revisions X and Y. I wonder 
what the approximate midpoint is?

Monotonically increasing sequential numbers make it super easy to answer 
questions like that. Ideally, such revision numbers would also be accepted by 
all tools we have to work with. Many git revision number solutions I have seen 
involve running an extra tool or consulting an additional website to be able to 
make determinations like this, and that would be a significant task on 
performance regression defense in particular.

We’d love to hear about solutions that can provide something like this, ideally 
ones that are GitHub compatible.

> 
> On Wed, Feb 20, 2019 at 1:38 PM, Bug Tracker 
>  wrote:
>> I considered this option, but my work will involve touching multiple parts 
>> of the codebase and thus I would like to be able to keep up / merge locally 
>> with the upstream every now and then (e.g. on each relatively stable 
>> release, such as Apple's Safari Technology Preview).
>> However, all branches, tags etc. are available only on SVN.
> 
> Migrating to git would be wonderful, but a huge amount of infrastructure 
> effort. Since it's unlikely that anyone is going to invest the large amount 
> of effort required to transition WebKit to git anytime soon, I'd recommend 
> learning how to work with git-svn. It's a bit of effort but not too hard, and 
> way better than using Subversion directly.
> 
> 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

Re: [webkit-dev] Experimental features review

[Maciej Stachowiak]

> On Feb 14, 2019, at 9:01 AM, Michael Catanzaro  wrote:
> 
> On Wed, Feb 13, 2019 at 9:16 PM, Simon Fraser  wrote:
>> For these two, we now have them on by default because we think they are 
>> ready to ship. They still exist as experimental features so that people can 
>> turn them off for regression testing, but is the policy now to move them 
>> back to Debug features at this stage?
> 
> Well, I'm really not sure, other than that the feature is no longer supposed 
> to be experimental once it's ready to be on by default.
> 
> I notice there is a new class of features called internal features:
> https://trac.webkit.org/changeset/235921/webkit. Perhaps that would suffice 
> for regression testing?

I think this approach is needlessly confusing. For many features, there’s 
likely to be a period where the default flips, but it’s still useful for it to 
be switchable. Either for debugging, or because it hasn’t shipped in products 
yet and it is useful to compare. It would be sad if flags disappeared the 
moment the default flips, and likewise sad if they moved to a different menu as 
soon as the default flips.

(As an aside, I kind of hate experimental features being a menu like it is in 
Safari. Other browsers have more readable and persistent UI for this, like a 
special page or a settings pane. They also tend to have both default-on and 
default-off flags in the same place, so you don’t get lost on the day the 
default flips.)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Exciting JS features (class fields) in need of review :)

[Maciej Stachowiak]

> On Feb 14, 2019, at 1:37 AM, Xan Lopez  wrote:
> 
> Hi Maciej,
> 
> the first patches had the flag indeed, so it should be easy to add it back to 
> the patch. Not sure what's the usual procedure, but I guess it makes sense to 
> enable it by default in the bug so that the bots keep testing the code? Then 
> we'll disable it before landing if that's our decision.

If it’s a runtime flag then it’s possible to have the tests run without having 
it enabled by default. This is one reason runtime flags are the preferred 
choice, the feature can be running tests all along while still getting further 
polish and refinement.

For a compile-time flag, your approach sounds reasonable to me (patch that 
includes a default-on flag, ideally with a note in the ChangeLog that it will 
be flipped before landing).

We almost never turn on features by default right in the patch where they first 
land, unless it is really small and simple, to reduce risk of anyone 
accidentally shipping it if they happen to cut a release branch soon after it 
lands (and before it has had enough bake time).

BTW I appreciate the contribution of such a substantial feature, I regret that 
you haven’t gotten more active review, and I am glad that Saam is now giving 
you another review pass.

Cheers,
Maciej

> 
> Cheers,
> Xan
> 
> On Thu, Feb 14, 2019 at 8:47 AM Maciej Stachowiak  <mailto:m...@apple.com>> wrote:
> 
> I left the boring review feedback that this work should be behind a feature 
> flag. Mentioning it here because this may apply to other feature patches you 
> have in progress. (I am not qualified to review the substance of what the 
> patch is doing.)
> 
> > On Feb 13, 2019, at 1:51 PM, ca...@igalia.com <mailto:ca...@igalia.com> 
> > wrote:
> > 
> > Hi WebKitters,
> > 
> > My colleagues at Igalia have been working on a number of JS language 
> > features! We want WebKit to have implementations in order to provide 
> > feedback for TC39, and to help meet the requirements to have them merged 
> > into the specification proper.
> > 
> > Unfortunately, JSC suggested reviewers have been occupied for the past 6 
> > months, unable to provide feedback and help us upstream the patches. I'm 
> > reaching out to see if there are other folks reading webkit-dev who might 
> > be able to check on the work, see how it looks, and help us get this stuff 
> > upstream. We've been doing internal reviews, but unfortunately don't yet 
> > have any JSC reviewers on our team.
> > 
> > You can find the patch for instance class fields at 
> > https://bugs.webkit.org/show_bug.cgi?id=174212 
> > <https://bugs.webkit.org/show_bug.cgi?id=174212>. Any kind of constructive 
> > feedback (from anyone) would be much appreciated :)
> > 
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> > https://lists.webkit.org/mailman/listinfo/webkit-dev 
> > <https://lists.webkit.org/mailman/listinfo/webkit-dev>
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> <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] Exciting JS features (class fields) in need of review :)

[Maciej Stachowiak]

I left the boring review feedback that this work should be behind a feature 
flag. Mentioning it here because this may apply to other feature patches you 
have in progress. (I am not qualified to review the substance of what the patch 
is doing.)

> On Feb 13, 2019, at 1:51 PM, ca...@igalia.com wrote:
> 
> Hi WebKitters,
> 
> My colleagues at Igalia have been working on a number of JS language 
> features! We want WebKit to have implementations in order to provide feedback 
> for TC39, and to help meet the requirements to have them merged into the 
> specification proper.
> 
> Unfortunately, JSC suggested reviewers have been occupied for the past 6 
> months, unable to provide feedback and help us upstream the patches. I'm 
> reaching out to see if there are other folks reading webkit-dev who might be 
> able to check on the work, see how it looks, and help us get this stuff 
> upstream. We've been doing internal reviews, but unfortunately don't yet have 
> any JSC reviewers on our team.
> 
> You can find the patch for instance class fields at 
> https://bugs.webkit.org/show_bug.cgi?id=174212. Any kind of constructive 
> feedback (from anyone) would be much appreciated :)
> 
> ___
> 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] Rename Bugzilla's "WebKit2" component to "WebKit Process Model"

[Maciej Stachowiak]

> On Feb 6, 2019, at 9:48 AM, Lucas Forschler  wrote:
> 
> Thanks Ryosuke,
> 
> I’d be in favor of adding a Bugzilla component “WebKit Process Model”
> I believe Simon has also asked for a WKWebView component. (WKWebView 
> viewport/tiling/animated resize issues)
> 
> Would the two of these components be sufficient to replace WebKit2?

I would suggest we rename “WebKit API” to “Legacy WebKit API” and call the new 
component “WebKit API” rather than “WKWebView”.

 - Macie 

> 
> Lucas
> 
> 
>> On Feb 1, 2019, at 11:57 AM, Ryosuke Niwa > > wrote:
>> 
>> Hm... I think WebKit2 component is currently used to implement both WebKit 
>> Process Model as well as WKWebView / WebKit2 API.
>> 
>> So we probably need to split it into multiple components, one of which is 
>> WebKit Process Model.
>> 
>> - R. Niwa
>> On Fri, Feb 1, 2019 at 10:27 AM Lucas Forschler > > wrote:
>> Hello all,
>> 
>> I am modernizing/cleaning up our Bugzilla component names. The first one I’d 
>> to rename is the WebKit2 component. I would like to rename this component to 
>> “WebKit Process Model”. 
>> 
>> Are there any objections or concerns with this rename?
>> 
>> Thanks,
>> Lucas
>> 
>> ___
>> 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 mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Rename Bugzilla component "ANGLE" to "WebGL"

[Maciej Stachowiak]

ANGLE is a separate chunk of code, and one the we periodically sync with an 
upstream repository, so I am not sure this is a good idea.

> On Feb 1, 2019, at 10:59 AM, Lucas Forschler  wrote:
> 
> I just realized we already have a WebGL Bugzilla component. So I propose 
> deprecating the ANGLE component, and using WebGL moving forward.
> 
>> On Feb 1, 2019, at 10:47 AM, Lucas Forschler  wrote:
>> 
>> Hello all,
>> 
>> I would like to rename the Bugzilla component “ANGLE” to “WebGL”.
>> 
>> Are there any objections or concerns with this rename?
>> 
>> Thanks,
>> Lucas
>> 
>> 
>> ___
>> 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 mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Rename Bugzilla Component "Media Elements" to "Media"

[Maciej Stachowiak]

Sounds good to me.

> On Feb 1, 2019, at 10:52 AM, Lucas Forschler  wrote:
> 
> Hello all,
> 
> I propose renaming the Bugzilla component “Media Elements” to “Media”.
> 
> Are there any objections or concerns with this rename?
> 
> Thanks,
> Lucas
> ___
> 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] Compile error in WebGL2RenderingContext.cpp

[Maciej Stachowiak]

> On Jan 17, 2019, at 10:15 AM, Michael Catanzaro  wrote:
> 
> 
> 
> On Thu, Jan 17, 2019 at 11:12 AM, Darin Adler  wrote:
>> Vector’s inline capacity feature was originally created as an alternative to 
>> variable length arrays for most of the purposes people would want to put 
>> them.
> 
> Any advantages of this over std::array (which is widely-used in WebKit)?

std::array is fixed size. So you can’t do Darin’s described trick of using the 
stack for small enough cases but falling back to the heap for large cases, for 
a  buffer whose size is not known at compile time.

std::array seems fine to use for cases that are known to be fixed size at 
compile time. I would imagine it saves space by not having to separately track 
size and capacity. I don’t know if std::array holds its values inline or in an 
external heap buffer always. If it always uses a heap buffer, then it’s 
probably  worse than a normal C array for strictly local buffers. It could 
still be ok for fixed-size arrays stored in objects.

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

Re: [webkit-dev] the name "AtomicString"

[Maciej Stachowiak]

> On Dec 20, 2018, at 11:24 AM, Geoffrey Garen  wrote:
> 
 So hard to pronounce though! Why not UniqueString? It’s not quite as 
 explicit but close enough. 
>>> 
>>> Wouldn’t it be confusing to use UniqueString type for a string that is 
>>> *common* in order to save memory?
>> 
>> I would interpret it as UniqueString(foo) means “give me the unique copy of 
>> string foo”. You use a unique copy so you can use the same string in many 
>> places without wasting memory, or excess time on string compares. It’s used 
>> in many places, but there is only one. (Maybe we should call it 
>> HighlanderString? OK, not serious.)
> 
> By definition, any string that has been uniqued is unique.
> 
> So, maybe we like “unique” or maybe we don’t. But if we like “unique”, it’s 
> strictly better than “uniqued”.
> 
>>> Personally, I like the AtomString proposal as it is close to the naming we 
>>> are used to and addresses the issue raised (atomic has a different meaning 
>>> with threading).
>>> Also, I had never heard of interned strings before.
> 
> AtomicString has two features:
> 
> (1) You do comparison by pointer / object identity;
> 
> (2) You never allocate two objects for the same sequence of characters.
> 
> JavaScript symbols offer (1) but avoid (2):
> 
>   let a = Symbol(“The string of the past!”);
>   let b = Symbol(“The string of the past!”);
>   a == b; // false
>   a === b; // false
> 
> Today we call (1) “UniquedStringImpl” and (1) + (2) “AtomicStringImpl”.
> 
> If we rename (1) + (2) to “UniqueString” or “UniquedString”, we need a new 
> name for (1) alone.

It seems like (1) alone is not actually “uniqued". In the case of symbols at 
least, it's the opposite: the string deliberately kept distinct from all other 
strings of equal value, so pointer equality is used as a check for equality by 
pointer identity, rather than a shortcut for equality by value. 

From what I can tell, UniquedStringImpl exists mainly to be a base class for 
SymbolImpl and AtomicStringImpl. So you could imagine giving it a more verbose 
and explicit name, like PointerEqualityStringImpl. However, JSC seems to use 
UniquedStringImpl directly in a bunch of cases, I think to make it convenient 
for a property name to be either an AtomicString or a Symbol. Maybe a longer 
name for that case is ok?

Regards,
Maciej


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

Re: [webkit-dev] the name "AtomicString"

[Maciej Stachowiak]

> On Dec 19, 2018, at 9:41 PM, Chris Dumez  wrote:
> 
>> 
>> On Dec 19, 2018, at 9:17 PM, Maciej Stachowiak > <mailto:m...@apple.com>> wrote:
>> 
>> 
>> 
>>> On Dec 19, 2018, at 8:06 PM, Ryosuke Niwa >> <mailto:rn...@webkit.org>> wrote:
>>> 
>>> On Wed, Dec 19, 2018 at 1:13 PM Simon Fraser >> <mailto:simon.fra...@apple.com>> wrote:
>>> > On Dec 19, 2018, at 12:33 PM, Michael Catanzaro >> > <mailto:mcatanz...@igalia.com>> wrote:
>>> > 
>>> > On Tue, Dec 18, 2018 at 9:31 PM, Darin Adler >> > <mailto:da...@apple.com>> wrote:
>>> >> I’ve gotten used to the name AtomicString over the years, but I wouldn’t 
>>> >> strongly object to changing it if other programmers are often confused 
>>> >> by it’s similarity to the term “atomic operations”.
>>> > 
>>> > Well there were two other developers in the thread Ryosuke linked to who 
>>> > made the exact same mistake as me, so I do think the current name is 
>>> > problematic. A change wouldn't need to be drastic, though. I think 
>>> > suggestions from the old thread like "StringAtom" or "AtomString" would 
>>> > be unproblematic. The problem is the specific word "atomic" carries an 
>>> > expectation that the object be safe to access concurrently across threads 
>>> > without locks; I think that expectation doesn't exist if not for the "ic" 
>>> > at the end.
>>> > 
>>> > FWIW I've only ever heard the "interned string" terminology prior to now.
>>> 
>>> SingletonString?
>>> UniquedString?
>>> 
>>> I do like UniquedString. That conveys what AtomicString really is. 
>>> SingletonString isn't so great since AtomicString table is still per thread.
>> 
>> So hard to pronounce though! Why not UniqueString? It’s not quite as 
>> explicit but close enough. 
> 
> Wouldn’t it be confusing to use UniqueString type for a string that is 
> *common* in order to save memory?

I would interpret it as UniqueString(foo) means “give me the unique copy of 
string foo”. You use a unique copy so you can use the same string in many 
places without wasting memory, or excess time on string compares. It’s used in 
many places, but there is only one. (Maybe we should call it HighlanderString? 
OK, not serious.)

> 
> Personally, I like the AtomString proposal as it is close to the naming we 
> are used to and addresses the issue raised (atomic has a different meaning 
> with threading).
> Also, I had never heard of interned strings before.

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

Re: [webkit-dev] the name "AtomicString"

[Maciej Stachowiak]

> On Dec 19, 2018, at 8:06 PM, Ryosuke Niwa  wrote:
> 
> On Wed, Dec 19, 2018 at 1:13 PM Simon Fraser  > wrote:
> > On Dec 19, 2018, at 12:33 PM, Michael Catanzaro  > > wrote:
> > 
> > On Tue, Dec 18, 2018 at 9:31 PM, Darin Adler  > > wrote:
> >> I’ve gotten used to the name AtomicString over the years, but I wouldn’t 
> >> strongly object to changing it if other programmers are often confused by 
> >> it’s similarity to the term “atomic operations”.
> > 
> > Well there were two other developers in the thread Ryosuke linked to who 
> > made the exact same mistake as me, so I do think the current name is 
> > problematic. A change wouldn't need to be drastic, though. I think 
> > suggestions from the old thread like "StringAtom" or "AtomString" would be 
> > unproblematic. The problem is the specific word "atomic" carries an 
> > expectation that the object be safe to access concurrently across threads 
> > without locks; I think that expectation doesn't exist if not for the "ic" 
> > at the end.
> > 
> > FWIW I've only ever heard the "interned string" terminology prior to now.
> 
> SingletonString?
> UniquedString?
> 
> I do like UniquedString. That conveys what AtomicString really is. 
> SingletonString isn't so great since AtomicString table is still per thread.

So hard to pronounce though! Why not UniqueString? It’s not quite as explicit 
but close enough. 

Cheers,
Maciej

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

Re: [webkit-dev] Hash table empty value

[Maciej Stachowiak]

> On Dec 19, 2018, at 12:54 PM, Michael Catanzaro  wrote:
> 
> On Tue, Dec 18, 2018 at 2:31 PM, Ryosuke Niwa  wrote:
>> I tend to agree but then we'd come up with other numbers for the empty & 
>> deleted values.
>> I've been thinking that we could use -1 and -2 but that's also somewhat 
>> arbitrary restriction.
> 
> Using min/max values seems much safer. E.g. we already have in HashTraits.h:

I think that’s true for integers, but for pointers, 0 and -1 are likely safer 
(if you don’t need to store null pointers) or -1 and -2 if you do, since all 1 
bits is less likely to be a valid address. There’s also some optimization for 
the special case where the empty value is 0, but probably not that important if 
we often need to store null pointers. 

> // Default unsigned traits disallow both 0 and max as keys -- use these 
> traits to allow zero and disallow max - 1.
> template struct UnsignedWithZeroKeyHashTraits : 
> GenericHashTraits {
>   static const bool emptyValueIsZero = false;
>   static T emptyValue() { return std::numeric_limits::max(); }
>   static void constructDeletedValue(T& slot) { slot = 
> std::numeric_limits::max() - 1; }
>   static bool isDeletedValue(T value) { return value == 
> std::numeric_limits::max() - 1; }
> };
> 
> And:
> 
> template struct SignedWithZeroKeyHashTraits : 
> GenericHashTraits {
>   static const bool emptyValueIsZero = false;
>   static T emptyValue() { return std::numeric_limits::min(); }
>   static void constructDeletedValue(T& slot) { slot = 
> std::numeric_limits::max(); }
>   static bool isDeletedValue(T value) { return value == 
> std::numeric_limits::max(); }
> };
> 
> Which both seem much safer than the current default:
> 
> // Default integer traits disallow both 0 and -1 as keys (max value instead 
> of -1 for unsigned).
> template struct GenericHashTraitsBase : 
> GenericHashTraitsBase {
>   static const bool emptyValueIsZero = true;
>   static void constructDeletedValue(T& slot) { slot = static_cast(-1); }
>   static bool isDeletedValue(T value) { return value == static_cast(-1); }
> };
> 
> 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

Re: [webkit-dev] the name "AtomicString"

[Maciej Stachowiak]

> On Dec 19, 2018, at 12:33 PM, Michael Catanzaro  wrote:
> 
> On Tue, Dec 18, 2018 at 9:31 PM, Darin Adler  wrote:
>> I’ve gotten used to the name AtomicString over the years, but I wouldn’t 
>> strongly object to changing it if other programmers are often confused by 
>> it’s similarity to the term “atomic operations”.
> 
> Well there were two other developers in the thread Ryosuke linked to who made 
> the exact same mistake as me, so I do think the current name is problematic. 
> A change wouldn't need to be drastic, though. I think suggestions from the 
> old thread like "StringAtom" or "AtomString" would be unproblematic. The 
> problem is the specific word "atomic" carries an expectation that the object 
> be safe to access concurrently across threads without locks; I think that 
> expectation doesn't exist if not for the "ic" at the end.
> 
> FWIW I've only ever heard the "interned string" terminology prior to now.

“Interned string” is really obvious to people who have seen it but mysterious 
to those who have not. Unfortunately, I don’t think there is a term for this 
concept that most programmers will already know. So the best we can do is a 
term that is clearly something you need to look up and can’t be confused for 
something else. Another term of art name for this concept is Symbol. 
Unfortunately, search results for String, Atom and Atom String don’t give a 
helpful explanation, and Symbol could be confused with the JavaScript 
language’s notion of symbols. “Interned String” gives helpful search results, 
but is not the normal use of the terminology. Usually there is an operation 
called “intern”, or there might be reference to “string interning”, but it 
usually gives back just a plain string, or a type with a name like “atom” or 
“symbol”.

On balance, if we change, I’d lean towards Atom, since it is concise, obviously 
mysterious if you don’t know what it is, and understandable to at least some 
people who have seem that name for the concept. The only downside is that it’s 
not obvious from the name that it is a kind of string.

Regards,
Maciej

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

Re: [webkit-dev] Watch out for std::optional's move constructor

[Maciej Stachowiak]

Right now, after a maybeMove type call on std::optional, you get either the 
original value, or a value that is officially valid but unspecified, and 
actually an optional that says it contains a value but doesn’t. With Chris’s 
proposal, you’d get a WTF::Optional with either the original value, or an 
optional that doesn’t contain a value and says it doesn’t. Among other things, 
this allows for a “did anything actually get left here” check after the 
function that may or may not move a value. Seems like an upgrade.


> On Dec 17, 2018, at 3:55 PM, Alex Christensen  wrote:
> 
> Let me give a concrete example on why, even with our nice-to-use WTF types, 
> the state of a C++ object is undefined after being moved from:
> 
> #include 
> #include 
> #include 
> 
> class Test : public RefCounted { };
> 
> void useParameter(RefPtr&& param)
> {
>   RefPtr usedParam = WTFMove(param);
> }
> 
> void dontUseParameter(RefPtr&&) { }
> 
> int main() {
>   RefPtr a = adoptRef(new Test);
>   RefPtr b = adoptRef(new Test);
>   std::cout << "a null? " << !a << std::endl;
>   std::cout << "b null? " << !b << std::endl;
>   useParameter(WTFMove(a));
>   dontUseParameter(WTFMove(b));
>   std::cout << "a null? " << !a << std::endl;
>   std::cout << "b null? " << !b << std::endl;
>   return 0;
> }
> 
> // clang++ test.cpp -I Source/WTF -L WebKitBuild/Debug -l WTF -framework 
> Foundation -L /usr/lib -l icucore --std=c++17 && ./a.out  
>  
> // a null? 0  
>   
> // b null? 0  
>   
> // a null? 1  
>   
> // b null? 0  
>  
> 
> 
> As you can see, the internals of callee dontUseParameter (which could be in a 
> different translation unit) affects the state of the local variable b in this 
> function.  This is one of the reasons why the state of a moved-from variable 
> is intentionally undefined, and we can’t fix that by using our own 
> std::optional replacement.  If we care about the state of a moved-from 
> object, that is what std::exchange is for.  I think we should do something to 
> track and prevent the use of moved-from values instead of introducing our own 
> std::optional replacement.
> 
>> On Dec 17, 2018, at 2:47 PM, Ryosuke Niwa > > wrote:
>> 
>> Yeah, it seems like making std::optional more in line with our own 
>> convention provides more merits than downsides here. People are using 
>> WTFMove as if it's some sort of a swap operation in our codebase, and as 
>> Maciej pointed out, having rules where people have to think carefully as to 
>> when & when not to use WTFMove seems more troublesome than the proposed fix, 
>> which would mean this work for optional.
>> 
>> - R. Niwa
>> 
>> On Mon, Dec 17, 2018 at 2:24 PM Geoffrey Garen > > wrote:
>> I don’t understand the claim about “undefined behavior” here. As Maciej 
>> pointed out, these are our libraries. We are free to define their behaviors.
>> 
>> In general, “undefined behavior” is an unwanted feature of programming 
>> languages and libraries, which we accept begrudgingly simply because there 
>> are practical limits to what we can define. This acceptance is not a mandate 
>> to carry forward undefined-ness as a badge of honor. In any case where it 
>> would be practical to define a behavior, that defined behavior would be 
>> preferable to undefined behavior.
>> 
>> I agree that the behavior of move constructors in the standard library is 
>> undefined. The proposal here, as I understand it, is to (a) define the 
>> behaviors move constructors in WebKit and (b) avoid std::optional and use an 
>> optional class with well-defined behavior instead.
>> 
>> Because I do not ❤️ security updates, I do ❤️ defined behavior, and so I ❤️ 
>> this proposal.
>> 
>> Geoff
>> 
>>> On Dec 17, 2018, at 12:50 PM, Alex Christensen >> > wrote:
>>> 
>>> This one and the many others like it are fragile, relying on undefined 
>>> behavior, and should be replaced by std::exchange.  Such a change was made 
>>> in https://trac.webkit.org/changeset/198755/webkit 
>>>  and we probably need many 
>>> more like that, but we are getting away with relying on undefined behavior 
>>> which works for us in most places.
>>> 
 On Dec 17, 2018, at 11:24 AM, Chris Dumez >>> > wrote:
 
 
 
> On Dec 17, 2018, at 11:10 AM, Chris Dumez  

Re: [webkit-dev] Watch out for std::optional's move constructor

[Maciej Stachowiak]

> On Dec 16, 2018, at 8:37 PM, Chris Dumez  wrote:
> 
> 
>> On Dec 16, 2018, at 7:43 PM, Fujii Hironori  wrote:
>> 
>> I don't like the proposal because it encourages misuse of move.
>> We can use move only for values about to be destroyed.
> 
> Just for reference, there are close to 400 matches for "WTFMove(m_” in our 
> code base. People do seem to rely on the state of objects after being moved 
> out.
> I totally agree that the state of the object being moved out is not defined 
> by the C++ standard. However, so far, in WebKit, we’ve been careful with our 
> move-constructors.
> 
> I think that if we do not update std::optional’s move constructor, then I 
> worry we’ll keep having to fix bugs in the future due to its misuse. 
> Although, maybe this mail thread will help.
> 
> That being said, I agree with your and Daniel and we should use std::exchange 
> more. I think all the "WTFMove(m_” lines in our code bases should probably be 
> replaced with std::exchange.

I think it would be easier to enforce a rule of “always use WTF::Optional 
instead of std::optional” than a rule of “use std::exchange more, but sometimes 
you really need WTFMove(), but don’t use move when it would be wrong to do so”. 
Better to set up the code to create simple rules that don’t require judgment 
IMO.

> 
> 
>> 
>> I like Dan's suggestion. We should use std::exchange or std::optional::swap 
>> for the cases.
>> Or, what about adding a new method WTF::Optional::release() for the case?
>> 
>> ___
>> 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 mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Watch out for std::optional's move constructor

[Maciej Stachowiak]

> On Dec 16, 2018, at 3:47 PM, Daniel Bates  wrote:
> 
> 
> 
>> On Dec 14, 2018, at 3:52 PM, Chris Dumez > > wrote:
>> 
>> So to be clear, it is often not truly about using the value after it is 
>> moved. It is about expecting that the variable / member has been nulled out 
>> after moving it.
>> If I WTFMove() out a data member m_dataMember, I expect later on `if 
>> (m_dataMember)` to be false.
>> 
> 
> I do not mean to derail the discussion about whether or not we should have 
> our own std::optional that disengages on move. I am all for convenience. I 
> think expecting a valid “empty” state (*) when moving out a data member is an 
> anti-pattern and I propose that we should be using std::exchange() instead 
> (or any code analogous to doing std::exchange()) for these cases, including 
> the case in your original email and especially with data members as in 
>  >.

Expectations can’t be an anti-pattern, only code can be an anti-pattern. At the 
point of checking whether a value is “empty” by some definition, you may not 
know that someone has std::move()d it, and shouldn’t have to. So to deal with 
the bug-prone nature of check after std::move(), we can do one of these:

(1) Ban all use of std::move() unless it’s possible for some sort of static 
check to know that no one will examine the moved value
(2) Make sure we only use types that leave themselves in a state that meets 
expectations post-move().
(3) Try real hard not to make mistakes and hope for the best

Maybe there is an option I am missing? Out of these, I think (2) is likely the 
best, on the whole.

> 
> Why do I consider it an anti-pattern? See (*) and because the concept of 
> “moving" is not spec'ed to behave like this. Here’s one reference to the 
> spec’ed behavior and an example comparable to the one in your first email 
> (highlighting is my own for emphasis):
> 
> [[
> Unless otherwise specified, all standard library objects that have been moved 
> from are placed in a valid but unspecified state. That is, only the functions 
> without preconditions, such as the assignment operator, can be safely used on 
> the object after it was moved from:

Note that this is specified for “standard library objects”. There’s nothing 
wrong with choosing to give a stronger API contract for our own objects, and 
then to rely on it.

> std::vector  > v;
> std::string  str = 
> "example";
> v.push_back(std::move(str)); // str is now valid but unspecified
> str.back(); // undefined behavior if size() == 0: back() has a precondition 
> !empty()
> str.clear(); // OK, clear() has no preconditions
> 
> ]]
>  >
> 
> (*) What is the valid “empty” state for a type without a default constructor?
> 
> Dan
> 
>> --
>>  Chris Dumez
>> 
>> 
>> 
>> 
>>> On Dec 14, 2018, at 3:45 PM, Chris Dumez >> > wrote:
>>> 
>>> 
 On Dec 14, 2018, at 3:39 PM, Fujii Hironori >>> > wrote:
 
 
 On Sat, Dec 15, 2018 at 6:38 AM Chris Dumez >>> > wrote:
 
 I have now been caught twice by std::optional’s move constructor. 
 
  I don't understand how this could be useful? Do you want to use the value 
 after it is moved? I'd like to see these your code. Could you show me 
 these two patches?
>>> 
>>> This is the latest one: https://trac.webkit.org/changeset/239228/webkit 
>>> 
>>> 
>>> 
>>> ___
>>> 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 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] Proposal for Device-Specific Layout Tests

[Maciej Stachowiak]

> On Dec 12, 2018, at 2:20 PM, Jonathan Bedard  wrote:
> 
>> 
>> On Dec 12, 2018, at 11:16 AM, Maciej Stachowiak > <mailto:m...@apple.com>> wrote:
>> 
>> 
>> 
>>> On Dec 12, 2018, at 10:07 AM, Jonathan Bedard >> <mailto:jbed...@apple.com>> wrote:
>>> 
>>> Ryosuke and I discussed this on Monday, and in passing, Ryosuke mentioned 
>>> that he personally finds something like this:
>>> 
>>> .html
>>> -expected.txt
>>> -expected-.txt
>>> 
>>> more clear than the directory method I proposed. After implementing the 
>>> above approach in the patch uploaded to 
>>> <https://bugs.webkit.org/show_bug.cgi?id=192162 
>>> <https://bugs.webkit.org/show_bug.cgi?id=192162>>, I’m inclined to agree. 
>>> Ryosuke’s approach achieves everything we need for device-type specific 
>>> expected results.
>>> 
>>> This still doesn’t solve disagreements about how to organize test results 
>>> when a single test is run on multiple device types, but it seems like a 
>>> step in the right direction.
>> 
>> In my opinion, we should think about what kind of device and platform 
>> differences we expect, and see if it can be organized into a single model. 
>> It strikes me as odd to have two totally different ways to organize variant 
>> results. And we don’t necessarily need to consider different platforms to be 
>> only targets with different binaries.
> 
> I think that we have 4 major reasons for differing expected results on 
> different platforms:
>   1) Missing feature in the test harness
>   2) Feature differentiation
>   3) Bug (or quirk) from the device-type/platform/OS
>   4) Tests sensitive to screen size and graphics support (deep color, for 
> example)
> 
> #1 and #3 are well covered under our current scheme, and I haven’t seen these 
> types of differences connected to device type. #2 is usually connected to 
> platform, occasionally OS version and in a few notable cases, iPad vs iPhone. 
> #4 is pretty much exclusively tied to device type and is a difference that we 
> have mostly ignored.
> 
>> One issue with these flat device names is that they have no hierarchy. It 
>> was hard for me to tell if your iPhone 7 vs iPhone 8 example of a difference 
>> was real or just imaginary, but I’d expect more tests to be different for 
>> iPhone vs iPad than different for iPhone 7 vs iPhone 8, so it would be nice 
>> to have a hierarchy for iPhone as a device class with different types of 
>> iPhones under it.
> 
> The iPhone 7 vs iPhone 8 difference was contrived, but even now we have a set 
> of tests which must be run on an iPhone 7 instead of an iPhone SE because 
> iPhone 7 supports deep color. So there are definitely circumstances where 
> iPhones might have different expected results from other iPhones.
> 
> In this proposal, I haven’t detailed the specifics of parsing device types 
> because that code actually already exists for creating simulated devices. At 
> the moment, device types aren’t implemented as a hierarchy, they’re 
> implemented by creating objects which use an “is a” comparison. A log from a 
> simulator test run shows this pretty well 
> <https://build.webkit.org/builders/Apple%20iOS%2012%20Simulator%20Release%20WK2%20%28Tests%29/builds/1491/steps/layout-test/logs/stdio
>  
> <https://build.webkit.org/builders/Apple%20iOS%2012%20Simulator%20Release%20WK2%20(Tests)/builds/1491/steps/layout-test/logs/stdio>>.
> 
> Creating devices for iPhone SE running iOS 12
> 11:52:45.780 92192 Creating device 'Managed 0', of type iPhone SE running iOS 
> 12
> Creating devices for iPhone 7 running iOS 12
> 12:21:30.931 92192 Creating device 'Managed 0', of type iPhone 7 running iOS 
> 12
> Creating devices for iPad running iOS 12
> 12:21:49.425 92192 Creating device 'Managed 0', of type iPad (6th generation) 
> running iOS 12
> While I haven’t given an example of a generic iPhone expected result, all the 
> examples of iPad expected results have actually been that of a generic iPad, 
> ‘iPad (6th generation)’ would we an example of a non-generic iPad. iPhones 
> operate under a similar system, just as an ‘iPad (6th generation)’ uses 
> generic iPad expectations, so too would an ‘iPhone 7’ use generic iPhone 
> expectations, unless a more specific expected result was available. 

I’m thinking of this from the perspective of someone navigating the test 
directory manually, rather than the perspective of the bots. Tools can clearly 
deal with any layout we come up with, so it should be optimized first for human 
use.

> 
&g

Re: [webkit-dev] Proposal for Device-Specific Layout Tests

[Maciej Stachowiak]

> On Dec 12, 2018, at 10:07 AM, Jonathan Bedard  wrote:
> 
> Ryosuke and I discussed this on Monday, and in passing, Ryosuke mentioned 
> that he personally finds something like this:
> 
>   .html
>   -expected.txt
>   -expected-.txt
> 
> more clear than the directory method I proposed. After implementing the above 
> approach in the patch uploaded to 
>  >, I’m inclined to agree. 
> Ryosuke’s approach achieves everything we need for device-type specific 
> expected results.
> 
> This still doesn’t solve disagreements about how to organize test results 
> when a single test is run on multiple device types, but it seems like a step 
> in the right direction.

In my opinion, we should think about what kind of device and platform 
differences we expect, and see if it can be organized into a single model. It 
strikes me as odd to have two totally different ways to organize variant 
results. And we don’t necessarily need to consider different platforms to be 
only targets with different binaries.

One issue with these flat device names is that they have no hierarchy. It was 
hard for me to tell if your iPhone 7 vs iPhone 8 example of a difference was 
real or just imaginary, but I’d expect more tests to be different for iPhone vs 
iPad than different for iPhone 7 vs iPhone 8, so it would be nice to have a 
hierarchy for iPhone as a device class with different types of iPhones under it.

But of course, while a device hierarchy could be fit under a flat notion of OS, 
the trick is how to fit it with a sequence of OS versions. Using directories 
for OS versions but filename variations for devices classes seems weird to me, 
and maybe almost backwards. I’d expect many device class differences to be 
permanent (iPhone vs iPad for example), while OS version differences may be 
transitory, in that they are often quirks of an older OS that will not matter 
once we no longer support that OS.

I think it’s worth thinking through all the variations that would be needed for 
a few real tests (ideally ones that already vary by OS version but which would 
also vary by device type) and make a single model that makes sense.

Maybe we should just use filename variations for everything, since that 
naturally expresses independent variation along multiple dimensions, while 
directories can only represent a single hierarchy. The trick then would be 
figuring out the priority order. If I have -expected-ios-ipad.txt 
and -expected-ios12.txt, then which is the right one to use on an 
iOS 12 iPad? Maybe we could have a convention to make ambiguous variation like 
this an error, or else decide whether OS version or device should take priority.

Regards,
Maciej



> 
> Jonathan
> 
>> On Dec 4, 2018, at 5:41 PM, Alexey Proskuryakov > > wrote:
>> 
>> 
>> 
>>> 4 дек. 2018 г., в 16:43, Ryosuke Niwa >> > написал(а):
>>> 
>>> 
>>> On Tue, Dec 4, 2018 at 12:55 PM Jonathan Bedard >> > wrote:
>>> These directories would be along-side tests.
>>> 
>>> I don't like that platform-specific results are under LayoutTests/platform 
>>> and device-specific results are next to the tests. We should stick with 
>>> either convention, not mix them up.
>>> 
>>> If we were to match LayoutTests/platforms, we should probably put it under 
>>> LayoutTests/devices, or alternatively inside each platform's test 
>>> directory. Alternatively, I'd be fine if we moved platform specific results 
>>> to those subdirectories. But having both conventions used throughout would 
>>> be an insane mess.
>> 
>> I'm not ready to have an opinion about which approach is best, however I 
>> wanted to make a general comment about unification.
>> 
>> I think that the attempt to abstract all sorts of differences behind the 
>> "port" and "platform" concepts in webkitpy was short sighted. There are many 
>> subtle and not so subtle variations of behaviors (OS, OS family, specific OS 
>> version, build style, specific API used from the build when there are 
>> multiple options). Trying to represent these by god objects is creating a 
>> lot more inconsistency and confusion than necessary.
>> 
>> One good thing about platform directories is that we can specify inheritance 
>> order with these in a way that is somewhat meaningful. If we are to have an 
>> inheritance order for device types, then continuing with the approach would 
>> make sense. But if the rule is exact match, or best match, then storing them 
>> as -expected directories makes good sense to me.
>> 
>> - Alexey
>> 
> 
> ___
> 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] Freenode spam counter-measure

[Maciej Stachowiak]

I think I added Jon Davis to the access list a while ago but not sure.


> On Aug 5, 2018, at 4:43 PM, Dan Bernstein  wrote:
> 
> 
> 
>>> On Aug 5, 2018, at 3:20 PM, Darin Adler  wrote:
>>> 
>>> On Aug 5, 2018, at 2:38 AM, Philippe Normand  wrote:
>>> 
>>> Can one of the #webkit admin please set the +r mode on? This would help 
>>> reducing spam. Only messages from registered nicks would come through.
>> 
>> I tried this by typing this:
>> 
>>/msg ChanServ set #webkit restricted on
>> 
>> But ChanServ replied:
>> 
>>ChanServ: You are not authorized to perform this command.
>> 
>> I wonder who is authorized!?
> 
> Looks like the authorized people include Maciej Stachowiak and Timothy 
> Hatcher.
> ___
> 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] 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] Tips to build faster on Mac?

[Maciej Stachowiak]

You can also just cd to the WebCore directory and type make.

> On Mar 16, 2018, at 3:24 PM, youenn fablet  wrote:
> 
> If you have a full build and made changes to WebCore, you might only need to 
> recompile WebCore. With make for instance, one can do:
> make d -C Source/WebCore
> 
>   Y
> 
> On Fri, Mar 16, 2018 at 6:55 AM Danyao Wang  > wrote:
> Thanks Brian for the Xcode UI tip! So far I've always used build-webkit. I 
> didn't realize there could be a difference.
> 
> On Thu, Mar 15, 2018 at 6:01 PM, Brian Burg  > wrote:
> 
> 
> > On Mar 15, 2018, at 1:58 PM, Danyao Wang  > > wrote:
> >
> > Hi,
> >
> > Being new to WebKit development (and also switching from Linux to Mac), I 
> > find my workflow relatively clumsy. Building on a fresh checkout usually 
> > takes me 20+ minutes even on my 12-core Mac Pro. Fastest incremental builds 
> > are ~2 minutes. This adds a lot to the develop / test / debug cycle.
> 
> These build times seem normal. WebKit is a big project, and we don’t use 
> CMake/ninja by default when building for Cocoa ports.
> 
> Are you building via build-webkit on the command line? In my experience, 
> incremental builds are faster via Xcode’s UI.
> 
> > I heard the good folks from Igalia working on the GTK port use icecc. Has 
> > anyone used this on Mac? Any other productivity tips?
> >
> > Thanks!
> > Danyao
> > ___
> > 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 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] HSTS user tracking

[Maciej Stachowiak]

> On Mar 1, 2018, at 10:44 AM, Michael Catanzaro  wrote:
> 
> On Fri, Jan 5, 2018 at 3:11 PM, Brent Fulgham  wrote:
>> I´m sorry we haven´t been forthcoming with details. We have wanted to put 
>> together a blog post explaining our fix, but have been preoccupied with a 
>> number of other security issues.
>> I will make this my top priority, or at least give a rough overview to the 
>> webkit-security folks if we can´t put together a blog-worthy document fast 
>> enough.
>> Thanks,
>> -Brent
> 
> Hi,
> 
> It'd still be great to get some details about your strategy for mitigating 
> user tracking via HSTS.
> 
> It should be suitable for webkit-dev, rather than the private security list, 
> right?

I think we should still publish the blog post, if it's at all close to ready. 
Brent?

 - Maciej

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