[webkit-dev] Smart Pointer Analysis Tool for WebKit

2020-09-17 Thread Ryosuke Niwa
Hi all,

I’ve been working with Geoff (ggaren) and Jan Korous from Apple's compiler
team to create a static analyzer which detects dangerous use of ref counted
objects, and we’re looking for folks who are interested in trying out this
tool and helping us refine the tool. Please let me know if you’re
interested in using this tool & try applying code changes to WebKit. Our
goal is to eventually integrate this tool into buildbot and EWS so that we
can catch dangerous code before they get committed.

*What is Dangerous?*

So *what is* a *dangerous* use of ref counted objects you may ask? It’s any
use of which we can’t trivially conclude that it doesn’t lead to a
use-after-free.

For now, we don’t detect dangerous use of non-ref counted objects including
ones that can vend WeakPtr. It’s on us, humans, to decide which objects
need to be ref counted or need to be CanMakeWeakPtr.

Consider the following example. This code most certainly will lead to a
use-after-free of “parent” in the third line because the code doesn’t keep
the parent alive. Because isContentEditable updates style in some cases, it
could lead to arbitrary script execution which could remove the parent from
the document.

Node* parent = element->parentElement();
if (parent->isContentEditable())
parent->scrollIntoView();

In general, relying on a complex data structure such as DOM tree to keep
RefCounted objects alive while we call a non-trivial function is not safe.
All it takes for the code to have a use-after-free is for someone to start
updating style, layout, etc… inside the function either directly or
indirectly. And we don’t want to make WebKit development really hard by
forcing anyone who modifies a function to check every caller of the
function and their callers, etc… to make sure it’s safe to do so.

For this reason, it’s *dangerous* to store a raw pointer or a reference to
a ref counted object as a local variable and use it after calling a
non-trivial function. We did a similar analysis of a number of other
patterns and usage of ref counted objects in WebKit and came up with the
following basic rules for using ref counted objects in a safe manner. We’re
hoping that these rules would be eventually incorporated into our coding
style guideline: https://webkit.org/code-style-guidelines/

*Rules for Using Ref Counted Objects*


   1. Every data member to a ref counted object must use either Ref,
   RefPtr, or WeakPtr. webkit.NoUncountedMemberChecker
   

   2. Every ref counted base class, if it has a derived class, must define
   a virtual destructor. webkit.RefCntblBaseVirtualDtor
   

   3. Every ref counted object passed to a non-trivial function as an
   argument (including "this" pointer) should be stored as a Ref or RefPtr in
   the caller’s local scope unless it's an argument to the caller itself by
   transitive property [1]. alpha.webkit.UncountedCallArgsChecker
   

   4. Every ref counted object must be captured using Ref or RefPtr for
   lambda. webkit.UncountedLambdaCapturesChecker
   

   5. Local variables - we’re still working on this (
   https://reviews.llvm.org/D83259)


Below, I've dissected each one of these rules with the real warning emitted
by the analysis tool in development. Please let me know if you have any
comments / concerns.

--
(1) is pretty trivial. Every ref counted data member should be stored using
Ref, RefPtr, or WeakPtr since it would be not trivially obvious that life
cycles of two or more objects are correctly tied or managed together.

--
(2) is also pretty easy to understand. In the following example, if someone
destroys an instance of B using Ref, then it would result in an
undefined behavior.

struct A : public RefCounted {
Vector someData;
};

struct B : public A {
Vector otherData;
};

--

For (3), passing a ref counted object as a raw pointer or reference to a
function as an argument, the tool may generate a warning like this:

Source/WebCore/html/FormAssociatedElement.cpp:181:13: warning: [WebKit]
call argument is a raw pointers to a ref-countable type
[-Wfunction-arg-ptr-to-refcntbl]
setForm(findAssociatedForm((), originalForm.get()));
^

This warns that void setForm(HTMLFormElement*) is called with the result
of findAssociatedForm, which returns HTMLFormElement* without storing it
anywhere. If setForm can somehow cause HTMLFormElement to be deleted, then
this can result in the use-after-free in setForm.

void FormAssociatedElement::resetFormOwner()
{
RefPtr originalForm = m_form.get();
setForm(findAssociatedForm((), 

Re: [webkit-dev] PSA: Bit fields won't be packed on Windows if you mix types

2020-09-04 Thread Ryosuke Niwa
On Thu, Sep 3, 2020 at 11:15 PM Fujii Hironori 
wrote:

>
> On Fri, Sep 4, 2020 at 2:56 PM Ryosuke Niwa  wrote:
>
>> On Thu, Sep 3, 2020 at 10:11 PM Fujii Hironori 
>> wrote:
>>
>>>
>>> On Fri, Sep 4, 2020 at 1:31 PM Ryosuke Niwa  wrote:
>>>
>>>> Consecutive bit fields must use the same type.
>>>>
>>>
>>> RenderLayer is mixing bool and unsigned in the consecutive bit fields.
>>> They should use only uint8_t, right?
>>>
>>> https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/rendering/RenderLayer.h#L1263
>>>
>>
>> Under the proposed coding style guide, yes, although I highly doubt the
>> size of RenderLayer really matters.
>>
>>
> Do you mean your new rule is applicable only for performance
> critical parts?
>

No, I'm saying that applying the proposed guideline wouldn't necessarily
help memory usage cause RenderLayer is a really large object anyway.
It doesn't mean we shouldn't apply.

BTW, I don't like to idea adding a new rule, but keeping old
> style code. It introduces divergence between the guideline and
> actual code. Do we really need a new rule that one doesn't
> necessary have to follow?
>

We should follow the proposed guideline in new code but we typically don't
update existing code to match the new guideline when we introduce a new
coding style guideline.

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


Re: [webkit-dev] PSA: Bit fields won't be packed on Windows if you mix types

2020-09-03 Thread Ryosuke Niwa
On Thu, Sep 3, 2020 at 10:11 PM Fujii Hironori 
wrote:

>
> On Fri, Sep 4, 2020 at 1:31 PM Ryosuke Niwa  wrote:
>
>> Consecutive bit fields must use the same type.
>>
>
> RenderLayer is mixing bool and unsigned in the consecutive bit fields.
> They should use only uint8_t, right?
>
> https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/rendering/RenderLayer.h#L1263
>

Under the proposed coding style guide, yes, although I highly doubt the
size of RenderLayer really matters.

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


Re: [webkit-dev] PSA: Bit fields won't be packed on Windows if you mix types

2020-09-03 Thread Ryosuke Niwa
Hi all,

I'm going to resurrect this thread from 2012 and suggest that we introduce
a new coding style guide as it came up in https://webkit.org/b/216069.

It looks like we added the rule to only use signed or unsigned as the
underlying type of bit fields to our style checker in
https://trac.webkit.org/r87771 without much discussion on webkit-dev. The
problem of this rule is that the type of bit fields determine the size of
the padding in most compilers such as GCC and clang. In the following
example, sizeof(U) is 4 but sizeof(C) is 1.

struct U {
  unsigned x : 1;
};

struct C {
  unsigned char x : 1;
};

The rule I propose instead is as follows:

Consecutive bit fields must use the same type.

*Right*:
struct S {
uint8_t count : 7;
uint8_t valid : 1;
}

struct C {
uint32_t foo : 30;
uint32_t bar : 2;
}

*Wrong*:
struct S {
uint8_t count : 7;
bool valid : 1;
}

struct C {
uint32_t foo : 30;
uint8_t bar : 2;
}

- R. Niwa

On Thu, Mar 29, 2012 at 1:21 AM Ryosuke Niwa  wrote:

> Hi,
>
> Unlike gcc and clang, MSVC pads each consecutive member variables of the
> same type in bitfields. e.g. if you have:
> struct AB {
> unsigned m_1 : 31;
> bool m_2 : 1;
> }
> then *MSVC pads m_1 and allocates sizeof(unsigned) * 2 for AB* whereas
> gcc and clang only allocate sizeof(unsigned) * 1 for AB.
>
> This is *not a compiler bug*. It's a spec. compliant behavior, and may in
> fact have a better run-time performance in some situations. However, for
> core objects like RenderObject and InlineBox, allocating extra 4-8 bytes
> per each object is prohibitory expensive.
>
> In such cases, please *use the same POD type for all bitfield member
> variables*. (Storage class classifiers and variable qualifiers seem to
> have no effect on how variables are packed; e.g. mutable, const, etc...).
> For example, MSVC will allocate sizeof(unsigned) * 1 for AB if we rewrite
> the above code as:
> struct AB {
> unsigned m_1 : 31;
> unsigned m_2 : 1;
> }
>
> When you're making this change, *be sure to audit all code that assigns a
> non-boolean value to m_2* because implicit type coercion into boolean is
> no longer in effect. For example,
>
> AB ab;
> ab.m_2 = 2;
> puts(ab.m_2 ? "true" : "false");
>
> will print "true" before the change and will print "false" after the
> change. An easy way to ensure you've audited all such code is to add
> getters and setters for all bitfield member variables or wrap them in a
> special structure or class as done in
> http://trac.webkit.org/changeset/103353 and
> http://trac.webkit.org/changeset/104254.
>
> Best regards,
> Ryosuke Niwa
> Software Engineer
> Google Inc.
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Request for position on hasDroppedEntry in PerformanceObserverCallback

2020-08-31 Thread Ryosuke Niwa
This seems fine to me.

On Mon, Aug 31, 2020 at 9:09 AM Nicolás Peña  wrote:
>
> Hi,
>
> We'd like to request an official position on a very small addition to 
> PerformanceTimeline specification. We've added a hasDroppedEntry parameter to 
> PerformanceObserverCallback, which is in 
> https://w3c.github.io/performance-timeline/#the-performanceobserver-interface,
>  and logic for it in 
> https://w3c.github.io/performance-timeline/#queue-the-performanceobserver-task.
>  It lets a developer know when an entry has been dropped from a buffer that 
> the PerformanceObserver cares about. We reached this solution when discussing 
> https://github.com/w3c/performance-timeline/issues/169 in a WebPerf WG call.
> ___
> 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 Cookie Store API

2020-08-27 Thread Ryosuke Niwa
Hi,

On Thu, Aug 27, 2020 at 12:02 PM Ayu Ishii  wrote:
>
> We would like to ask for WebKit's official position on the Cookie Store API.
> Cookie Store API aims to improve the complexity and performance issues of 
> cookies today by providing an asynchronous alternative to document.cookie and 
> exposing HTTP cookies to service workers. Its interface also encourages 
> developers to make better decisions about security. More information can be 
> found on the explainer below. Chrome has implemented what is currently in the 
> spec, and is planning to ship that soon.

We're supportive of the idea of having an asynchronous cookie API.
However, we would need to review other aspects of this proposal, for
example, exposing it to service workers since that could have subtle
implications.

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


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

2020-08-25 Thread Ryosuke Niwa
Sorry for the late reply. We're going to review this feature.

- R. Niwa

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


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

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

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

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


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

2020-08-25 Thread Ryosuke Niwa
Our intern worked on the feature but I don't think anyone is actively
maintaining or developing the feature at the moment.

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

- R. Niwa

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


Re: [webkit-dev] Request for position on the Origin-Isolation header

2020-08-20 Thread Ryosuke Niwa
Hi,

On Thu, Aug 20, 2020 at 8:51 AM Domenic Denicola  wrote:
>
> Hello webkit-dev,
>
> I've been working on a new header called Origin-Isolation, which is a way of 
> allowing origins  to opt-out of using document.domain and cross-origin 
> sharing of WebAssembly.Module, and thus allowing the browser to put them into 
> an origin-keyed agent cluster instead of a site-keyed one. This could in turn 
> allow the browser to make better behind-the-scenes decisions for process 
> isolation, or other resource allocation decisions, since sites no longer have 
> any ways to synchronously communicate cross-origin.
>

We haven't had a chance to fully review the proposal but we didn't
find anything we'd immediately object to. It seems like a reasonable
idea.

I feel like I saw some discussions of also differentiating based on
protocol (treating http://webkit.org and https://webkit.org
differently). Do you know you've already had such a discussion and if
so what the outcome of that discussion was?

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


Re: [webkit-dev] Request for position on content-visibility

2020-08-14 Thread Ryosuke Niwa
Hi,

Sorry for the late reply. We're still reviewing this.

- R. Niwa

On Tue, May 26, 2020 at 12:00 PM Vladimir Levin  wrote:
>
> Hi,
>
> I'm asking for WebKit's position on CSS property content-visibility (spec 
> draft: https://drafts.csswg.org/css-contain-2/#content-visibility).
>
> We're currently implementing this in Chromium and intend to ship it in the 
> near future.
>
> Please let me know your thoughts,
> Vladimir Levin
> ___
> 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] debug-test-runner: Timed out waiting for notifyDone to be called

2020-08-13 Thread Ryosuke Niwa
On Thu, Aug 13, 2020 at 9:42 AM Benjamin King  wrote:
>
> Hi,
>
> I’m trying to run a LayoutTest case in the debugger using `debug-test-runner` 
> and it fails by timing out, see below. However, if I run `run-webkit-test` it 
> works. I read the WebKit wiki on debugging and searched google to no avail. 
> Any advice?
>
> ```
> % ./Tools/Scripts/debug-test-runner LayoutTests/webaudio/biquad-lowpass.html
> …
> (lldb) run
> …
> 2020-08-13 12:30:12.960868-0400 WebKitTestRunner[73700:1010133] [Loading] 
> 0x10a026020 - [pageProxyID=7, webPageID=8, PID=73704] 
> WebPageProxy::didCommitLoadForFrame: frameID = 3
> Content-Type: text/plain
> #PID UNRESPONSIVE - WebKitTestRunner (pid 73700)
> FAIL: Timed out waiting for notifyDone to be called

This appears to be a timeout caused by js-test.js or WebKitTestRunner
itself. I can reproduce the same issue but I can't tell why this
happens.

FWIW, passing --no-timeout to Tools/Scripts/debug-test-runner made it
work for me at least in debug builds:
./Tools/Scripts/debug-test-runner --debug --no-timeout
LayoutTests/webaudio/biquad-lowpass.html

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


Re: [webkit-dev] Request for feedback on CompressionStream and DecompressionStream

2020-08-12 Thread Ryosuke Niwa
Hi all,

This is a very belated reply but what's being proposed seems
reasonable to us (Apple's WebKit team). We would like to know more
about use cases, and how they might be deployed in real websites / use
cases but we don't see any major issues with it.

- R. Niwa

On Wed, Nov 27, 2019 at 11:18 PM Thomas Steiner  wrote:
>
> You can see DecompressionStream in action in unarchiver, this is the relevant 
> code snippet (run it in Chrome 79+ with the 
> chrome://flags/#native-file-system-api and the 
> chrome://flags/#enable-experimental-web-platform-features flags set).
>
> On Thu, Nov 28, 2019 at 6:07 AM Adam Rice  wrote:
>>
>> I am trying to gauge feedback on compression streams with a view to shipping 
>> them in Chromium.
>>
>> Very briefly, they are a way to do gzip and gunzip in the browser. Less 
>> briefly, the explainer 
>> https://github.com/WICG/compression/blob/master/explainer.md goes into some 
>> detail of the how and why. The specification 
>> https://wicg.github.io/compression/ gives verbose detail of how. You may 
>> also find the W3C TAG review 
>> https://github.com/w3ctag/design-reviews/issues/410 interesting.
>
> ___
> 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 emerging standard: Declarative Shadow DOM

2020-08-10 Thread Ryosuke Niwa
Hi,

Sorry for the late reply. I've been on a medical leave. I just
commented on https://github.com/whatwg/dom/issues/831

- R. Niwa

On Tue, Aug 4, 2020 at 4:26 PM Mason Freed  wrote:
>
> Hello WebKit folks,
>
> I just wanted to quickly ping this thread to see if there was any interest in 
> posting a position on declarative Shadow DOM. My original post here didn't 
> gather much feedback. :-)
>
> Thanks,
> Mason
>
>
> On Tue, May 26, 2020 at 12:11 PM Mason Freed  wrote:
>>
>> Hello WebKit!
>>
>> I would like to request an official WebKit position on the Declarative 
>> Shadow DOM proposal. There have been some great comments and discussion from 
>> WebKit folks on the issue thread, but it is a bit unclear whether the 
>> overall proposal is something WebKit would support. This was brought up and 
>> discussed, e.g., on the DOM spec PR here: 
>> https://github.com/whatwg/dom/pull/858#issuecomment-623735890
>>
>> Please see below for all of the relevant supporting documents and 
>> discussions.
>>
>> Explainer: 
>> https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md
>> WhatWG DOM Issue discussion: https://github.com/whatwg/dom/issues/831
>> HTML Spec PR: https://github.com/whatwg/html/pull/5465
>> DOM Spec PR: https://github.com/whatwg/dom/pull/858
>> TAG review: https://github.com/w3ctag/design-reviews/issues/494
>> Request for Mozilla Position: 
>> https://github.com/mozilla/standards-positions/issues/335
>>
>> Thanks,
>> Mason Freed
>>
> ___
> 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 Schemeful Same-Site

2020-08-10 Thread Ryosuke Niwa
Sorry for the late reply. We're going to review this.

- R. Niwa

On Thu, May 28, 2020 at 11:25 AM Steven Bingler  wrote:
>
> Hello WebKit-dev,
>
> I'm seeking WebKit's position on Schemeful Same-Site. I've provided the 
> explainer [1], spec [2], TAG review [3], and Blink's I2P [4] which contains 
> some additional discussion you may find useful.
>
> Thanks,
> Steven
>
> [1] Explainer: https://github.com/sbingler/schemeful-same-site
> [2] Spec: 
> https://mikewest.github.io/cookie-incrementalism/draft-west-cookie-incrementalism.html#rfc.section.3.3
> [3] TAG Review: https://github.com/w3ctag/design-reviews/issues/497
> [4]  Blink I2P: 
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/qB7DKqxkiaA
> ___
> 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 Event Timing

2020-08-08 Thread Ryosuke Niwa
On Fri, Aug 7, 2020 at 2:09 PM Rob Buis  wrote:
>
> I was not aware of Long Tasks API. However it seems to have a slightly
> different focus (task vs. input events). Also I am mostly interested in
> First Input Delay, and it was decided some time ago to not put it in
> Long Tasks API (see
> https://docs.google.com/document/d/1bYMLTkjcyOZR5Jt3vrulzMSoS32zOFtwyH33f6hW_C8/edit#).

The concern still withstands. We don't have dozens of slightly
different APIs that websites need to track for junks & delays during
user interactions.

It's also unclear how this first input delay works with a single page
app which may have multiple transitions after a single page load from
the browser engine's perspective. There had been some discussions
about this in the past in Web Perf WG but I don't think we've come to
any conclusion about it.

In general, I'm hesitant to have any of these APIs implemented in
WebKit without figuring out more coherent picture of how they'd all
fit together to address underlying use cases.

- R. Niwa

> On 06.08.20 20:07, Simon Fraser wrote:
> > Our feedback is that this API seems reasonable, but that there's overlap 
> > with the "long tasks" API,
> > and it's not clear if we need both.
> >
> > Simon
> >
> >> On Aug 6, 2020, at 10:43 AM, Rob Buis  wrote:
> >>
> >> Hi Webkit-Dev,
> >>
> >> I would like to get an official position from Webkit on the Event Timing 
> >> Web Perf API.
> >> Besides providing information about input event latency it can be used to 
> >> obtain
> >> First Input Timing metrics. This specification builds on the Performance 
> >> Timeline
> >> specification, which is implemented in Webkit. Chrome has implemented the 
> >> Event
> >> Timing API, see the chrome status entry below.
> >>
> >> - Specification: https://wicg.github.io/event-timing/
> >> - Explainer: https://github.com/WICG/event-timing
> >> - MDN: 
> >> https://developer.mozilla.org/en-US/docs/Web/API/PerformanceEventTiming
> >> - ChromeStatus: https://chromestatus.com/feature/5167290693713920
> >> - Caniuse.com URL: https://caniuse.com/#feat=mdn-api_performanceeventtiming
> >>
> >> Regards,
> >>
> >> Rob.
> >> ___
> >> 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] Request for Webkit position for Imperative Shadow DOM Distribution API

2020-08-06 Thread Ryosuke Niwa
On Sun, Aug 2, 2020 at 9:42 PM Yu Han  wrote:

> Thanks Ryosuke.  You mean  > the ability to assign an arbitrary descendant
> node of a shadow *host* to be assigned to a slot, right?
>

Yes, that's what I mean.

I saw your proposal in the issue discussion and I think it'll definitely
> improve ergonomics for web developers. Let's do it in the next version of
> the Imperative slot API.
>

Cool.

- R. Niwa

On Sat, Aug 1, 2020 at 12:09 AM Ryosuke Niwa  wrote:
>
>> Hi Yu,
>>
>> I've reviewed your PRs and they look okay. We still prefer having the
>> ability to assign an arbitrary descendant node of a shadow root to be
>> assigned to a slot since there are a number of user cases we care about
>> that could be addressed with such a capability but what's currently being
>> proposed doesn't preclude that possibility in the future as far as I could
>> tell.
>>
>> - R. Niwa
>>
>> On Thu, Jul 30, 2020 at 10:28 AM Yu Han  wrote:
>>
>>> Hi Webkit-Dev,
>>>
>>> We would like to get an official position from webkit for Imperative
>>> Shadow DOM Distribution API. This proposal was discussed in the last TPAC
>>> F2F <https://github.com/whatwg/html/issues/3534#issuecomment-537802687>.
>>> And Chrome has implemented this API based on the F2F summary.
>>>
>>>
>>>- Specification Title: Imperative Shadow DOM Distribution API
>>>   - Explainer
>>>   
>>> <https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Imperative-Shadow-DOM-Distribution-API.md>
>>>   - Spec PRs for HTML <https://github.com/whatwg/html/pull/5483>
>>>and DOM <https://github.com/whatwg/dom/pull/860>
>>>   - WhatWG DOM issue discussion
>>>   <https://github.com/whatwg/html/issues/3534>.
>>>   - TAG Review <https://github.com/w3ctag/design-reviews/issues/486>
>>>   .
>>>   - ChromeStatus <https://chromestatus.com/feature/5711021289242624>
>>>- Caniuse.com URL (optional):
>>>- Bugzilla URL (optional):
>>>- Mozillians who can provide input (optional):
>>>
>>> Other information
>>>
>>> The imperative Shadow DOM distribution API allows developers to
>>> explicitly set the assigned nodes for a slot element. With this API, web
>>> developers can create web components without needing to add a specific
>>> markup, slot="" attribute, to children of the host component. In addition,
>>> it enables conditional slotting based on either environmental state or an
>>> attribute passed in.
>>>
>>> More details, including more motivating uses cases, can be found in the
>>> explainer
>>> <https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Imperative-Shadow-DOM-Distribution-API.md>
>>> .
>>>
>>> Example syntax:
>>>
>>> 
>>>
>>>
>>>
>>>
>>> class CustomTab extends HTMLElement {
>>> static get observedAttributes() {
>>>   return ['show-tab'];
>>> }
>>> constructor() {
>>> super();
>>> const shadowRoot = this.attachShadow({mode: 'open', slotAssignment: 
>>> 'manual'});
>>> shadowRoot.innerHTML = `
>>> `;
>>> }
>>> attributeChangedCallback(name, oldValue, newValue) {
>>> UpdateDisplayTab(this, newValue);
>>> }
>>> connectedCallback() {
>>> if (!this._observed) {
>>>const target = this;
>>>const showTab = this.getAttribute('show-tab');
>>>const observer = new MutationObserver(function(mutations) {
>>> UpdateDisplayTab(target, showTab);
>>> });
>>> observer.observe(this, {childList: true});
>>> this._observed = true;
>>> }
>>> }}
>>> function  UpdateDisplayTab(elem, tabIdx) {
>>> const shadow = elem.shadowRoot;
>>> const slot = shadow.querySelector("slot");
>>> const panels = elem.querySelectorAll('tab-panel');
>>> if (panels.length && tabIdx && tabIdx <= panels.length ) {
>>>   slot.assign([panels[tabIdx-1]]);
>>> } else {
>>>   slot.assign([]);
>>> }}
>>>
>>> thanks,
>>>
>>> Han
>>> ___
>>> 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 Event Timing

2020-08-06 Thread Ryosuke Niwa
I'm generally concerned about the proliferation of all these X timing API.
It's hard to review the aspect of "first input timing" because its
definition is imprecise: https://github.com/WICG/event-timing/issues/91

On Thu, Aug 6, 2020 at 11:07 AM Simon Fraser  wrote:

> Our feedback is that this API seems reasonable, but that there's overlap
> with the "long tasks" API,
> and it's not clear if we need both.
>
> Simon
>
> > On Aug 6, 2020, at 10:43 AM, Rob Buis  wrote:
> >
> > Hi Webkit-Dev,
> >
> > I would like to get an official position from Webkit on the Event Timing
> Web Perf API.
> > Besides providing information about input event latency it can be used
> to obtain
> > First Input Timing metrics. This specification builds on the Performance
> Timeline
> > specification, which is implemented in Webkit. Chrome has implemented
> the Event
> > Timing API, see the chrome status entry below.
> >
> > - Specification: https://wicg.github.io/event-timing/
> > - Explainer: https://github.com/WICG/event-timing
> > - MDN:
> https://developer.mozilla.org/en-US/docs/Web/API/PerformanceEventTiming
> > - ChromeStatus: https://chromestatus.com/feature/5167290693713920
> > - Caniuse.com URL:
> https://caniuse.com/#feat=mdn-api_performanceeventtiming
> >
> > Regards,
> >
> > Rob.
> > ___
> > 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] Request for Webkit position for Imperative Shadow DOM Distribution API

2020-08-01 Thread Ryosuke Niwa
Hi Yu,

I've reviewed your PRs and they look okay. We still prefer having the
ability to assign an arbitrary descendant node of a shadow root to be
assigned to a slot since there are a number of user cases we care about
that could be addressed with such a capability but what's currently being
proposed doesn't preclude that possibility in the future as far as I could
tell.

- R. Niwa

On Thu, Jul 30, 2020 at 10:28 AM Yu Han  wrote:

> Hi Webkit-Dev,
>
> We would like to get an official position from webkit for Imperative
> Shadow DOM Distribution API. This proposal was discussed in the last TPAC
> F2F .
> And Chrome has implemented this API based on the F2F summary.
>
>
>- Specification Title: Imperative Shadow DOM Distribution API
>   - Explainer
>   
> 
>   - Spec PRs for HTML  and
>   DOM 
>   - WhatWG DOM issue discussion
>   .
>   - TAG Review .
>   - ChromeStatus 
>- Caniuse.com URL (optional):
>- Bugzilla URL (optional):
>- Mozillians who can provide input (optional):
>
> Other information
>
> The imperative Shadow DOM distribution API allows developers to explicitly
> set the assigned nodes for a slot element. With this API, web developers
> can create web components without needing to add a specific markup, slot=""
> attribute, to children of the host component. In addition, it enables
> conditional slotting based on either environmental state or an attribute
> passed in.
>
> More details, including more motivating uses cases, can be found in the
> explainer
> 
> .
>
> Example syntax:
>
> 
>
>
>
>
> class CustomTab extends HTMLElement {
> static get observedAttributes() {
>   return ['show-tab'];
> }
> constructor() {
> super();
> const shadowRoot = this.attachShadow({mode: 'open', slotAssignment: 
> 'manual'});
> shadowRoot.innerHTML = `  
>   `;
> }
> attributeChangedCallback(name, oldValue, newValue) {
> UpdateDisplayTab(this, newValue);
> }
> connectedCallback() {
> if (!this._observed) {
>const target = this;
>const showTab = this.getAttribute('show-tab');
>const observer = new MutationObserver(function(mutations) {
> UpdateDisplayTab(target, showTab);
> });
> observer.observe(this, {childList: true});
> this._observed = true;
> }
> }}
> function  UpdateDisplayTab(elem, tabIdx) {
> const shadow = elem.shadowRoot;
> const slot = shadow.querySelector("slot");
> const panels = elem.querySelectorAll('tab-panel');
> if (panels.length && tabIdx && tabIdx <= panels.length ) {
>   slot.assign([panels[tabIdx-1]]);
> } else {
>   slot.assign([]);
> }}
>
> thanks,
>
> Han
> ___
> 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] Introducing a minimum ICU version for WebKit

2020-04-03 Thread Ryosuke Niwa
On Fri, Apr 3, 2020 at 4:25 PM Kirsling, Ross 
wrote:

> Hi everybody,
>
>
>
> Just sending out an email blast for visibility regarding
> https://bugs.webkit.org/show_bug.cgi?id=209694.
>
>
>
> This patch:
>
>- Upgrades the Mac ICU headers under Source/WTF/icu from ICU 55 to ICU
>62, matching Mojave
>- Introduces a minimum ICU version of 60.2 throughout the codebase, as
>required by GTK for Ubuntu 18.04 LTS
>
>
>
> As written in the ChangeLog, the immediate motivations are:
>
>1. To properly establish a minimum ICU version for WebKit as a whole
>(responding to a pain point identified in
>https://bugs.webkit.org/show_bug.cgi?id=209579)
>2. To support the development of ECMA-402 Intl API features, which JSC
>is quite behind on
>(and which often boil down to exposing ICU functionality to JavaScript)
>
>
>
> The only remaining concern of which I am aware is that AppleWin’s ICU
> headers, stored in WebKitAuxiliaryLibrary.zip, need to be upgraded from ICU
> 49 to 62 (to match the lib files stored in WebKitSupportLibrary.zip). We do
> have a potential workaround for this (i.e. having CMake copy the Mac
> headers to WebKitLibraries/win) but it is feared that this may break
> Apple-internal builds and we would certainly like to avoid a revert if
> possible. Any help on this front would be greatly appreciated.
>
>
FWIW, I've been told that Brent / Per might be able to help you there but
might need some more time due to other more urgent commitments.

- R. Niwa
___
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

2020-03-11 Thread Ryosuke Niwa
On Wed, Mar 4, 2020 at 10:53 PM Noam Rosenthal  wrote:
>
>
> On Thu, Mar 5, 2020 at 4:24 AM Maciej Stachowiak  wrote:
>>
>>>
>> There has been a lot of work done on the spec front since the comments 
>> above, and I think we're ready for a re-review the state.
>> * The next pull request: https://github.com/whatwg/html/pull/5112 has been 
>> thumbed up to make it into the HTML spec, and is separate from client-hints, 
>> but requires second implementor interest, which is what this email thread is 
>> for :)
>>
>>
>> I don’t think it has? I’m seeing:
>> "[ ]  At least two implementers are interested (and none opposed):”
>>
>>
>> And satisfying this is a requirement for adding features to WHATWG Living 
>> Standards.
>>
>> And the review block at the bottom says “Review required” and “Merging is 
>> Blocked with big red X’s.
>
> Yes, see the last comment from the reviewer: "I guess the main things 
> remaining are implementer interest and someone verifying the test coverage. 
> (Happy to help with the latter once the former is sorted.) "

Just to close the loop here, I don't think we're interested in
supporting this header given the layering violation we've pointed out
in the past at this point.

- R. Niwa
___
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'?

2020-03-06 Thread Ryosuke Niwa
On Fri, Mar 6, 2020 at 6:15 PM Kirsling, Ross  wrote:
>
> 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’.

I think the ship has sailed on this one. People who have been working
on the WebKit project for long enough are so used to the phrase
"rollout a patch" that it's gonna be tricky to change the terminology.
Having said that, I'd much prefer the term "revert" over "rollout" or
"rollback". It's also the term git uses.

> 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).

As a non-native speaker myself, I never find this term confusing
because I have no mental model of what "rollout" or "rollback" means.
However, I find those two terms infinitely more confusing than the
very direct "revert".

- R. Niwa
___
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)

2020-03-03 Thread Ryosuke Niwa
On Tue, Mar 3, 2020 at 12:31 AM Noam Rosenthal  wrote:

>
> On Tue, Mar 3, 2020 at 10:18 AM Ryosuke Niwa  wrote:
>
>> Sorry for the delay. I had other other things to take care of first.
>>
>> Based on the discussion we had (between Maciej, Simon, Alan, and I), we
>> should take the following items into account for WebKit's first meaningful
>> paint heuristics:
>>
>>- Background image
>>
>> I've filed https://bugs.webkit.org/show_bug.cgi?id=208501 and can get it
> done.
> Btw if there's something I'm taking on myself but Apple would rather do or
> vice versa, please let me know :)
>

Great. I've cc'ed a few more folks.

>
>>- SVG images
>>- "Contentful" canvas once we rigorously defined what it means:
>>https://github.com/w3c/paint-timing/issues/50
>>- First frame / poster image of a video:
>>https://github.com/w3c/paint-timing/issues/51
>>
>> Then as Maciej pointed out there are a few spec works to do:
>>
>>- WebKit takes any text regardless of whether they appear within UA
>>shadow root or not into account for the first meaningful paint. The spec
>>needs to clarify this behavior -
>>https://github.com/w3c/paint-timing/issues/52
>>- The exact timing of navigation should be defined -
>>https://github.com/w3c/paint-timing/issues/19
>>- Clarify whether "first paint" or "first content paint" ever happens
>>to a blank page - https://github.com/w3c/paint-timing/issues/53
>>- Clarify what happens to a page which consists of just an iframe -
>>https://github.com/w3c/paint-timing/issues/54
>>- Combination of paint timing and long tasks can expose precise paint
>>timing - https://github.com/w3c/paint-timing/issues/55
>>
>> To supplement earlier Maciej's points, per our discussion, we don't think
>> "first paint" is a good metric to expose to the Web since Safari / WebKit
>> users would never see that. If any website optimize for the first paint
>> metrics instead of or at the cost of first contentful paint, then such an
>> optimization would only result in perceived regressions for our users.
>>
> I've spoken with the Wikipedia folks on this and they agree, first-paint
> is not really that useful as a performance metric (I think it's useful to
> catch bugs, e.g. in cases where it's vastly behind first-contentful-paint).
> For now I'm focusing only on the first-contentful-paint metric, and adding
> web platform tests to cover this situation (the current tests would fail in
> the case where FP is not implemented).
>

Sounds great to me.

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.

- R. Niwa
___
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)

2020-03-03 Thread Ryosuke Niwa
Sorry for the delay. I had other other things to take care of first.

Based on the discussion we had (between Maciej, Simon, Alan, and I), we
should take the following items into account for WebKit's first meaningful
paint heuristics:

   - Background image
   - SVG images
   - "Contentful" canvas once we rigorously defined what it means:
   https://github.com/w3c/paint-timing/issues/50
   - First frame / poster image of a video:
   https://github.com/w3c/paint-timing/issues/51

Then as Maciej pointed out there are a few spec works to do:

   - WebKit takes any text regardless of whether they appear within UA
   shadow root or not into account for the first meaningful paint. The spec
   needs to clarify this behavior -
   https://github.com/w3c/paint-timing/issues/52
   - The exact timing of navigation should be defined -
   https://github.com/w3c/paint-timing/issues/19
   - Clarify whether "first paint" or "first content paint" ever happens to
   a blank page - https://github.com/w3c/paint-timing/issues/53
   - Clarify what happens to a page which consists of just an iframe -
   https://github.com/w3c/paint-timing/issues/54
   - Combination of paint timing and long tasks can expose precise paint
   timing - https://github.com/w3c/paint-timing/issues/55

To supplement earlier Maciej's points, per our discussion, we don't think
"first paint" is a good metric to expose to the Web since Safari / WebKit
users would never see that. If any website optimize for the first paint
metrics instead of or at the cost of first contentful paint, then such an
optimization would only result in perceived regressions for our users.

- R. Niwa
___
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

2020-02-26 Thread Ryosuke Niwa
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.

 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/

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).
>

We should probably adopt the same 5 business day policy here.

II/ Intent to prototype template
>

I don't think a template is necessary. We don't have a template for
nominating reviewer, committer, etc...

We should just have a list of topics / details / information each email
should contain. We should probably have:

   - Summary of new feature / behavior change
   - Bug URL
   - Spec URL / PR / Issue
   - Status in other browsers

I really don't think links to the related emails on webkit-dev, etc... is
necessary because anyone interested in a given feature / behavior change
will surely check the bug, etc...

On the other hand, we should probably also create a way to track all these
new features and behavior changes in some central place. For new Web facing
features, we have: https://webkit.org/status/

We should probably create some other page / tracking tool where all
behavior changes to existing Web APIs are tracked. And updating of
https://webkit.org/status/ as well as this new tracking tool should
probably a part of the requirement of adding a new feature / making a Web
facing behavioral change.

- R. Niwa
___
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)

2020-02-26 Thread Ryosuke Niwa
On Wed, Feb 26, 2020 at 9:00 PM Maciej Stachowiak  wrote:

>
>
> On Feb 26, 2020, at 2:25 PM, Ryosuke Niwa  wrote:
>
>
> On Wed, Feb 26, 2020 at 11:29 AM Maciej Stachowiak  wrote:
>
>>
>>
>> On Feb 26, 2020, at 10:51 AM, Noam Rosenthal 
>> wrote:
>>
>>
>>
>> On Wed, Feb 26, 2020 at 8:08 PM Maciej Stachowiak  wrote:
>>
>>>
>>> Some quick comments:
>>>
>>
>>> the definition of First Contentful Paint here in the spec: <
>>> https://www.w3.org/TR/paint-timing/#sec-terminology> does not match the
>>> definition stated at <https://web.dev/first-contentful-paint/>. 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?
>>>
>> 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, 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, 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).
>

Well, WebKit does have heuristics like the number of characters that have
been laid out to gate the initial paint whereas Blink makes no such
attempts for having the first contentful paint (it just means the painted
content has something more than pure white / blank tile).

Note (for folks not familiar with WebKit's navigation / painting model)
that, by definition, WebKit's first painting of a newly navigated page *is*
the first contentful paint and also the first paint because we never even
attempt to paint the page until then (if we did paint the newly navigated
page prior to that point, that'd be considered as a bug).

- R. Niwa
___
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)

2020-02-26 Thread Ryosuke Niwa
On Wed, Feb 26, 2020 at 10:54 AM Noam Rosenthal  wrote:

> (resending from correct address)
> On Wed, Feb 26, 2020 at 8:08 PM Maciej Stachowiak  wrote:
>
>>
>> Some quick comments:
>>
>
>> the definition of First Contentful Paint here in the spec: <
>> https://www.w3.org/TR/paint-timing/#sec-terminology> 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?
>>
> 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, 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, 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 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.

Second off, the point of specification is to allow multiple independent
implementations. If we had to reverse-engineer what Chrome is doing and
implement that, it defeats the point of having any standard at all.

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.
>

I don't think we don't should that because we don't have an equivalent of
first-paint.

- R. Niwa
___
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)

2020-02-26 Thread Ryosuke Niwa
On Wed, Feb 26, 2020 at 11:29 AM Maciej Stachowiak  wrote:

>
>
> On Feb 26, 2020, at 10:51 AM, Noam Rosenthal 
> wrote:
>
>
>
> On Wed, Feb 26, 2020 at 8:08 PM Maciej Stachowiak  wrote:
>
>>
>> Some quick comments:
>>
>
>> the definition of First Contentful Paint here in the spec: <
>> https://www.w3.org/TR/paint-timing/#sec-terminology> 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?
>>
> 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, 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, 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.

- 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
> 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 Badging API

2020-02-20 Thread Ryosuke Niwa
On Wed, Feb 19, 2020 at 4:32 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”.
>>&

Re: [webkit-dev] WebKit position on Wake Lock API

2020-02-19 Thread Ryosuke Niwa
On Tue, Feb 18, 2020 at 5:23 AM Thomas Steiner  wrote:

> On Sat 21. Dec 2019 at 02:18 Ryosuke Niwa  wrote:
>
>> We'll be discussing this internally at Apple but since we're heading into
>> the holiday shutdown, we probably won't be able to get back to you until
>> sometime next month.
>>
>
> Hello Ryosuke,
>
> Have you or someone else from the team had a chance to look at this?
> Please note that we’re currently exclusively look for the “screen” wake
> lock case, not the “system” case.
>

I'm still soliciting a feedback.

For now, I can say we're very much concerned about any impact on battery
life since that's no.1 thing our users care about. Since even a few
percentage point of battery life regression would be a major concern,
there *needs
to be extraordinarily good reasons* to add this API; I just don't think any
of the use cases listed in https://w3c.github.io/wake-lock/#introduction are
compelling enough to meet such a standard.

- R. Niwa
___
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

2020-02-18 Thread Ryosuke Niwa
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.

 * 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.

As such, this feature isn't going to work on either platform as currently
proposed.

- R. Niwa

On Sun, Jan 19, 2020 at 16:27 Matt Giuca  wrote:
>>
>>> Hi WebKit team,
>>>
>>> I have previously proposed the Badging API (
>>> https://github.com/WICG/badging) to provide websites with a mechanism
>>> to set a badge (a small dot or number) on the current document's tab, or
>>> for installed applications, on the app icon in the system shelf or home
>>> screen.
>>>
>>> Would WebKit / Safari be interested in implementing the API now or in
>>> the future?
>>>
>>> We are planning to ship in Chromium soon:
>>>
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/fHc49JNFTAU/m/bJD25Yr7CAAJ
>>>
>>> Regards
>>>
>>>
>>> Matt Giuca
>>> ___
>>> 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


Re: [webkit-dev] Clearing old reviews from the queue

2020-02-16 Thread Ryosuke Niwa
Sounds reasonable to me although I’d suggest older than 1 year instead of 6
months since I don’t think 6 months is long enough to render a patch
completely obsolete in many cases.

- R. Niwa

On Sun, Feb 16, 2020 at 07:53 Dean Jackson  wrote:

> Does anyone oppose clearing all review requests that are older than 6
> months? (or 1 year?)
>
> I tried to use the bugzilla API to do this, but I couldn't work out how to
> detect the attachment state properly. I looked at the source code for the
> queue page and it uses custom SQL :)
>
> (It's easy to do with the GitHub API)
>
> Dean
>
> ___
> 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


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

2020-02-16 Thread Ryosuke Niwa
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.
 * We don’t want every website to start using this API to increase
“engagement”.

- R. Niwa

On Sun, Jan 19, 2020 at 16:27 Matt Giuca  wrote:

> Hi WebKit team,
>
> I have previously proposed the Badging API (
> https://github.com/WICG/badging) to provide websites with a mechanism to
> set a badge (a small dot or number) on the current document's tab, or for
> installed applications, on the app icon in the system shelf or home screen.
>
> Would WebKit / Safari be interested in implementing the API now or in the
> future?
>
> We are planning to ship in Chromium soon:
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/fHc49JNFTAU/m/bJD25Yr7CAAJ
>
> Regards
>
>
> Matt Giuca
> ___
> 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


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

2020-01-22 Thread Ryosuke Niwa
On Wed, Jan 22, 2020 at 12:23 AM François Beaufort  <
fbeauf...@google.com> wrote:

> Maciej said earlier they could provide more details if desired.
>

Well, you have to tell us what details you're looking for.

Would you have any alternative ideas that would help ordinary people
> understand the full security & privacy implications of granting NFC access?
>

I can't imagine how given most people don't know what NFC is.

I'll go off a bit on a tangent and say that one of the primary strengths of
the Web is that users can visit any website without the fear of their
computing devices being permanently compromised. Unfortunately, APIs such
as Web NFC, Web USB, Web Serial API would pose new threats for persistent
attacks on external devices exposed by those APIs. If we continue this
path, at some point (or maybe we're already there), the Web will turn into
any other non-Web platform where ordinary users can (or are advised to)
only use well known trusted applications or visit well known trusted
websites just like how native apps work today.

- R. Niwa

On Wed, Jan 22, 2020 at 8:15 AM Ryosuke Niwa  wrote:
>
>> I'm not sure what specifics you're looking for but the issue is that we
>> don't believe permission prompt is sufficient mitigation. Ordinary people
>> don't understand the full security & privacy implications of granting NFC
>> access when asked.
>>
>> - R. Niwa
>>
>> On Wed, Jan 22, 2020 at 12:04 AM François Beaufort  <
>> fbeauf...@google.com> wrote:
>>
>>> Gentle ping.
>>>
>>> On Mon, Jan 13, 2020 at 12:56 PM François Beaufort  <
>>> fbeauf...@google.com> wrote:
>>>
>>>> As promised earlier, here's the intent to experiment thread URL we've
>>>> just sent to blink-dev:
>>>> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/8bsAd-PsdbA
>>>>
>>>> It would be greatly appreciated if you could share specifics about your
>>>> decision.
>>>> Some alternative designs would also help moving this discussion forward.
>>>>
>>>> Thank you,
>>>> Francois.
>>>>
>>>> On Mon, Jan 6, 2020 at 10:48 PM Maciej Stachowiak 
>>>> wrote:
>>>>
>>>>>
>>>>> 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  <
>>>>> fbeauf...@google.com> 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
>>>
>>
___
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

2020-01-22 Thread Ryosuke Niwa
I'm not sure what specifics you're looking for but the issue is that we
don't believe permission prompt is sufficient mitigation. Ordinary people
don't understand the full security & privacy implications of granting NFC
access when asked.

- R. Niwa

On Wed, Jan 22, 2020 at 12:04 AM François Beaufort  <
fbeauf...@google.com> wrote:

> Gentle ping.
>
> On Mon, Jan 13, 2020 at 12:56 PM François Beaufort  <
> fbeauf...@google.com> wrote:
>
>> As promised earlier, here's the intent to experiment thread URL we've
>> just sent to blink-dev:
>> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/8bsAd-PsdbA
>>
>> It would be greatly appreciated if you could share specifics about your
>> decision.
>> Some alternative designs would also help moving this discussion forward.
>>
>> Thank you,
>> Francois.
>>
>> On Mon, Jan 6, 2020 at 10:48 PM Maciej Stachowiak  wrote:
>>
>>>
>>> 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  <
>>> fbeauf...@google.com> 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
>
___
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

2019-12-20 Thread Ryosuke Niwa
We'll be discussing this internally at Apple but since we're heading into
the holiday shutdown, we probably won't be able to get back to you until
sometime next month.

- R. Niwa

On Wed, Dec 11, 2019 at 1:19 PM Thomas Steiner  wrote:

> The Intent to Experiment thread is here:
>
> https://groups.google.com/a/chromium.org/forum/m/#!msg/blink-dev/nrDKOvVl_I4/yNYZOwJ1EQAJ
>
> On Wed 11. Dec 2019 at 22:08 Ryosuke Niwa  wrote:
>
>>
>> On Wed, Dec 11, 2019 at 11:42 AM Maciej Stachowiak  wrote:
>>
>>>
>>> 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.)
>>>
>>
>> https://github.com/mozilla/standards-positions/issues/210 is Mozilla's
>> standards position issue.
>>
>>> 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
>>>
>> --
> Thomas Steiner, PhD—Developer Advocate (https://blog.tomayac.com,
> https://twitter.com/tomayac)
>
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
> Registergericht und -nummer: Hamburg, HRB 86891
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.1.23 (GNU/Linux)
>
>
> iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.
> hTtPs://xKcd.cOm/1181/
> -END PGP SIGNATURE-
>
___
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

2019-12-11 Thread Ryosuke Niwa
On Wed, Dec 11, 2019 at 11:42 AM Maciej Stachowiak  wrote:

>
> 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.)
>

https://github.com/mozilla/standards-positions/issues/210 is Mozilla's
standards position issue.

> 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
>
___
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)

2019-12-03 Thread Ryosuke Niwa
Great. I've completed the survey.

- R. Niwa

On Mon, Dec 2, 2019 at 5:19 PM Aakash Jain  wrote:

> There were multiple ideas discussed in this thread. I would like to gather
> more data about what do most people prefer. I have sent out a short survey
> in https://lists.webkit.org/pipermail/webkit-dev/2019-December/030980.html
>
> Thanks
> Aakash
>
> On Nov 5, 2019, at 12:04 PM, Alexey Proskuryakov  wrote:
>
>
>
> 4 нояб. 2019 г., в 1:37 PM, Ryosuke Niwa  написал(а):
>
>
> On Mon, Nov 4, 2019 at 9:40 AM Alexey Proskuryakov  wrote:
>
>>
>> Can you elaborate on that, how exactly is e-mailing on first failure
>> useful to reviewers?
>>
>> Getting rid of Bugzilla comments was one of the goals of EWS rewrite,
>> based on engineering feedback about noise in bugs and in e-mail, and I
>> wholeheartedly agree with this feedback. So I think that comments are
>> generally undesirable.
>>
>> Since I don't understand what your precise scenario is, I may be make
>> straw man arguments below, but here are some things that I think make the
>> proposed behavior unhelpful (add a comment on first failure, or when all
>> EWSes pass).
>>
>> 1. EWS comments in Bugzilla are so annoying that some people take the
>> radical step of manually hiding them. EWS history is archived anyway, there
>> is no need to look into comments for it.
>>
>> 2. There are often many people CC'ed on the bug to whom EWS data is
>> irrelevant or even mysterious (e.g. reporters, web developers or
>> non-reviewers). The noise is a slight annoyance, discouraging further
>> participation in the project.
>>
>> 3. I believe that for most reviewers, the mode of operation is one of the
>> two: (1) do it when pinged directly, or (2) go over the review queue when
>> one has the time. Getting EWS comments helps neither.
>>
>> 4. Commenting when all EWSes pass is not very practical - it's too often
>> that we have some stragglers that take days (or forever). I don't think
>> that we can make it reliable even if we start actively policing EWS
>> responsiveness.
>>
>> 5. The reviewer likely wants to know the state of multiple EWSes if they
>> are going to wait for EWS at all. What exactly are they going to do after
>> getting an e-mail that one EWS failed?
>>
>
> I often use a EWS failure as a signal to wait reviewing a patch.
> Otherwise, a bug mail will stay in my inbox as one of items to get to.
>
> I can see the usefulness in the somewhat unusual case of a super urgent
>> patch. We may want multiple people to watch it, so that members of CC list
>> would go and ask the patch author to update it with more urgency than
>> e-mail allows for. I think that opt-in is a better mechanism for that, so
>> that people who opted in would receive information about each EWS data
>> point.
>>
>
> I think there is a value in knowing that a patch isn't ready instead of
> having to open the bug to realize that.
>
>
> So just to clarify,
>
> - a major part of how you get to review bugs is by being CC'ed, and you
> review them when you have the time to read bugmail;
> - and you don't open the bug in Bugzilla if there is already an EWS
> failure by the time you read the e-mail where review is requested?
>
> That's clearly a valid benefit. In my mind, it probably doesn't outweigh
> the downsides. On the other hand, yours is a voice of someone who reviews
> way more patches than Maciej and me combined these days, so maybe more
> e-mail is an overall benefit to many of the reviewers.
>
> - Alexey
>
>
>
> - R. Niwa
>
>> 3 нояб. 2019 г., в 6:58 PM, 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
&g

Re: [webkit-dev] Handling flaky layout-test failures in EWS

2019-12-03 Thread Ryosuke Niwa
On Tue, Dec 3, 2019 at 9:29 AM Alexey Proskuryakov  wrote:

>
> Yes, I think that this makes more sense than retrying.
>
> What is the current behavior when a patch introduces substantial
> flakiness? E.g. this scenario:
>
> - First test run produces 5 failures.
> - Second test run produces 5 different failures.
> - Clean re-run produces no failures.
>
> This looks like decent evidence to make the EWS bubble red. I don't know
> what exactly the threshold should be, but that should certainly be below 30.
>

This makes sense to me.

Another scenario where flaky failures might be a real regression is when
tests which never failed before starts failing flakily.

Can we fetch data from the flakiness dashboard and see if we’ve ever
observed the flakiness on a given test? That would let us get out of the
guessing game.

I understand some flakiness might be specific to EWS but I’d imagine that’d
be more of minority. If it is common, we could also make EWS bots
periodically run full tests without patches and report results to flakiness
dashboard so that we have a corpse of flaky teat failures on EWS bots as
well.

- R. Niwa

3 дек. 2019 г., в 8:40 AM, Aakash Jain  написал(а):
>
>
> Hi Everyone,
>
> We have various layout-tests which are flaky (which sometimes pass and
> sometimes fail/crash/timeout). EWS needs to work despite these flaky tests,
> and need to be able to tell whether the patch being tested introduced any
> test failure or not.
>
> In EWS, we have logic (same logic in both old and new EWS) on how to deal
> with flaky tests. The logic is roughly following:
>
> - We apply the patch and build.
>
> - Run layout-tests. During the test-run, we retry the failed tests. If
> those tests pass in retry, the run is considered to have no failing test
> (this retry part is same for EWS / build.webkit.org / manual-run and part
> of run-webkit-test script itself).
>
> - If a test-run has some failures, EWS retry the test-run one more time
> (to check if those test failures were flaky).
>
> - Then we do one more test-run on clean-tree (without the patch), and
> compare the results of first run, second run, and clean tree run.
>
> - After that we analyze the results from all three test-runs (which we
> call first_run, second_run and clean_tree_run).
>
>
> If there are different test failures in first and second runs (i.e.: flaky
> test failures), and the patch being tested did not introduce any new test
> failure, we retry the entire build (probably hoping that next time we will
> not see the flakiness). This retry can result in almost infinite loop, if
> someone commits a very flaky test (which is not rare), and would cause EWS
> to be almost stuck until the flakiness is fixed.
>
> From
> https://trac.webkit.org/browser/webkit/trunk/Tools/Scripts/webkitpy/tool/bot/patchanalysistask.py#L352
>  ('Defer' means retrying the build).
> '''
> 350# At this point we know that at least one test flaked, but no
> consistent failures
> 351# were introduced. This is a bit of a grey-zone.
> 352return False  # Defer patch
> '''
>
>
> Retrying the entire build, just because of few flaky tests seems excessive
> and inefficient. This doesn't help identify flaky tests, and only delays
> the EWS result. Instead, we should mark the build as SUCCESS (since the
> patch did not introduce any new consistent test failure).
>
> In other EWS test-suites like API tests and JSC tests, we do not retry the
> entire build on flaky test failures, we ignore the flaky tests, and only
> focus on tests which failed consistently. We should do the similar thing
> for layout-tests as well.
>
> I am going to make that change for layout tests in
> https://bugs.webkit.org/show_bug.cgi?id=204769. Please let me know if
> anyone has a different opinion.
>
> Thanks
> Aakash
>
>
>
> ___
> 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


Re: [webkit-dev] Removing WebSQL support

2019-11-22 Thread Ryosuke Niwa
Ugh... not so fast I guess. Apparently we forgot to disable it in WebKit1
:(. So we have to do that first.

On Fri, Nov 22, 2019 at 12:53 PM Maciej Stachowiak  wrote:

>
> 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
>
> --
- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Removing WebSQL support

2019-11-22 Thread Ryosuke Niwa
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


Re: [webkit-dev] WPT at the WebKit Contributors Meeting

2019-11-13 Thread Ryosuke Niwa
Hi Stephen,

Thanks for coming to the contributor's meeting and making a
representation. We enjoyed your presentation & we had a really
productive discussion. The WebKit team at Apple is putting a lot of
effort into improving our WPT pass rate going forward as Maciej
presented so we're looking forward to working with you all :)

Thanks
- R. Niwa

On Sun, Nov 10, 2019 at 6:21 PM Stephen Mcgruer  wrote:
>
> Hi all,
>
> Philip (foo...@chromium.org) and I wanted to thank you all for welcoming us 
> at the WebKit Contributors Meeting last week to talk about Improving Interop 
> with WPT[0] (web-platform-tests). We felt there was great dialog about WebKit 
> and WPT, and we hope to keep that going looking forward.
>
> We have opened a few issues tracking items that were discussed at the 
> meeting, including adding WebKitGTK to the UI[1] (fixed!), improving WebKit 
> --> WPT export[2], and adding download links on the wpt.fyi dashboard[3]. We 
> also intend to publish our methodology for the 'browser-specific failures' 
> graph by the end of the year (including making it easy for anyone to run the 
> same analysis).
>
> Please feel free to voice questions, concerns, or ideas via:
>
> Issues filed on our github repository for web-platform-tests[4] or the 
> wpt.fyi dashboard[5], or
> Email to smcgr...@chromium.org and foo...@chromium.org.
>
> We also accept pull requests, of course!
>
> Thanks,
> Stephen & Philip
>
> [0]: https://trac.webkit.org/wiki/ImprovingInteropwithWPT
> [1]: https://github.com/web-platform-tests/wpt.fyi/issues/1576
> [2]: https://github.com/web-platform-tests/wpt-pr-bot/issues/100
> [3]: https://github.com/web-platform-tests/wpt.fyi/issues/1480
> [4]: https://github.com/web-platform-tests/wpt/issues
> [5]: https://github.com/web-platform-tests/wpt.fyi/issues
> ___
> 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] Supporting for finding ref tests

2019-11-08 Thread Ryosuke Niwa
On Fri, Nov 8, 2019 at 2:15 PM Simon Fraser  wrote:
>
> > On Nov 8, 2019, at 2:07 PM, Ryosuke Niwa  wrote:
> >
> > On Fri, Nov 8, 2019 at 2:01 PM Simon Fraser  wrote:
> >>
> >> I'd like to land a patch to support finding test references via  >> rel="match/mismatch">:
> >> https://bugs.webkit.org/show_bug.cgi?id=203784
> >>
> >> There has been some discussion about this in the past:
> >> https://lists.webkit.org/pipermail/webkit-dev/2011-November/018470.html
> >>
> >> But I think the benefits outweigh the drawbacks. As that mail states:
> >>
> >> *Link element approach*
> >> Pros:
> >>
> >>   - Can reuse same ref. file for multiple tests
> >>
> >> Still true.
> >>
> >>   - Can have multiple ref. files for single test
> >>
> >> True but no something that we support, and I haven't see any WPT use this 
> >> (our importer throws an error if it sees this)
> >>
> >>   - Information is self-contained in the test file
> >>
> >> Still true
> >>
> >>   - We may get away with test suite build step
> >>
> >> It certainly simplifies WPT test import.
> >>
> >> Currently importing some CSS suites (e.g. css-backgrounds) results in 
> >> broken -expected.html files because copying them breaks references to sub 
> >> resources.
> >>
> >> (It turns out that we can't convert W3C ref tests to use WebKit conventions
> >> due to the first two points.)
> >>
> >> We're doing this much more now, and the "multiple references" point is 
> >> moot, so I think we can import WPT tests mostly as-is.
> >>
> >> Cons:
> >>
> >>   - Requires us modifying each port's DRT to support this format
> >>
> >> No, it just requires webkitpy hacking which I've done in the patch.
> >
> > I'm not certain writing a bunch of regular expressions in webkitpy is
> > a reliable mechanism to find expected results. Another issue I found
> > back then was that it significantly slowed run-webkit-tests' startup
> > time because WPT has a workflow to find all tests & their expected
> > results upfront before any tests could run.
>
> The patch uses html5lib (via BeautifulSoup), which is exactly what WPT, and 
> our importer use to find the ref tests.
>
> We don't find references up-front; only when running each test. This patch 
> does add some overhead for parsing each test file,
> which I measured to be about 1-2 sec on a directory which took 30s to run. I 
> think this slight slowdown is worthwhile (we could
> probably eliminate it with some webkitpy optimizations).

Hm... that's ~3% overhead.

> >>   - Adding link elements itself may affect tests (all W3C tests are
> >>   required to have link elements at the moment)
> >>
> >> I haven't seen this be an issue.
> >
> > Another issue is that if you were to modify a test which happens to be
> > also used as a reference or a mismatch result (worse) for some other
> > test, then you may not notice that without inspecting every other test
> > in existence.
>
> EWS will tell you. Also, generally a file won't act as both a test and a 
> reference; I don't see us deviating from
> our current "-expected.html" naming conventions. BTW, you don't *have* to add 
> a  tag; we'll still fall
> back to the current search behavior. If you have both, then webkitpy will 
> warn.

I think we should enforce that in our tooling then.

> >>   - Hard to understand relationship between files. e.g. if we want to
> >>   figure out which tests use ref.html, we must look at all test files
> >>
> >> This is true, but I don't really see it being a problem in practice.
> >
> > This definitely is an issue. It's possible WPT has improved things but
> > we've definitely had an experience where tests were used as reference
> > for other tests, etc... and having to think about this issue every
> > time I touch test drove me nuts.
>
> Do you have any examples? If this does happen in WPT, we should discourage it 
> (and can fix it via PRs).

Oh yeah, it's discouraged but it still happens. If we're doing this in
WebKit, run-webkit-tests should outright refuse to run such tests.

> Generally references live in a resources/ or references/ subdirectory, or 
> have "-ref" in the name.

We need to enforce that in tool.

> >> What I have seen is us importing CSS 2.1 tests that have foo.html and 
> >> foo-ref.html, and treating foo-ref.html as a test

Re: [webkit-dev] Supporting for finding ref tests

2019-11-08 Thread Ryosuke Niwa
On Fri, Nov 8, 2019 at 2:01 PM Simon Fraser  wrote:
>
> I'd like to land a patch to support finding test references via  rel="match/mismatch">:
> https://bugs.webkit.org/show_bug.cgi?id=203784
>
> There has been some discussion about this in the past:
> https://lists.webkit.org/pipermail/webkit-dev/2011-November/018470.html
>
> But I think the benefits outweigh the drawbacks. As that mail states:
>
> *Link element approach*
> Pros:
>
>- Can reuse same ref. file for multiple tests
>
> Still true.
>
>- Can have multiple ref. files for single test
>
> True but no something that we support, and I haven't see any WPT use this 
> (our importer throws an error if it sees this)
>
>- Information is self-contained in the test file
>
> Still true
>
>- We may get away with test suite build step
>
> It certainly simplifies WPT test import.
>
> Currently importing some CSS suites (e.g. css-backgrounds) results in broken 
> -expected.html files because copying them breaks references to sub resources.
>
> (It turns out that we can't convert W3C ref tests to use WebKit conventions
> due to the first two points.)
>
> We're doing this much more now, and the "multiple references" point is moot, 
> so I think we can import WPT tests mostly as-is.
>
> Cons:
>
>- Requires us modifying each port's DRT to support this format
>
> No, it just requires webkitpy hacking which I've done in the patch.

I'm not certain writing a bunch of regular expressions in webkitpy is
a reliable mechanism to find expected results. Another issue I found
back then was that it significantly slowed run-webkit-tests' startup
time because WPT has a workflow to find all tests & their expected
results upfront before any tests could run.
>
>- Adding link elements itself may affect tests (all W3C tests are
>required to have link elements at the moment)
>
> I haven't seen this be an issue.

Another issue is that if you were to modify a test which happens to be
also used as a reference or a mismatch result (worse) for some other
test, then you may not notice that without inspecting every other test
in existence.

>- Hard to understand relationship between files. e.g. if we want to
>figure out which tests use ref.html, we must look at all test files
>
> This is true, but I don't really see it being a problem in practice.

This definitely is an issue. It's possible WPT has improved things but
we've definitely had an experience where tests were used as reference
for other tests, etc... and having to think about this issue every
time I touch test drove me nuts.

> What I have seen is us importing CSS 2.1 tests that have foo.html and 
> foo-ref.html, and treating foo-ref.html as a test so generating 
> foo-expected.txt and foo-ref-expected.txt. That seems worse.

Seems like we can treat "-ref" as a special suffix like we already do
with support directory and resources directory.

> So now that WPT is heavily invested in  I think we should follow 
> suite. It will simplify WPT import, and reduced the number of cloned 
> -expected.html files significantly.

I really don't want to deal with tests being used as references for
other tests. I'm okay with this approach if we forbid that.

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


Re: [webkit-dev] [Styling] Space between [] and () in C++ lambdas

2019-11-08 Thread Ryosuke Niwa
There has been no more votes either way so no space wins. Here's a patch to
codify it in our code style guidelines:
https://bugs.webkit.org/show_bug.cgi?id=204021

- R. Niwa

On Sat, Nov 2, 2019 at 8:26 PM Ryosuke Niwa  wrote:

> On Sat, Nov 2, 2019 at 10:16 AM Caitlin Potter  wrote:
>
>> Not that anybody asked me, but I also prefer to not include a space
>> between captures and parameter, for similar reasons.
>>
>> If I’m not mistaken, v8/chromium tends to omit the space as well. If
>> that’s still true and WebKit adopted that style, context switching between
>> both codebases would be marginally easier for me.
>>
>> On Nov 2, 2019, at 4:19 AM, Antti Koivisto  wrote:
>>
>> 
>>
>> On Fri, Nov 1, 2019 at 10:50 PM Yusuke Suzuki  wrote:
>>
>>>
>>> > On Nov 1, 2019, at 11:53, Michael Catanzaro 
>>> wrote:
>>> >
>>> > On Fri, Nov 1, 2019 at 11:19 am, Ryosuke Niwa 
>>> wrote:
>>> >> Namely, some people write a lambda as:
>>> >> auto x = [] () { }
>>> >> with a space between [] and () while others would write it as:
>>> >> auto x = []() { }
>>> >
>>> > : I omit the () when there are no parameters, as in these examples.
>>> >
>>> > No preference on spacing.
>>>
>>> I like having a space here, because this rule is simpler to me.
>>> If we always have a space between them, this is clear that the above
>>> case is written in `[] { }` instead of `[]{ }`.
>>>
>>
>> I prefer not having the redundant space in [](). It also makes logical
>> sense to me to keep the lambda signature together. I started using lambdas
>> with space there, dropped it later, and suffered no adverse consequences.
>>
>> As for existing practice, WebCore favors spaceless ]( about 2:1 but
>> across the entire WebKit it is closer to 1:1.
>>
>> We always put space before { } block, I don't think that is really in
>> question here, or creating any inconsistencies.
>>
>>
>>antti
>>
>>
>>>
>>> -Yusuke
>>>
>>> >
>>> >
>>> > ___
>>> > 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
>>
> --
> - R. Niwa
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] [Styling] () for a lambda without arguments (Was Space between [] and () in C++ lambdas)

2019-11-08 Thread Ryosuke Niwa
Seems like there is a consensus here. Here's a patch to codify it in our
code style guidelines: https://bugs.webkit.org/show_bug.cgi?id=204021

On Mon, Nov 4, 2019 at 8:06 AM Alex Christensen 
wrote:

> When the lambda is mutable or has a trailing return type, the () is
> currently required by the C++ grammar, so we can’t say to always omit ().
> We could say to always have it, to only have it when necessary, or have no
> code style guideline.  I think we should always have spaces before and
> after, though.
>
> On Nov 3, 2019, at 3:27 AM, Ryosuke Niwa  wrote:
>
>
>
> On Sat, Nov 2, 2019 at 8:25 PM Ryosuke Niwa  wrote:
>
>>
>> On Sat, Nov 2, 2019 at 7:54 PM Chris Dumez  wrote:
>>
>>>
>>>
>>> On Nov 2, 2019, at 7:38 PM, Ryosuke Niwa  wrote:
>>>
>>> 
>>>
>>> On Sat, Nov 2, 2019 at 1:23 AM Antti Koivisto  wrote:
>>>
>>>>
>>>> On Sat, Nov 2, 2019 at 1:38 AM Ryosuke Niwa  wrote:
>>>>
>>>>> On Fri, Nov 1, 2019 at 11:53 AM Michael Catanzaro <
>>>>> mcatanz...@gnome.org> wrote:
>>>>>
>>>>>> On Fri, Nov 1, 2019 at 11:19 am, Ryosuke Niwa 
>>>>>> wrote:
>>>>>> > Namely, some people write a lambda as:
>>>>>> > auto x = [] () { }
>>>>>> >
>>>>>> > with a space between [] and () while others would write it as:
>>>>>> >
>>>>>> > auto x = []() { }
>>>>>>
>>>>>> : I omit the () when there are no parameters, as in these examples.
>>>>>>
>>>>>
>>>>> I guess that's another thing we should decide. Should we, or should we
>>>>> not have () when there are no arguments.
>>>>>
>>>>
>>>> I think this is easily settled by voting via exiting practice. We have
>>>> 1287 instances of [&] { and 107 instances of [&]() { and &] () { across the
>>>> whole WebKit.
>>>>
>>>
>>> That’s good to know. Why don’t we go with the status quo then.
>>>
>>> In this case, we do put a space between ] or ) and {, right?
>>>
>>>
>>> How is this the conclusion from Antti’s comment?
>>>
>>> Based on the discussion so far, it thought no space had a slight lead.
>>>
>>
>> I think you’re conflating this discussion with the other email thread
>> about a space between [] and ().
>>
>> Here, I’m talking about placing a space after [] before { as in:
>> [] { }
>>
>> As opposed to:
>> []{ }
>>
>> We never use the latter style whether it’s other control flow statements
>> like if, while, or for, or for function definitions.
>>
>> - R. Niwa
>>
>> --
>> - 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


[webkit-dev] iOS EWS behind by 3 days??

2019-11-04 Thread Ryosuke Niwa
Hi all,

Does anyone know what's happening with iOS EWS? They're ~3 days behind now:
https://ews-build.webkit.org/#/builders/24

- R. Niwa
___
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)

2019-11-04 Thread Ryosuke Niwa
On Mon, Nov 4, 2019 at 9:40 AM Alexey Proskuryakov  wrote:

>
> Can you elaborate on that, how exactly is e-mailing on first failure
> useful to reviewers?
>
> Getting rid of Bugzilla comments was one of the goals of EWS rewrite,
> based on engineering feedback about noise in bugs and in e-mail, and I
> wholeheartedly agree with this feedback. So I think that comments are
> generally undesirable.
>
> Since I don't understand what your precise scenario is, I may be make
> straw man arguments below, but here are some things that I think make the
> proposed behavior unhelpful (add a comment on first failure, or when all
> EWSes pass).
>
> 1. EWS comments in Bugzilla are so annoying that some people take the
> radical step of manually hiding them. EWS history is archived anyway, there
> is no need to look into comments for it.
>
> 2. There are often many people CC'ed on the bug to whom EWS data is
> irrelevant or even mysterious (e.g. reporters, web developers or
> non-reviewers). The noise is a slight annoyance, discouraging further
> participation in the project.
>
> 3. I believe that for most reviewers, the mode of operation is one of the
> two: (1) do it when pinged directly, or (2) go over the review queue when
> one has the time. Getting EWS comments helps neither.
>
> 4. Commenting when all EWSes pass is not very practical - it's too often
> that we have some stragglers that take days (or forever). I don't think
> that we can make it reliable even if we start actively policing EWS
> responsiveness.
>
> 5. The reviewer likely wants to know the state of multiple EWSes if they
> are going to wait for EWS at all. What exactly are they going to do after
> getting an e-mail that one EWS failed?
>

I often use a EWS failure as a signal to wait reviewing a patch. Otherwise,
a bug mail will stay in my inbox as one of items to get to.

I can see the usefulness in the somewhat unusual case of a super urgent
> patch. We may want multiple people to watch it, so that members of CC list
> would go and ask the patch author to update it with more urgency than
> e-mail allows for. I think that opt-in is a better mechanism for that, so
> that people who opted in would receive information about each EWS data
> point.
>

I think there is a value in knowing that a patch isn't ready instead of
having to open the bug to realize that.

- R. Niwa

> 3 нояб. 2019 г., в 6:58 PM, 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,
> - R. 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 

Re: [webkit-dev] [Styling] () for a lambda without arguments (Was Space between [] and () in C++ lambdas)

2019-11-02 Thread Ryosuke Niwa
On Sat, Nov 2, 2019 at 8:25 PM Ryosuke Niwa  wrote:

>
> On Sat, Nov 2, 2019 at 7:54 PM Chris Dumez  wrote:
>
>>
>>
>> On Nov 2, 2019, at 7:38 PM, Ryosuke Niwa  wrote:
>>
>> 
>>
>> On Sat, Nov 2, 2019 at 1:23 AM Antti Koivisto  wrote:
>>
>>>
>>> On Sat, Nov 2, 2019 at 1:38 AM Ryosuke Niwa  wrote:
>>>
>>>> On Fri, Nov 1, 2019 at 11:53 AM Michael Catanzaro 
>>>> wrote:
>>>>
>>>>> On Fri, Nov 1, 2019 at 11:19 am, Ryosuke Niwa 
>>>>> wrote:
>>>>> > Namely, some people write a lambda as:
>>>>> > auto x = [] () { }
>>>>> >
>>>>> > with a space between [] and () while others would write it as:
>>>>> >
>>>>> > auto x = []() { }
>>>>>
>>>>> : I omit the () when there are no parameters, as in these examples.
>>>>>
>>>>
>>>> I guess that's another thing we should decide. Should we, or should we
>>>> not have () when there are no arguments.
>>>>
>>>
>>> I think this is easily settled by voting via exiting practice. We have
>>> 1287 instances of [&] { and 107 instances of [&]() { and &] () { across the
>>> whole WebKit.
>>>
>>
>> That’s good to know. Why don’t we go with the status quo then.
>>
>> In this case, we do put a space between ] or ) and {, right?
>>
>>
>> How is this the conclusion from Antti’s comment?
>>
>> Based on the discussion so far, it thought no space had a slight lead.
>>
>
> I think you’re conflating this discussion with the other email thread
> about a space between [] and ().
>
> Here, I’m talking about placing a space after [] before { as in:
> [] { }
>
> As opposed to:
> []{ }
>
> We never use the latter style whether it’s other control flow statements
> like if, while, or for, or for function definitions.
>
> - R. Niwa
>
> --
> - R. Niwa
>
-- 
- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] [Styling] () for a lambda without arguments (Was Space between [] and () in C++ lambdas)

2019-11-02 Thread Ryosuke Niwa
On Sat, Nov 2, 2019 at 1:23 AM Antti Koivisto  wrote:

>
> On Sat, Nov 2, 2019 at 1:38 AM Ryosuke Niwa  wrote:
>
>> On Fri, Nov 1, 2019 at 11:53 AM Michael Catanzaro 
>> wrote:
>>
>>> On Fri, Nov 1, 2019 at 11:19 am, Ryosuke Niwa  wrote:
>>> > Namely, some people write a lambda as:
>>> > auto x = [] () { }
>>> >
>>> > with a space between [] and () while others would write it as:
>>> >
>>> > auto x = []() { }
>>>
>>> : I omit the () when there are no parameters, as in these examples.
>>>
>>
>> I guess that's another thing we should decide. Should we, or should we
>> not have () when there are no arguments.
>>
>
> I think this is easily settled by voting via exiting practice. We have
> 1287 instances of [&] { and 107 instances of [&]() { and &] () { across the
> whole WebKit.
>

That’s good to know. Why don’t we go with the status quo then.

In this case, we do put a space between ] or ) and {, right?

I guess this is also consistent with the way people write objective C
blocks:
https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/WorkingwithBlocks/WorkingwithBlocks.html

For JavaScript, this rule probably doesn’t apply because arrow function and
regular anonymous function both require ().

- R. Niwa

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


[webkit-dev] [Styling] () for a lambda without arguments (Was Space between [] and () in C++ lambdas)

2019-11-01 Thread Ryosuke Niwa
On Fri, Nov 1, 2019 at 11:53 AM Michael Catanzaro 
wrote:

> On Fri, Nov 1, 2019 at 11:19 am, Ryosuke Niwa  wrote:
> > Namely, some people write a lambda as:
> > auto x = [] () { }
> >
> > with a space between [] and () while others would write it as:
> >
> > auto x = []() { }
>
> : I omit the () when there are no parameters, as in these examples.
>

I guess that's another thing we should decide. Should we, or should we not
have () when there are no arguments.

I think we usually err on the side of more concise form but I do prefer
having () so that it's clear it's a function. Otherwise, it can look like a
code block start & end.

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


Re: [webkit-dev] [Styling] Space between [] and () in C++ lambdas

2019-11-01 Thread Ryosuke Niwa
On Fri, Nov 1, 2019 at 11:19 AM Ryosuke Niwa  wrote:

> Hi all,
>
> There seems to be inconsistency in our coding style with regards to
> spacing in lambdas.
>
> Namely, some people write a lambda as:
> auto x = [] () { }
>
> with a space between [] and () while others would write it as:
>
> auto x = []() { }
>
> without a space between the two. I'd like to require either style in our
> guideline so that things are consistent in our codebase. Which one should
> we use?
>
> FWIW, I mildly prefer having a space between [] and ().
>

I forgot to mention that according to Antti
<https://bugs.webkit.org/show_bug.cgi?id=203134#c11>, the existing code in
WebCore places no space between ] and ( with 2:1 ratio.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] [Styling] Space between [] and () in C++ lambdas

2019-11-01 Thread Ryosuke Niwa
Hi all,

There seems to be inconsistency in our coding style with regards to spacing
in lambdas.

Namely, some people write a lambda as:
auto x = [] () { }

with a space between [] and () while others would write it as:

auto x = []() { }

without a space between the two. I'd like to require either style in our
guideline so that things are consistent in our codebase. Which one should
we use?

FWIW, I mildly prefer having a space between [] and ().

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


Re: [webkit-dev] EWS now parses error logs in case of build failure

2019-10-29 Thread Ryosuke Niwa
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


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

2019-10-11 Thread Ryosuke Niwa
On Fri, 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.


I don't think that addresses my primary concern. It's very important to
signal to the rest of the world that a single port of WebKit doesn't
represent the entirety of the WebKit project for the purpose of WPT pass
rate or any other standards compliance.

We already had a discussion about how how Apple should provide JSC binary
on Linux despite of the fact Apple does not maintain any port on Linux:
https://lists.webkit.org/pipermail/webkit-dev/2017-December/029805.html

I don't think we want to add more confusion to the situation by different
ports of WebKit using the WebKit logo on wpt.fyi or any other place for
that matter.

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


Re: [webkit-dev] Implementing OffscreenCanvas

2019-10-11 Thread Ryosuke Niwa
On Fri, Oct 11, 2019 at 2:09 AM Chris Lord  wrote:

>
> On 2019-10-10 23:15, Ryosuke Niwa wrote:
> > On Thu, Oct 10, 2019 at 2:07 PM Myles C. Maxfield
> >  wrote:
> >
> >>> On Oct 10, 2019, at 12:57 PM, Ryosuke Niwa 
> >>> wrote:
> >>>
> >>> Hi Chris,
> >>>
> >>> I'm excited that you're working on OffscreenCanvas because I think
> >>> it would be a valuable feature
> >>
> >> Me too!!!
> >>
> >>> , and I'm confident we can come up with a strategy to limit its
> >>> privacy & security risk as we see fit.
> >>>
> >>> However, many of your patches seem to ignore the fact most of
> >>> WebCore objects aren't thread safe. For example, CSS parser and
> >>> the entire CSS object model aren't designed to used in non-main
> >>> thread. Regardless of how ready Linux ports might be, we can't
> >>> land or enable this feature in WebKit until all thread safety
> >>> issues are sorted out.
> >>>
> >>> Unfortunately, I can't make a time commitment to review & find
> >>> every thread safety issue in your patches. Please work with
> >>> relevant experts and go over your code changes.
> >>
> >> I’d be happy to work with you on this.
> >>
> >>> For example, it's never safe to an object that's RefCounted in
> >>> multiple threads because RefCounted isn't thread safe. One would
> >>> have to use ThreadSafeRefCounted. It's never safe to use
> >>> AtomString from one another in another because AtomString has a
> >>> pool of strings per thread. For that matter, it's never safe to
> >>> use a single String object from two or more threads because String
> >>> itself is RefCounted and isn't thread safe. It's not not okay to
> >>> do readonly access to basic container types like Vector, HashMap,
> >>> etc... because they don't guarantee atomic update of internal data
> >>> structures and doing so can result in UAF.
>
> To the best of my knowledge, I've taken this into account (it's hard to
> see this without applying the whole patch series, as later patches
> assume the changes made with respect to thread-safety in the earlier
> patches). There are of course bound to be things I've missed - and I'm
> also open to taking a different strategy on certain things too, I'm
> fairly new to the WebKit codebase (well, I'm assuming having worked on
> it around 10 years ago doesn't apply too much anymore :)) and I imagine
> I've taken some naive approaches in places that someone more experienced
> would be able to correct me on.


I think you want Antti's input most here since many of the classes you're
touching in CSS is maintained by Antti these days.

The thing that worries me most about this feature is the thread
safety. Historically, we had many thread safety issues regarding Timer,
RefCounted objects, WeakPtr, etc... Chris (Dumez) and I have been
addressing some of those issues more systematically (e.g.
https://trac.webkit.org/r241499 & https://trac.webkit.org/r248113) because
we seem to keep making same mistakes across the codebase. The key here is
to really make which objects are used concurrently or in non-main threads
obvious to whomever reading the code in the future.

I can think of a few ways to do that. For one, we should be adding lots of
thread safety assertions. Assertions are better than comments because
they're obvious to readers and they warn us whenever they get out of date
or we make mistakes. In fact, I discourage adding comments about thread
safety; if you find yourself doing that, then it's time to refactor code
such that the code is obviously multi-threaded or concurrent by the virtue
of the way things are structured or make it not matter because the code is
naturally thread safe. Just as an example, one of your patches made
CSSValuePool's member functions thread safe but it left the rest of code
still access CSSValuePool::singleton() object. This is problematic because
singleton objects are usually shared across threads. A better approach is
to have each caller explicitly get a specific instance of CSSValuePool from
some other object; e.g. CSSParser's member variable. This will make it so
that the code that needs to run concurrently would not rely on singleton
objects, and whatever new code which gets introduced to CSSValuePool or
CSSParser would naturally be thread safe so long as the author follows the
same convention. Finally, we can add an assertion
in CSSValuePool::singleton() to make sure it's only called in the thread.
This way, anyone who makes a mistake of calling this singleton function in
CSSParser, or elsewhere which can be used 

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

2019-10-10 Thread Ryosuke Niwa
On Thu, Oct 10, 2019 at 9:03 AM Carlos Alberto Lopez Perez <
clo...@igalia.com> 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
>
>
> But if that is ok for you, then for my part is also fine... in the end
> webkitgtk is webkit, right?
>

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. WebKit's ports are unlike Gecko's
& Blink's because while they may have platform specific bugs, each engine
is supposed to fully support more or less the same set of features on all
platforms equally well, and there is a clear entity which maintains either
engine (Mozilla & Google). With WebKit, that's not the case.

If I were you, I'd do something like putting WebKit logo on a side of GTK+
logo's box.

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


Re: [webkit-dev] Implementing OffscreenCanvas

2019-10-10 Thread Ryosuke Niwa
Hi Chris,

I'm excited that you're working on OffscreenCanvas because I think it would
be a valuable feature, and I'm confident we can come up with a strategy to
limit its privacy & security risk as we see fit.

However, many of your patches seem to ignore the fact most of WebCore
objects aren't thread safe. For example, CSS parser and the entire CSS
object model aren't designed to used in non-main thread. Regardless of how
ready Linux ports might be, we can't land or enable this feature in WebKit
until all thread safety issues are sorted out.

Unfortunately, I can't make a time commitment to review & find every thread
safety issue in your patches. Please work with relevant experts and go over
your code changes.

For example, it's never safe to an object that's RefCounted in multiple
threads because RefCounted isn't thread safe. One would have to use
ThreadSafeRefCounted. It's never safe to use AtomString from one another in
another because AtomString has a pool of strings per thread. For that
matter, it's never safe to use a single String object from two or more
threads because String itself is RefCounted and isn't thread safe. It's not
not okay to do readonly access to basic container types like Vector,
HashMap, etc... because they don't guarantee atomic update of internal data
structures and doing so can result in UAF.

I think the hardest part of this project is validating that enabling this
feature wouldn't introduce dozens of new thread safety issues and thereby
security vulnerabilities.

- R. Niwa

On Thu, Oct 10, 2019 at 4:23 AM Chris Lord  wrote:

>
> 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


Re: [webkit-dev] virtual destructor annotations in subclasses

2019-10-08 Thread Ryosuke Niwa
On Tue, Oct 8, 2019 at 4:24 PM Yury Semikhatsky  wrote:

>
> This question came up in a code review where I annotated subclass's
> destructor with 'override':
>
> class SuperClass {
> public:
>   virtual ~SuperClass() {}
> };
>
> class Subclass : public SuperClass {
> public:
>   ~Subclass() *override*;
> };
>
> The style guide recommends
> 
> annotating overriden methods with either 'override' or 'final'. At the same
> time with a very few exceptions, the vast majority of the subclasses in
> WebKit annotate their destructors with 'virtual' keyword. It might be
> because some of the code predates c++11 and virtual was the default
> choice back then. In any case it prevents the compiler from generating
> errors when super destructor is accidentally not made virtual.
>
> So my question is if there is a reason to exempt destructors from the
> above rule and mark them virtual in subclasses or they should be annotated
> with override/final similar to other virtual methods?
>
> In the latter case we could update existing code once  by automatically
> generating fix with clang-tidy.
>

I don't have an opinion either way about the actual style but I'm against
adding override everywhere en masse the same way we don't land a bunch of
whitespace or other style tidy ups. If we were to decide that we want to
add override, that should happen over time as people touch different
classes and files.

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


[webkit-dev] Implementing requestIdleCallback

2019-10-07 Thread Ryosuke Niwa
Hi all,

I'm starting the effort to implement requestIdleCallback [1] in WebKit in
https://bugs.webkit.org/show_bug.cgi?id=164193. It's an API for executing
scripts when the browser is idle. It's supported by both Gecko & Blink as
well as the old Edge engine.

Because we don't plan on implementing any sort of scheduler or the
literal event loop in WebKit, the major part of this effort involves
identifying task sources [2] that interact with the idleness as
discussed in https://github.com/w3c/requestidlecallback/issues/71, and
contributing to more explicitly define what "idle" means in the cooperative
scheduling specification itself.

This would entail studying the use thereof and refactoring of Timer,
GenericTaskQueue, GenericEventQueue, etc... in order to track origins of
tasks and determining the quality of service of each task; e.g. whether a
given task is considered as a task that should delay requestIdleCallback if
it's author observable, and if not, then its relative priority with
requestIdleCallback.

[1] Spec: https://w3c.github.io/requestidlecallback/
[2]
https://html.spec.whatwg.org/multipage/webappapis.html#generic-task-sources

- R. Niwa
___
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)

2019-10-02 Thread Ryosuke Niwa
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.

- R. Niwa

On Wed, Oct 2, 2019 at 10:05 AM Carlos Alberto Lopez Perez <
clo...@igalia.com> wrote:

> Hi,
>
> I'm working on having daily runs of WebKitGTK (with minibrowser) at
> https://wpt.fyi
> but then I noticed that the WebKitGTK project doesn't have a logo as such.
>
> So, I wonder...
>
> Would it be OK to use the WebKit logo for the WebKitGTK port?
> (to show on wpt.fyi at the top of the column for the WebKitGTK test
> results)
>
> Thanks for the comments
>
> Best regards.
>
> ___
> 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] Planned EWS improvements

2019-09-26 Thread Ryosuke Niwa
On Fri, Sep 27, 2019 at 7:57 AM Saam Barati  wrote:

> Hi Aakash,
>
> Thanks for doing this work.
>
> On Sep 26, 2019, at 11:27 AM, Aakash Jain  wrote:
>
> Hi Everyone,
>
> I have been making number of improvements to EWS. I also have various
> planned improvements to EWS. I wanted to reach out to you guys to see if
> anyone wants me to prioritize any particular improvement(s). If there is
> any improvement which you want to see and is not listed below, please feel
> free to let me know. Also most of the queues have been transitioned from
> old to new EWS and I am working on the remaining ones (jsc, windows and
> commit-queue).
>
> Here is the list of improvements (in no particular order):
>
> 1) Develop a webpage showing summary of EWS builds for a patch. This page
> would provide the summary of important build-steps, high-level details
> about the failure (e.g.: name of the tests which failed, or possibly
> relevant build failure logs), and include link(s) to the Buildbot page(s).
> This page will open on clicking the status-bubbles (and would be
> replacement of old EWS status page like
> https://webkit-queues.webkit.org/patch/379563/win-ews). Currently
> clicking the status-bubble opens the Buildbot build page, which contains a
> lot of infrastructure details, and probably is information-overload for
> many engineers, so this summary page should help with that.
> https://webkit.org/b/197522
>
> 2) Redesign status-bubble tooltip to include more detailed information
> about failures (e.g.: each test failure name along-with url to flakiness
> dashboard, and url to complete results.html file, as suggested by David
> Kilzer in
> https://lists.webkit.org/pipermail/webkit-dev/2019-September/030799.html).
> We should also add the tooltip support for iPad/iPhone
> https://webkit.org/b/201940
>
> 3) Add a way to retry a patch in EWS. This would allow engineers to
> confirm that the failures indicated by EWS aren't flaky/incorrect. Maybe a
> good place to add the 'retry' button would be the status-bubble's tool-tip
> (visible only if the bubble is red) https://webkit.org/b/196599
>
> This would be amazing. (My 2c: I'd vote for the button being visible
> without tooltip.)
>

Yeah, this would be the most useful addition to EWS.

4) Parse the relevant build failure message from build logs (and display in
> summary page) https://webkit.org/b/201941
>
> 5) Style failure should be displayed in-line on the review page along-with
> the code, just like the reviewer's comments https://webkit.org/b/202252
>
> 6) Add more test-suites to EWS (e.g.: LLDB tests, resultsdbpy tests)
> https://webkit.org/b/189206, https://webkit.org/b/201928
>
> 7) Add commit-queue support for security bugs https://webkit.org/b/201939
>
> 8) API tests should upload crashlogs https://webkit.org/b/201929
>
>
Along with this one.

- R. Niwa

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


Re: [webkit-dev] Implementing MathML stylistic attributes in WebKit

2019-09-02 Thread Ryosuke Niwa
On Mon, Sep 2, 2019 at 7:11 AM Frédéric Wang  wrote:

>
> Currently MathML attributes mathvariant, displaystyle and scriptlevel [1]
> [2] are implemented in WebKit using custom "style resolution" and
> "one-glyph rendering" inside the MathML layout code [3] [4] [5]. These
> features involve text rendering and interaction with CSS font-size, so it
> is difficult to implement them properly and completely that way. There are
> known bugs and missing features right now (e.g. mathvariant transform only
> applies to one-character strings, automatic displaystyle/scriptlevel does
> not work with fractions, etc)
>
> Several years ago, Gecko used to do something similar but that was causing
> a lot of problems (dynamic update, assertion failures...). At the end, this
> is now implemented in Gecko more reliably by mapping the attributes to
> internal CSS properties ; [6] is based on that. When I tried to do
> something like this in WebKit three years ago, I was only able to rely on
> proprietary -webkit-* extensions exposed to users [7].
>
> So my questions are:
>
> (1) What is WebKit's mechanism to implement such stylistic attributes?
>

It looks like -internal-text-autosizing-status is such a property. This is
a property the author can never set and we set it internally for
implementation purposes. ComputedStyleExtractor::valueForPropertyInStyle
manually skips it so it's never exposed anywhere.

One subtle thing I didn't check is whether it would affect the CSS parser
or not (as in whether it would be considered as a valid CSS property or
not). There might be some subtle effect there.

-webkit-text-decorations-in-effect is also a CSS property we use internally
to compute the effective set of text decorations applied to text for
editing purposes. The author can never set it but it's unfortunately
exposed via computed style.

(2) Is it possible to implement internal (i.e. not web-exposed to users)
> CSS properties/values in WebKit?
>

It appears possible today using the technique deployed by
CSSPropertyInternalTextAutosizingStatus.


> (3) Is it ok to add more -webkit-* properties/values or should these
> properties be standardized at the CSS WG instead?
>

N/A

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


[webkit-dev] Disabling keygen element by default

2019-08-16 Thread Ryosuke Niwa
Hi all,

HTML keygen element had been removed from Chrome since 2017, and Firefox
recently removed it in Firefox 69:
https://bugzilla.mozilla.org/show_bug.cgi?id=1315460

I've put a patch up to disable keygen element by default on
https://bugs.webkit.org/show_bug.cgi?id=200850.

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


Re: [webkit-dev] Moving to Python 3

2019-07-13 Thread Ryosuke Niwa
On Sat, 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?


That seems okay given macOS / iOS ports don’t use CMake right now.

Virtually all ports that use CMake as the build system would have python3
in the base installation or already require installations of a bunch of
software (e.g. Windows port), right?

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


Re: [webkit-dev] Moving to Python 3

2019-07-13 Thread Ryosuke Niwa
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.


> 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


Re: [webkit-dev] Moving to Python 3

2019-07-12 Thread Ryosuke Niwa
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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Moving to Python 3

2019-07-12 Thread Ryosuke Niwa
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.

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


Re: [webkit-dev] What is the status of Network Error Logging and Reporting API?

2019-06-10 Thread Ryosuke Niwa
On Sat, Jun 8, 2019 at 5:37 PM Konstantin Tokarev  wrote:

>
> 04.06.2019, 02:41, "Ryosuke Niwa" :
> > I assume you want to use this feature. What are your use cases?
>
> Actually, I was just rambling through web-platform-tests and discovered
> thing I wasn't aware of,
> which seemed to be on standards track but missing in feature status.
>
> However, I think this feature could be useful as a lightweight inspector
> replacement for embedded
> systems which are deployed to clients, when it may not be easy to make a
> direct connection.
>

I'm not sure it could be useful in some cases but what would be nice is to
know what folks want to this API in real life so that we can prioritize it
appropriately.

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


Re: [webkit-dev] Remove SVGTests.hasExtension?

2019-06-07 Thread Ryosuke Niwa
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


Re: [webkit-dev] Remove SVGTests.hasExtension?

2019-06-07 Thread Ryosuke Niwa
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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] What is the status of Network Error Logging and Reporting API?

2019-06-03 Thread Ryosuke Niwa
I assume you want to use this feature. What are your use cases?

On Sun, Jun 2, 2019 at 6:16 PM Konstantin Tokarev  wrote:

> They are missing from features.json
>
> https://w3c.github.io/network-error-logging/
> https://www.w3.org/TR/reporting/
>
> --
> Regards,
> Konstantin
>
> ___
> 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] Waiting for an event in layout test...

2019-05-31 Thread Ryosuke Niwa
I’m gonna give you a game changing function:

function listenForEventOnce(target, name, timeout) {
return new Promise((resolve, reject) => {
const timer = timeout ? setTimeout(reject, timeout) : null;
target.addEventListener(name, () => {
if (timer)
clearTimeout(timer);
resolve();
}, {once: true});
});
}

You can then write a test like this:
await listenForEventOnce(document.body, 'load');
// do stuff after load event.

await listenForEventOnce(document.querySelector('input'), 'focus');
await listenForEventOnce(visualViewport, 'scroll', 5000);
// After the input element is focused, then the visual viewport scrolled or
5 seconds has passed.

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


Re: [webkit-dev] Introducing brand new EWS

2019-04-11 Thread Ryosuke Niwa
Yes, that would be great.

Although I'd still prefer having a proper waterfall view so that when my
patch isn't getting processed / very behind in the queue, I can figure out
what's causing it on my own instead of having to tell a bot watcher
something is wrong with EWS.

- R. Niwa

On Thu, Apr 11, 2019 at 12:17 PM Aakash Jain  wrote:

> Hi Ryosuke,
>
> Sorry for the delay. I will soon be adding the feature to display patch's
> position in queue in https://bugs.webkit.org/show_bug.cgi?id=196607.
> Would that address your concern?
>
> Thanks
> Aakash
>
> On Apr 4, 2019, at 10:09 PM, Ryosuke Niwa  wrote:
>
> The new bubbles seem to be working well, and having API tests running in
> EWS is great!
>
> Can we add the waterfall view to https://ews-build.webkit.org/#/builders so
> that we can see where our patches are in the queue?
>
> - R. Niwa
>
> On Thu, Apr 4, 2019 at 6:59 PM Aakash Jain  wrote:
>
>> Introducing brand new EWS
>>
>> with EWS for API Tests (for macOS and iOS)
>>
>> and EWS for WebKitPerl Tests!
>>
>>
>> Starting today, when you upload a patch to bugs.webkit.org, you will see
>> few more bubbles (for API tests and webkitperl tests). You might also see
>> additional button 'Submit to new EWS' (if the patch doesn't have r? flag).
>>
>> The new EWS comes with many new features and there are lot more I want to
>> add. But, I don't want you guys to wait more to start getting the benefits.
>> That's why I am rolling it out in phases, starting with EWS for API Tests
>> and WebKitPerl Tests. These are tests which are not currently covered by
>> the existing EWS. Next step would be to move queues from existing EWS to
>> new EWS one by one, with the eventual goal of moving over everything to new
>> EWS.
>>
>>
>> *Why new EWS?*
>> The existing EWS has certain architectural limitations. One of the
>> prominent limitation is that there is no concept of building and testing
>> the patch on different queues. If we have three queues: WK1 tests, WK2
>> tests and API tests, all three queues would need to compile WebKit
>> independently. So WebKit would be compiled thrice instead of once. This is
>> inefficient and thereby require more hardware.
>>
>> The new EWS has separate builder and tester queues. Builder queues build
>> once and upload the archive. Multiple tester queues download that same
>> archive and run tests on that. That way WebKit is compiled only once, and
>> re-used on multiple tester queues. This improves system efficiency and
>> allows us to add new test queues with substantially less hardware.
>>
>> The new EWS uses Buildbot at the back-end, which is a production-level CI
>> system. It is easier to maintain and automatically provide various features
>> like historical build logs, real-time log streaming, easier bot management,
>> ability to retry a build etc. Plus, it’s a system most of you are already
>> familiar with (build.webkit.org).
>>
>>
>> *How can you contribute:*
>> If you are interested in contributing, the source code is located at:
>> ews-build (Buildbot): Tools/BuildSlaveSupport/ews-build
>> ews-app (web-app): Tools/BuildSlaveSupport/ews-app
>>
>> Detailed instructions are at:
>> https://trac.webkit.org/wiki/EarlyWarningSystem#ContributingtoEarlyWarningSystem
>>
>>
>> *Upcoming features:*
>> - status-bubble should display position in queue
>> https://bugs.webkit.org/show_bug.cgi?id=196607
>> - EWS should comment on Bugzilla bugs about failures
>> https://bugs.webkit.org/show_bug.cgi?id=196598
>> - EWS should have a way to retry a patch
>> https://bugs.webkit.org/show_bug.cgi?id=196599
>> - Security EWS https://bugs.webkit.org/show_bug.cgi?id=196605
>>
>>
>> If you notice any issue, please feel free to file bugs (and assign to me).
>>
>> Thanks & Regards
>> Aakash Jain
>> ___
>> 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] Introducing brand new EWS

2019-04-04 Thread Ryosuke Niwa
The new bubbles seem to be working well, and having API tests running in
EWS is great!

Can we add the waterfall view to https://ews-build.webkit.org/#/builders so
that we can see where our patches are in the queue?

- R. Niwa

On Thu, Apr 4, 2019 at 6:59 PM Aakash Jain  wrote:

> Introducing brand new EWS
>
> with EWS for API Tests (for macOS and iOS)
>
> and EWS for WebKitPerl Tests!
>
>
> Starting today, when you upload a patch to bugs.webkit.org, you will see
> few more bubbles (for API tests and webkitperl tests). You might also see
> additional button 'Submit to new EWS' (if the patch doesn't have r? flag).
>
> The new EWS comes with many new features and there are lot more I want to
> add. But, I don't want you guys to wait more to start getting the benefits.
> That's why I am rolling it out in phases, starting with EWS for API Tests
> and WebKitPerl Tests. These are tests which are not currently covered by
> the existing EWS. Next step would be to move queues from existing EWS to
> new EWS one by one, with the eventual goal of moving over everything to new
> EWS.
>
>
> *Why new EWS?*
> The existing EWS has certain architectural limitations. One of the
> prominent limitation is that there is no concept of building and testing
> the patch on different queues. If we have three queues: WK1 tests, WK2
> tests and API tests, all three queues would need to compile WebKit
> independently. So WebKit would be compiled thrice instead of once. This is
> inefficient and thereby require more hardware.
>
> The new EWS has separate builder and tester queues. Builder queues build
> once and upload the archive. Multiple tester queues download that same
> archive and run tests on that. That way WebKit is compiled only once, and
> re-used on multiple tester queues. This improves system efficiency and
> allows us to add new test queues with substantially less hardware.
>
> The new EWS uses Buildbot at the back-end, which is a production-level CI
> system. It is easier to maintain and automatically provide various features
> like historical build logs, real-time log streaming, easier bot management,
> ability to retry a build etc. Plus, it’s a system most of you are already
> familiar with (build.webkit.org).
>
>
> *How can you contribute:*
> If you are interested in contributing, the source code is located at:
> ews-build (Buildbot): Tools/BuildSlaveSupport/ews-build
> ews-app (web-app): Tools/BuildSlaveSupport/ews-app
>
> Detailed instructions are at:
> https://trac.webkit.org/wiki/EarlyWarningSystem#ContributingtoEarlyWarningSystem
>
>
> *Upcoming features:*
> - status-bubble should display position in queue
> https://bugs.webkit.org/show_bug.cgi?id=196607
> - EWS should comment on Bugzilla bugs about failures
> https://bugs.webkit.org/show_bug.cgi?id=196598
> - EWS should have a way to retry a patch
> https://bugs.webkit.org/show_bug.cgi?id=196599
> - Security EWS https://bugs.webkit.org/show_bug.cgi?id=196605
>
>
> If you notice any issue, please feel free to file bugs (and assign to me).
>
> Thanks & Regards
> Aakash Jain
> ___
> 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] MathML Refresh Heads up

2019-03-21 Thread Ryosuke Niwa
On Thu, Mar 21, 2019 at 9:42 AM Frédéric Wang  wrote:

> On 20/03/2019 20:45, Ryosuke Niwa wrote:
>
> I agree on the goal but disagree on the suggestion. At minimum, we should
> decide each case separately and try to collect some data before.
>
>> We can continue to agree to disagree on this point. But I strongly object
>> to removing any features from MathML implementation of WebKit without
>> having done comprehensive compatibility testing with various iOS and macOS
>> apps that use MathML.
>>
>> I'm also happy with more testing with iOS / macOS apps. I was just
> concerned by the "for now" and the "there isn't any easy way to do it" in
> your initial emails, it seems you were not open to accept any change for an
> undetermined period of time, just because of your ports...
>
Yes, in general, I don't think we should be any feature from WebKit unless
there is a good evidence that the removal won't affect any website or apps.
This topic comes up of wanting to remove a feature comes up every now and
then, and my answer is always that we should never remove a feature. The
corollary of this position is that we should never add a feature unless
it's absolutely necessary because we can never remove it once it's added.

> I guess one way to satisfy your desire without breaking WebKit in iOS and
>>> macOS would be to add a runtime feature flag which disables the parts of
>>> MathML that's not a part of core MathML, and then only enable this feature
>>> in your own port. That would allow you to have the same set of features
>>> between your products without breaking our ports.
>>>
>>
> ...however that proposal from you last email sounds more constructive.
> That would still be extra burden for us to manage deprecated MathML code
> and the corresponding tests, but at least that will give us the opportunity
> to start disabling features & run tests without them, to better see which
> parts we can ignore when comparing code between web engines and even to
> have beta testers providing feedback. So that seems a good trade off until
> Apple is ready to accept the changes (or not).
>
> I really don't care what maintainers of Blink say or do about MathML
>>> because they don't have MathML implementation right now. My primary concern
>>> as I've stated multiple times is iOS and macOS apps that currently use
>>> MathML.
>>>
>> Again, you are the one who brought up that topic in this thread. If you
> really don't care about Blink maintainers or Google's opinion then please
> just don't mention them.
>
Well, you're the one who brought up Chromium in the very first email:

> As some of you may know, Igalia is working on MathML support in Chromium
> this year


I think it would have been best if you didn't mention it if you didn't talk
to talk about.

> These all seem like something out in the wild might be using.
>>> https://github.com/search?q=mathml+fontweight=Code yields quite a
>>> few examples in which fontweight content attribute is being used for
>>> example.
>>>
>>> MathML is used as an exchange format in various tools, standards and
>>> documents so that's not really surprising to get matches. However, the
>>> MathML Core spec targets usage in web engines so what we need instead is to
>>> check content that is actually served to web engines in general and to
>>> WebKit in particular.
>>>
>>> Note: There are straighforward CSS polyfills for the attributes
>>> previously mentioned. A JS polyfill would be needed for MathML nonzero
>>> unitless lengths (if they are really used) but removing the possibility to
>>> write "5" instead of "500%" is part of the general goal to align more with
>>> HTML/CSS. Regarding fontweight, it is known to require some extra
>>> code/tests in Gecko/Stylo in order to handle conflicts with mathvariant (
>>> WebKit doesn't handle such conflicts
>>> https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/mathml/MathMLElement.cpp#L122
>>> ).
>>>
>> An existence of a bug in our code is not an evidence that the entire
>> feature can be removed.
>>
> That was not my point. I was just trying to explain that there are more
> issues involved when you analyze carefully each case, you cannot just rely
> on generic claims, quick searches or unilateral approaches in order to make
> a decision. Anyway that was just a side note, it's probably not worth
> entering into details on this mailing list.
>
> Thank you,
>
> --
> Frédéric Wang
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] MathML Refresh Heads up

2019-03-20 Thread Ryosuke Niwa
On Wed, Mar 20, 2019 at 10:42 AM Ryosuke Niwa  wrote:

>
> On Wed, Mar 20, 2019 at 5:57 AM Frédéric Wang  wrote:
>
>> On 16/03/2019 00:04, Ryosuke Niwa wrote:
>>
>> On Fri, 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?
>>>
>>
>> Ultimately, we need some testing to ensure whatever iOS and macOS apps,
>> or websites that specifically target WebKit and Gecko that use MathML don't
>> get broken by those removals. Because there isn't an easy way to do that
>> right now, my suggestion is not remove any features for now.
>>
>> I agree on the goal but disagree on the suggestion. At minimum, we should
>> decide each case separately and try to collect some data before.
>>
> We can continue to agree to disagree on this point. But I strongly object
> to removing any features from MathML implementation of WebKit without
> having done comprehensive compatibility testing with various iOS and macOS
> apps that use MathML.
>
> Put it another way, what's the benefit of removing features in WebKit
>> before fixing other MathML bugs?
>>
>> This question sounds rhetorical, but basically this is already said in
>> the initial email: improve browser interoperability and reduce complexity
>> of current implementations Especially, at Igalia we are working on several
>> engines in parallel and it's much easier if the implementation logic and
>> set of WPT tests is consistent in order to compare the code, fix bugs and
>> implement new features.
>>
> Then the best way to achieve that will be implementing what WebKit and
> Gecko implement in Blink, not remove features from WebKit and Gecko.
>
>> Maintaining WebKits-specific features and tests would be an extra burden,
>> so it would be preferable to avoid it when possible.
>>
> I see why you'd prefer that but making one's job easier by breaking
> backwards compatibility with exiting apps and websites is not a good trade
> off.
>

I guess one way to satisfy your desire without breaking WebKit in iOS and
macOS would be to add a runtime feature flag which disables the parts of
MathML that's not a part of core MathML, and then only enable this feature
in your own port. That would allow you to have the same set of features
between your products without breaking our ports.

If the only benefit is that Blink may have an easier time implementing the
>> rest and therefore might be more interoperable, I really don't buy that
>> argument given MathML isn't supported at all in Blink today.
>>
>> Note that you are the only one who suggested on this thread that our
>> WebKit announcement is made according to Google's opinion or Blink's
>> development plan... I get that having more features in Gecko/WebKit might
>> be an interoperability concern and maybe Apple actually has more
>> information from Google, but so far Google people actually seem more
>> interested in the two other points of the initial email.
>>
> I really don't care what maintainers of Blink say or do about MathML
> because they don't have MathML implementation right now. My primary concern
> as I've stated multiple times is iOS and macOS apps that currently use
> MathML.
>
>> These all seem like something out in the wild might be using.
>> https://github.com/search?q=mathml+fontweight=Code yields quite a
>> few examples in which fontweight content attribute is being used for
>> example.
>>
>> MathML is used as an exchange format in various tools, standards and
>> documents so that's not really surprising to get matches. However, the
>> MathML Core spec targets usage in web engines so what we need instead is to
>> check content that is actually served to web engines in general and to
>> WebKit in particular.
>>
>> Note: There are straighforward CSS polyfills for the attributes
>> previously mentioned. A JS polyfill would be needed for MathML nonzero
>> unitless lengths (if they are really used) but removing the possibility to
>> write "5" instead of "500%" is part of the general goal to align more with
>> HTML/CSS. Regarding fontweight, it is known to req

Re: [webkit-dev] MathML Refresh Heads up

2019-03-20 Thread Ryosuke Niwa
On Wed, Mar 20, 2019 at 5:57 AM Frédéric Wang  wrote:

> On 16/03/2019 00:04, Ryosuke Niwa wrote:
>
> On Fri, 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?
>>
>
> Ultimately, we need some testing to ensure whatever iOS and macOS apps, or
> websites that specifically target WebKit and Gecko that use MathML don't
> get broken by those removals. Because there isn't an easy way to do that
> right now, my suggestion is not remove any features for now.
>
> I agree on the goal but disagree on the suggestion. At minimum, we should
> decide each case separately and try to collect some data before.
>
We can continue to agree to disagree on this point. But I strongly object
to removing any features from MathML implementation of WebKit without
having done comprehensive compatibility testing with various iOS and macOS
apps that use MathML.

Put it another way, what's the benefit of removing features in WebKit
> before fixing other MathML bugs?
>
> This question sounds rhetorical, but basically this is already said in the
> initial email: improve browser interoperability and reduce complexity of
> current implementations Especially, at Igalia we are working on several
> engines in parallel and it's much easier if the implementation logic and
> set of WPT tests is consistent in order to compare the code, fix bugs and
> implement new features.
>
Then the best way to achieve that will be implementing what WebKit and
Gecko implement in Blink, not remove features from WebKit and Gecko.

> Maintaining WebKits-specific features and tests would be an extra burden,
> so it would be preferable to avoid it when possible.
>
I see why you'd prefer that but making one's job easier by breaking
backwards compatibility with exiting apps and websites is not a good trade
off.

> If the only benefit is that Blink may have an easier time implementing the
> rest and therefore might be more interoperable, I really don't buy that
> argument given MathML isn't supported at all in Blink today.
>
> Note that you are the only one who suggested on this thread that our
> WebKit announcement is made according to Google's opinion or Blink's
> development plan... I get that having more features in Gecko/WebKit might
> be an interoperability concern and maybe Apple actually has more
> information from Google, but so far Google people actually seem more
> interested in the two other points of the initial email.
>
I really don't care what maintainers of Blink say or do about MathML
because they don't have MathML implementation right now. My primary concern
as I've stated multiple times is iOS and macOS apps that currently use
MathML.

> These all seem like something out in the wild might be using.
> https://github.com/search?q=mathml+fontweight=Code yields quite a
> few examples in which fontweight content attribute is being used for
> example.
>
> MathML is used as an exchange format in various tools, standards and
> documents so that's not really surprising to get matches. However, the
> MathML Core spec targets usage in web engines so what we need instead is to
> check content that is actually served to web engines in general and to
> WebKit in particular.
>
> Note: There are straighforward CSS polyfills for the attributes previously
> mentioned. A JS polyfill would be needed for MathML nonzero unitless
> lengths (if they are really used) but removing the possibility to write "5"
> instead of "500%" is part of the general goal to align more with HTML/CSS.
> Regarding fontweight, it is known to require some extra code/tests in
> Gecko/Stylo in order to handle conflicts with mathvariant ( WebKit doesn't
> handle such conflicts
> https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/mathml/MathMLElement.cpp#L122
> ).
>
An existence of a bug in our code is not an evidence that the entire
feature can be removed.

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


Re: [webkit-dev] MathML Refresh Heads up

2019-03-15 Thread Ryosuke Niwa
On Fri, 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?
>

Ultimately, we need some testing to ensure whatever iOS and macOS apps, or
websites that specifically target WebKit and Gecko that use MathML don't
get broken by those removals. Because there isn't an easy way to do that
right now, my suggestion is not remove any features for now.

Put it another way, what's the benefit of removing features in WebKit
before fixing other MathML bugs? If the only benefit is that Blink may have
an easier time implementing the rest and therefore might be more
interoperable, I really don't buy that argument given MathML isn't
supported at all in Blink today.

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 )
>

These all seem like something out in the wild might be using.
https://github.com/search?q=mathml+fontweight=Code yields quite a few
examples in which fontweight content attribute is being used for example.

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?
>

Unfortunately, there isn't an easy way to do this right now. I wish there
was, and it's something we want to improve over time.

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


Re: [webkit-dev] MathML Refresh Heads up

2019-03-15 Thread Ryosuke Niwa
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...

- 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.
>

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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Reminder regarding formatting uint64_t

2019-03-15 Thread Ryosuke Niwa
On Thu, Feb 28, 2019 at 12:40 PM Sam Weinig  wrote:

>
>
> > On Feb 27, 2019, at 4:05 PM, Keith Rollin  wrote:
> >
> >> On Wed, Feb 27, 2019 at 2:36 PM Michael Catanzaro <
> mcatanz...@igalia.com> wrote:
> >> Hi,
> >>
> >> For the past several years, I've been regularly fixing -Wformat
> >> warnings that look like this:
> >>
> >> ../../Source/WebKit/WebProcess/WebPage/WebPage.cpp:3148:46: warning:
> >> format ‘%llu’ expects argument of type ‘long long unsigned
> >> int’, but argument 6 has type ‘uint64_t’ {aka ‘long unsigned
> >> int’} [-Wformat=]
> >> RELEASE_LOG_ERROR(ProcessSuspension, "%p - WebPage
> >> (PageID=%llu) - LayerTreeFreezeReason::ProcessSuspended was set when
> >> removing LayerTreeFreezeReason::PageTransition; current reasons are %d",
> >>
> >>
> ^~
> >> this, m_pageID, m_LayerTreeFreezeReasons.toRaw());
> >>   
> >>
> >> Problem is that uint64_t is long long unsigned int on Mac, but only
> >> long unsigned int on Linux. It can't be printed with %llu, so please
> >> use PRIu64 instead. E.g.:
> >>
> >> LOG("%llu", pageID); // wrong
> >> LOG("%" PRIu64, pageID); // correct
> >>
> >> This is good to keep in mind for any sized integer types, but uint64_t
> >> in particular since this is what causes problems for us in practice.
> >
> >
> >
> >> On Feb 27, 2019, at 14:47, Ryosuke Niwa  wrote:
> >>
> >> We should probably stop using these formatting strings in favor of
> makeString by making *LOG* functions to use makeString behind the scene.
> >
> > Formatting strings are pretty much required for the RELEASE_LOG* macros.
> These macros require a string literal for the formatting information, so
> you can’t say something like:
> >
> > RELEASE_LOG_ERROR(ProcessSuspension, makeString(this, " - WebPage
> (PageID = ", m_pageID, "), - LayerTreeFreezeReason::ProcessSuspended was
> set when removing LayerTreeFreezeReason::PageTransition; current reasons
> are ", m_LayerTreeFreezeReasons.toRaw()));
> >
> > This would not result in a string literal being passed to RELEASE_LOG,
> and you’d get a compiler error.
> >
> > You could technically get away with passing your created string along
> with a “%s” format specification:
> >
> > RELEASE_LOG_ERROR(ProcessSuspension, "%s", makeString(this, " - WebPage
> (PageID = ", m_pageID, "), - LayerTreeFreezeReason::ProcessSuspended was
> set when removing LayerTreeFreezeReason::PageTransition; current reasons
> are ", m_LayerTreeFreezeReasons.toRaw()));
> >
> > But this is not advised. The underlying Cocoa os_log facility is able to
> greatly compress the logs stored in memory and on disk, as well as get
> corresponding performance benefits, by taking advantage of the fact that
> the formatting string is a literal that can be found in the executable’s
> binary image. When you log with a particular formatting string, that string
> is not included in the log archive, but a reference to it is. In the case
> that Michael gives, a reference to the big formatting string is stored
> along with the pointer, the unsigned long long, and the integer. In the
> above example, a reference to “%s” is stored, along with the
> fully-formatted string. This latter approach takes up a lot more memory.
> >
> > So go wild with the LOG* macros, but understand the restrictions with
> the RELEASE_LOG* macros.
>
> Seems like a fun project would be to attempt to generate the format string
> literal at compile time based on the parameters passed.
>

Hm... os_log_* themselves seem to be macros:
https://developer.apple.com/documentation/os/os_log_debug?language=objc

I wonder if we can still use templates to detect types & generate the
static string though... Assuming, we can iterate over __VA_ARGS__ to
generate something like:
os_log_(ChannelStuff™, GENERATE_FORMAT_STRING(__VA_ARGS__), __VA_ARGS__)
and have GENERATE_FORMAT_STRING generate a sequence of formatString<>(_1) +
formatString<>(_2) + formatString<>(_3) + ...
where formatString generates static string which knows how to
concatenate itself using techniques like these:
https://akrzemi1.wordpress.com/2017/06/28/compile-time-string-concatenation/
https://stackoverflow.com/questions/15858141/conveniently-declaring-compile-time-strings-in-c
https://stackoverflow.com/questions/24783400/concatenate-compile-time-strings-in-a-template-at-compile-time

It's getting a bit too late for me to think straight though...

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


Re: [webkit-dev] PSA: WebCore::Quirks should define the logic to determine if a particular site specific quirk is needed or not

2019-03-12 Thread Ryosuke Niwa
On Tue, Mar 12, 2019 at 7:57 PM Michael Catanzaro 
wrote:

> On Tue, Mar 12, 2019 at 9:42 PM, Ryosuke Niwa  wrote:
> > On that note, I'd appreciate if someone who maintains PlayStation /
> > Windows ports could cleanup standardsUserAgentForURL to use
> > WebsitePolicies in WebKit layer instead of having the logic in
> > WebCore.
>
> Looks like standardUserAgentForURL is a stub for both PlayStation and
> Windows? Only the UserAgentGLib.cpp implementation of
> standardUserAgentForURL actually calls into UserAgentQuirks.cpp.


Oh, I didn't notice that.

What exactly are you hoping to have changed?


Right now, WebPage::platformUserAgent on GTK+ and Windows checks
needsSiteSpecificQuirks
and returns the result of standardUserAgentForURL.

Ideally, we want all ports to be using WebsitePolicies to set per-URL UA
string instead.
e.g. we've got rid of the code on macOS and iOS.

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


[webkit-dev] PSA: WebCore::Quirks should define the logic to determine if a particular site specific quirk is needed or not

2019-03-12 Thread Ryosuke Niwa
Hi all,

I've consolidated all site specific quirks in WebCore and WebKit into
WebCore::Quirks:
https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/page/Quirks.cpp

Going forward, any logic to determine whether a given site specific quirk
is needed or not in a given document should be added to this class instead
of scattered across our codebase and/or directly checking
Settings::needsSiteSpecificQuirks.

On that note, I'd appreciate if someone who maintains PlayStation / Windows
ports could cleanup standardsUserAgentForURL to use WebsitePolicies in
WebKit layer instead of having the logic in WebCore.

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


Re: [webkit-dev] Reminder regarding formatting uint64_t

2019-02-27 Thread Ryosuke Niwa
We should probably stop using these formatting strings in favor of
makeString by making *LOG* functions to use makeString behind the scene.

See https://trac.webkit.org/changeset/242014 for example.

- R. Niwa

On Wed, Feb 27, 2019 at 2:36 PM Michael Catanzaro 
wrote:

> Hi,
>
> For the past several years, I've been regularly fixing -Wformat
> warnings that look like this:
>
> ../../Source/WebKit/WebProcess/WebPage/WebPage.cpp:3148:46: warning:
> format ‘%llu’ expects argument of type ‘long long unsigned
> int’, but argument 6 has type ‘uint64_t’ {aka ‘long unsigned
> int’} [-Wformat=]
>  RELEASE_LOG_ERROR(ProcessSuspension, "%p - WebPage
> (PageID=%llu) - LayerTreeFreezeReason::ProcessSuspended was set when
> removing LayerTreeFreezeReason::PageTransition; current reasons are %d",
>
>
> ^~
>  this, m_pageID, m_LayerTreeFreezeReasons.toRaw());
>
>
> Problem is that uint64_t is long long unsigned int on Mac, but only
> long unsigned int on Linux. It can't be printed with %llu, so please
> use PRIu64 instead. E.g.:
>
> LOG("%llu", pageID); // wrong
> LOG("%" PRIu64, pageID); // correct
>
> This is good to keep in mind for any sized integer types, but uint64_t
> in particular since this is what causes problems for us in practice.
>
> Thanks,
>
> 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] Encoding and decoding ProcessID

2019-02-24 Thread Ryosuke Niwa
On Sun, Feb 24, 2019 at 9:55 AM Adrien Destugues 
wrote:

> We are finally starting to look into moving the Haiku port to WebKit2.
>
> We have hit one little problem I'm not sure how to solve. Our pid_t on
> 32bit Haiku is declared as a signed long integer (this is for legacy
> reasons and not something we can fix easily). Our uint32_t is a signed
> integer (not long). This creates a compilation error when using pid_t
> with IPC::Encoder, because none of the encode() functions match when
> trying to pass a pid_t in our case.
>
> Our options seems to be:
> - Cast pid_t to int32_t when encoding it. I fear this would break other
>   platforms if they decide to use a 64bit pid_t, for example
>

We definitely don't want to do this for the reason you stated.

- Add an encode(pid_t) to the IPC::Encoder. I fear on other platforms it
>   would complain that this is the same as encode(int32_t) and break the
>   build
>

We may want to wrap pid_t in a struct when passing around IPC.
That would work around this problem.

- Define WTF::ProcessID as int32_t instead of pid_t, which I think could
>   work, afte rfixing some compiler warnings (we will need to cast back
>   to pid_t when passing it to OS functions, I think)
>

We definitely don't want to do this for the same reason as the first.

Note that because 32-bit UI process on macOS would start 64-bit WebContent
process, it's very important that every IPC message explicitly specifies
the size of POD types. We can't, for example, use uintptr_t whose size
varies between 32-bit and 64-bit builds on macOS in our IPC code.

- R. Niwa
___
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

2019-02-21 Thread Ryosuke Niwa
On Thu, Feb 21, 2019 at 9:31 AM Darin Adler  wrote:

> I tried not to weigh in on this, but my view on the materials we should
> use to build the bike shed must be shared!
>
> Generally it seems neat to be able to make the code slightly more tight
> and terse by merging the function call and the return into a single
> statement.
>
> Other than not being accustomed to it, I have noticed three small things I
> don’t like about using “return” with a call to a void-returning function.
>
> - You can’t use this idiom when you want to ignore the result of a
> function, only if the function actually returns void. Often functions are
> designed with ignorable and often ignored return values. For example, it’s
> common to call something that might fail and have a good reason to ignore
> whether it failed or not. The idiom we are discussing requires treating
> those functions differently from ones that return void. If you refactor so
> that a function now returns an ignorable return value you need to visit all
> the call sites using return and change them into the two line form.
>

Perhaps this is the key distinction we want to make. Maybe if the *intent*
is to ignore the function's return value regardless of what it may return
in the future, then we should have a separate "return". If the *intent* is
to return whatever that other function returns, then we should return void.
But having to think about the intent of code isn't a great thing for coding
style guideline.

- It works for return, but not for break. I’ve seen at least one case where
> someone filled a switch statement with return statements instead of break
> statements so they could use this more-terse form. Now if we want to add
> one line of code after that switch, we need to convert all those cases into
> multi-line statements with break.
>

This is an orthogonal point but I do prefer switch'es that return directly
over one that break's then having a separate return after the switch
statement especially if the switch statement is long.

I've gotta say I'm fascinated to learn that many people are bothered by
returning void. I guess I was never bothered by it because I see a return
statement as a thing that returns the control back to the caller, not a
thing that returns a value.

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


Re: [webkit-dev] For your consideration: Naming scheme for fooIfExists/ensureFoo

2019-02-21 Thread Ryosuke Niwa
For those who joined webkit-dev after June 2013, see
https://lists.webkit.org/pipermail/webkit-dev/2013-June/thread.html#25056

On Thu, Feb 21, 2019 at 7:54 PM Ryosuke Niwa  wrote:

> I guess we never remembered to update our style guideline back in 2013.
>
> I've uploaded a patch to do this:
> https://bugs.webkit.org/show_bug.cgi?id=194930
>
> - R. Niwa
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] For your consideration: Naming scheme for fooIfExists/ensureFoo

2019-02-21 Thread Ryosuke Niwa
I guess we never remembered to update our style guideline back in 2013.

I've uploaded a patch to do this:
https://bugs.webkit.org/show_bug.cgi?id=194930

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


Re: [webkit-dev] Moving to Git

2019-02-20 Thread Ryosuke Niwa
On Wed, Feb 20, 2019 at 10:02 AM Philippe Normand  wrote:

> On Wed, 2019-02-20 at 09:40 -0800, Ryosuke Niwa wrote:
> >
> > On Wed, Feb 20, 2019 at 8:28 AM Bug Tracker <
> > bug.tracking.acco...@protonmail.com> wrote:
> > > I was curious about the status of the proposal for migrating from
> > > SVN to Git (https://trac.webkit.org/wiki/Moving%20to%20Git).
> > >
> > > The relevant page on the Trac wiki hasn't been updated for over 5
> > > years and since then Git has become much more popular (the de facto
> > > standard for new projects, more or less), while:
> > > SVN support is diminishing (e.g. in Xcode).
> > > Git support on Windows is much better than 5 years ago.
> > > It's difficult to find free robust SVN clients / UIs, unlike the
> > > plethora of options available for Git.
> > > Most young and relatively new developers (with less than 10 years
> > > of experience, like myself) are much more comfortable with Git and
> > > maybe have not even used SVN before, so moving to Git could
> > > encourage more users and contributors.
> > >
> > > Is there any progress in this direction?
> > >
> >
> > No progress has been made as far as I can tell. Every other year or
> > so, this topic comes up on webkit-dev, and the outcome is always the
> > same.
> >
> > We need a monotonically increasing revision number to track down perf
> > regressions, etc... yet nobody has put the time & effort to create a
> > solution with Git.
>
> Quoting the wiki page linked above:
>
> Some previously svn projects have worked around this. For example,
> Haiku uses automatic linear tags on each push.
> http://cgit.haiku-os.org/haiku/log/


Right, I'm totally aware of that solution because it has come up in the
past. Chromium implemented a similar solution (presumably
Cr-Commit-Position is that thing?).

What we need is a concrete plan to add the support for such a mechanism in
WebKit and update all the tools we have: buildbot, webkitpy, etc...

As far as I can tell, nobody has yet to propose such a plan for WebKit.
THAT is the biggest blocker as far as I can tell.

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


Re: [webkit-dev] Moving to Git

2019-02-20 Thread Ryosuke Niwa
On Wed, Feb 20, 2019 at 8:28 AM Bug Tracker <
bug.tracking.acco...@protonmail.com> wrote:

>
> I was curious about the status of the proposal for migrating from SVN to
> Git (https://trac.webkit.org/wiki/Moving%20to%20Git).
>
> The relevant page on the Trac wiki hasn't been updated for over 5 years
> and since then Git has become much more popular (the de facto standard for
> new projects, more or less), while:
>
>1. SVN support is diminishing (e.g. in Xcode).
>2. Git support on Windows is much better than 5 years ago.
>3. It's difficult to find free robust SVN clients / UIs, unlike the
>plethora of options available for Git.
>4. Most young and relatively new developers (with less than 10 years
>of experience, like myself) are much more comfortable with Git and maybe
>have not even used SVN before, so moving to Git could encourage more users
>and contributors.
>
>
> Is there any progress in this direction?
>

No progress has been made as far as I can tell. Every other year or so,
this topic comes up on webkit-dev, and the outcome is always the same.

We need a monotonically increasing revision number to track down perf
regressions, etc... yet nobody has put the time & effort to create a
solution with Git. I stay firmly opposed to making the Subversion-to-Git
transition until such a solution is devised and implemented in various
tools we use.

And no, we can't use git-bisect because performance tests take anywhere
from 30min to an hour, and we may need ~8 runs to detect a statistically
significant difference of 1% or less, meaning that even deciding whether a
given perf regression exists between revision X and Y might take ~8 hours.

I'm increasingly frustrated that people keep bringing this topic up without
ever resolving the issues that have been raised in the past. Keep bringing
up the same topic without presenting a solution to the problems that have
been raised in the past 8 years or so of the discussion is simply
unproductive.

- R. Niwa
___
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

2019-02-19 Thread Ryosuke Niwa
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
and Alex both expressed preferences for being able to return void, and Saam
pointed out that there is a lot of existing code which does this. Zalan
also said he does this in his layout code.

- R. Niwa
___
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

2019-02-07 Thread Ryosuke Niwa
On Thu, Feb 7, 2019 at 12:53 PM Tim Horton  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();
> > }
>
> ⸘do people do this‽
>

I much prefer doing this in my own code but stay away from it in WebKit
because we tend to have a separate return.

> I prefer:
> >
> > void g()
> > {
> > if (...) {
> > f();
> > return
> > }
> > f();
> > }
> >
> > Does it bother you? For the former? For the latter? Update our style
> guide?
>
> +1 to a style guide update
>

Yeah, we might as well as codify it in the style guideline for clarity.

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


Re: [webkit-dev] Tools/TestWebKitAPI

2019-02-05 Thread Ryosuke Niwa
On Tue, Feb 5, 2019 at 5:06 PM Michael Catanzaro 
wrote:

> On Tue, Feb 5, 2019 at 4:01 PM, ross.kirsl...@sony.com wrote:
> > That said, I would expect specifically the Tools/TestWebKitAPI/Tests
> > subdirectory to be the thing moved to APITests/, since the code that
> > actually runs the tests is as much a “tool” as DRT, WKTR, or
> > various other test-running scripts under
> >  Tools/Scripts are.
>
> I dunno, we could do it either way, but there's value in keeping
> related code together. E.g. our tests subclass lots of TestWebKitAPI
> classes, so we'd have code in APITests/ subclassing stuff under
> Tools/TestWebKitAPI/. It's much more tightly-coupled than, say, the
> layout tests are to TestController/WKTR, which communicates with layout
> tests over well-defined interfaces. In contrast, our API tests really
> depend on implementation details of TestWebKitAPI and they often have
> to be changed in tandem.
>

Yeah, I'd prefer keeping all the related code for TestWebKitAPI in one
place.
We have build scripts in Source too so there is a precedence for this.

We can probably push the harness code into APITests/harness or something.

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


Re: [webkit-dev] Tools/TestWebKitAPI

2019-02-05 Thread Ryosuke Niwa
Moving it to top-level APITests directory sounds good to me although I'm
not volunteering to fix any Xcode or Apple internal build related issues.

- R. Niwa

On Tue, Feb 5, 2019 at 1:07 PM  wrote:

> APITests/ would seem like an improvement to me...although given that this
> would be the seventh *Tests/ directly, it also makes me wonder if those
> should all be moved under a top-level Tests/ directory? __
>
> (Either way, I'd be happy to help with Xcode rearranging if needed, at
> least to the point of pleasing the external builds.)
>
> Ross
>
> On 2/5/19, 12:13 PM, "webkit-dev on behalf of Michael Catanzaro" <
> webkit-dev-boun...@lists.webkit.org on behalf of mcatanz...@igalia.com>
> wrote:
>
> Hi,
>
> I started writing this mail to propose creating a separate ChangeLog
> for Tools/TestWebKitAPI, to make the Tools/ ChangeLog more focused on,
> you know, actual tools. So many of my changes under Tools/ are to the
> API tests.
>
> But this reminded me that TestWebKitAPI is the only testsuite we have
> under Tools/. All the rest are toplevel directories:
>
> JSTests/
> LayoutTests/
> ManualTests/
> PerformanceTests/
> WebDriverTests/
> WebPlatformTests/
>
> So it almost doesn't fit under Tools/ at all, right? Would there be
> any
> objections to moving it to a toplevel WebKitAPITests/ or just
> APITests/
> directory? That would nicely parallel all our other tests.
>
> (The practical objection is that moving anything is difficult for
> someone without familiarity with both XCode and CMake. I'd only be
> able
> to help with the CMake portion of the move. And then Apple internal
> build will inevitably break too, so someone would need to volunteer to
> care for that.)
>
> If we don't want to move it, I guess a new ChangeLog file would be
> fine? :)
>
> Michael
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev 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"

2019-02-01 Thread Ryosuke Niwa
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


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

2018-12-19 Thread Ryosuke Niwa
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.

___
> 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

2018-12-18 Thread Ryosuke Niwa
On Tue, Dec 18, 2018 at 11:35 AM Michael Catanzaro 
wrote:

> I know I'm getting a bit far afield here, but:
>
> On Mon, Dec 17, 2018 at 9:26 PM, Ryosuke Niwa  wrote:
> > But then our behavior of HashMap which doesn't accept the POD
> > integral value of 0 as a key
>
> This behavior is really unexpected and dangerous [1], and we should
> seriously consider changing it. No doubt lots of bugs caused by this
> are just waiting to be uncovered. I've been working on WebKit since
> 2014 and didn't know about this until last month.


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.

Another oddity: I recently learned that AtomicStrings are actually
> interned strings. WTF. Why not call them that? I had thought for years
> that they were strings safe to be shared across threads, like other
> atomics. Not at all. Maybe this was dumb of me, but it could have been
> avoided by better naming.
>

This topic has been discussed extensively in the past:
https://lists.webkit.org/pipermail/webkit-dev/2013-June/024988.html

- R. Niwa
___
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

2018-12-17 Thread Ryosuke Niwa
On Mon, Dec 17, 2018 at 6:40 PM Fujii Hironori 
wrote:

>
> On Tue, Dec 18, 2018 at 11:16 AM Maciej Stachowiak  wrote:
>
>>
>>  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.
>>
>>
> Don't recommend such checks. It is simply use-after-move. The expression
> WTFMove(x) means marking x as disposable.
>

That's simply not true. The semantics of WTFMove / std::move is really that
of a type cast. I think std::move was ill-named. It really should have been
called std::movable_cast or something. Also, as Geoff has already pointed
out, the behavior of STL doesn't prevent us from writing our own template
library to always have a very well specified & good state after
std::move'ed & its value was move-constructed.

It's one thing to consider that new WebKit contributors who are familiar
with C++ semantics of std::move and std::optional getting confused by
WebKit's implementation of std::option. But then our behavior of HashMap
which doesn't accept the POD integral value of 0 as a key, and how Ref and
RefPtr work and they're used by our WebCore code is probably more
problematic than this std::optional behavior.

In general, I find these kinds of dogmatic adoption of the best practices /
recommended ways of coding to be highly problematic. We shouldn't care who
or what entity recommends writing code in one way or another. We should be
questioning every and each recommendation anyone makes, and judging for
ourselves whether it makes a sense for the WebKit project.

For example, there is a group of people who swear by always wrapping each
single statement with { ~ } as a way of preventing bugs which stems from
forgetting { ~ } around multiple statements. Yet in my nine years of
writing & reviewing code in WebKit, I've never once came across such a
mistake made by either me or any other contributor.

- R. Niwa
___
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

2018-12-17 Thread Ryosuke Niwa
Let me add this.

The situation we have here is analogous to having a member function
"move()" which leave std::optional in undefined state as in:

std::optional a;
std::optional b = a.move();

would leave a in some undefined state. I don't care what C++ standards say
or what STL does. That's insane.
Every object should remain in a well defined state after performing an
operation.

- R. Niwa


On Mon, Dec 17, 2018 at 4:22 PM Ryosuke Niwa  wrote:

> It's true that WTFMove or std::move doesn't do anything if the moved
> variable is not used because WTFMove / std::move is just a type cast.
>
> However, that behavior is orthogonal from the issue that calling WTFMove /
> std::move on std::optional, and the returned value is assigned to another
> std::optional, the original std::optional will be left a bad state.
>
> I completely disagree with your assessment that this calls for the use of
> std::exchange.
>
>
> On Mon, 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 ot

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

2018-12-17 Thread Ryosuke Niwa
It's true that WTFMove or std::move doesn't do anything if the moved
variable is not used because WTFMove / std::move is just a type cast.

However, that behavior is orthogonal from the issue that calling WTFMove /
std::move on std::optional, and the returned value is assigned to another
std::optional, the original std::optional will be left a bad state.

I completely disagree with your assessment that this calls for the use of
std::exchange.


On Mon, 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  wrote:
>>
>>
>>
>> On Dec 17, 2018, at 10:27 AM, Alex Christensen 
>> wrote:
>>
>> On Dec 14, 2018, at 1:37 PM, Chris Dumez  wrote:
>>
>>
>> As far as I know, our convention in WebKit so far for our types has been
>> that types getting moved-out are left in a valid “empty” state.
>>
>> This is not necessarily true.  

  1   2   3   4   5   6   7   8   9   10   >