Re: [webkit-dev] Network Information API reboot: request for early feedback

2021-08-30 Thread Ryosuke Niwa via webkit-dev
On Mon, Aug 30, 2021 at 2:58 AM Thomas Steiner  wrote:

> On Mon, Aug 30, 2021 at 11:06 AM Ryosuke Niwa  wrote:
>
>> On Mon, Aug 30, 2021 at 1:17 AM Thomas Steiner  wrote:
>>
>>> On Sun, Aug 29, 2021 at 1:00 AM Ryosuke Niwa  wrote:
>>>
>>>> I don't think exposing the information about whether the connection is
>>>> metered or not is acceptable from the privacy standpoint. Based on the IP
>>>> address of a user & this metered status, a website may even be able to tell
>>>> what kind of carrier plan a given user is in.
>>>>
>>>
>>> Thanks for the reply, Ryosuke! Just to clarify, the `metered` attribute
>>> would be a manual user setting, not a browser heuristic. This means you
>>> could easily mark your all-data included WiFi at home as metered if you
>>> wanted to, or, on the opposite end, mark your roaming data plan you
>>> purchased for a ton of money at the airport as unmetered. None of this
>>> happens without the user voluntarily revealing the information.
>>>
>>
>> I don't think it's fair to characterize any given user telling the OS to
>> reduce the data usage as a consent to be profiled by random websites. I
>> would certainly not expect such information to be exposed to ad trackers
>> and alike.
>>
>
> Apple seems to see no issue in exposing this information to iOS/iPadOS
> apps: https://developer.apple.com/videos/play/wwdc2019/712/?time=959.
>
>
>> You could make the same argument for turning on low power mode but
>> battery level being low or having low power mode turned on may reveal the
>> user's socioeconomic status or user's immediate need to take
>> certain actions. It can lead to egregious consequences like this:
>> https://www.theverge.com/2016/5/20/11721890/uber-surge-pricing-low-battery.
>> I definitely would not want to be seeing ads promoting new SIM cards or ads
>> for a cafe with free WiFi service nearby just because I requested my phone
>> to reduce data usage.
>>
>
> Yes, bad things like that can happen, and the fact that companies like
> Uber make "evil" use of available information is no secret. At the same
> time, companies that make "good" use of information, like Algolia's example
> (
> https://www.algolia.com/blog/engineering/netinfo-api-algolia-javascript-client/),
> hopefully outweigh the disadvantages. We don't prohibit hammers because
> they can be abused as a weapon.
>

Please refer to https://www.w3.org/TR/design-principles/#safe-to-browse.
It's not okay to add a new API which makes the web less safe & private for
users just because the API can be used for good purposes.

And again, the information is exposed to random native apps that can
> likewise profile you. I agree there is a difference between a random native
> app and a random website, but at the same time we have mitigations like
> third-party blocking (and ITP on Apple devices) that make such profiling
> harder and harder.
>

The web and native apps have fundamentally different security &
privacy models. We don't let websites access random files in your system
without an explicit user consent.

On Mon, Aug 30, 2021 at 6:54 AM Thomas Steiner  wrote:

> > None of this happens without the user voluntarily  revealing the
>> > information.
>>
>> How would that possibly work? A new type of permission prompt? It's
>> easy for users to decide whether a website should have geolocation or
>> microphone access, but the risk here is just extra entropy, which is
>> going to be real hard to explain to users.
>>
>
> The current thinking is that there would be no additional permission
> needed. Note that the proposal reduces the overall entropy compared to the
> current API, which exposes more information:
> https://wicg.github.io/netinfo/#networkinformation-interface (compared to
> https://raw.githack.com/tomayac/netinfo/relaunch/index.html#the-networkinformation-interface
> ).
>

That's an API WebKit has never supported and never will for various privacy
& security reasons. Also, I don't think the notion that this old API
exposed more information is necessarily true. The user actively choosing to
use low data mode is very much new information that websites couldn't
necessarily infer from the old API.

Overall, I don't think there is much left to discuss here. What you're
proposing will introduce a serious privacy concern, and it's not acceptable.

I'm going to stop replying to this thread going forward since I have other
things to do but please note that my lack of future response does not, in
any way, constitute a lack of signal or acceptance of an argument, idea, or
amendment to the proposal.

Apple's 

Re: [webkit-dev] Network Information API reboot: request for early feedback

2021-08-30 Thread Ryosuke Niwa via webkit-dev
On Mon, Aug 30, 2021 at 1:17 AM Thomas Steiner  wrote:

> On Sun, Aug 29, 2021 at 1:00 AM Ryosuke Niwa  wrote:
>
>> I don't think exposing the information about whether the connection is
>> metered or not is acceptable from the privacy standpoint. Based on the IP
>> address of a user & this metered status, a website may even be able to tell
>> what kind of carrier plan a given user is in.
>>
>
> Thanks for the reply, Ryosuke! Just to clarify, the `metered` attribute
> would be a manual user setting, not a browser heuristic. This means you
> could easily mark your all-data included WiFi at home as metered if you
> wanted to, or, on the opposite end, mark your roaming data plan you
> purchased for a ton of money at the airport as unmetered. None of this
> happens without the user voluntarily revealing the information.
>

I don't think it's fair to characterize any given user telling the OS to
reduce the data usage as a consent to be profiled by random websites. I
would certainly not expect such information to be exposed to ad trackers
and alike. You could make the same argument for turning on low power mode
but battery level being low or having low power mode turned on may reveal
the user's socioeconomic status or user's immediate need to take
certain actions. It can lead to egregious consequences like this:
https://www.theverge.com/2016/5/20/11721890/uber-surge-pricing-low-battery.
I definitely would not want to be seeing ads promoting new SIM cards or ads
for a cafe with free WiFi service nearby just because I requested my phone
to reduce data usage.

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


Re: [webkit-dev] Network Information API reboot: request for early feedback

2021-08-28 Thread Ryosuke Niwa via webkit-dev
I don't think exposing the information about whether the connection is
metered or not is acceptable from the privacy standpoint. Based on the IP
address of a user & this metered status, a website may even be able to tell
what kind of carrier plan a given user is in.

- R. Niwa

On Fri, Aug 20, 2021 at 7:51 AM Thomas Steiner via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> Hey WebKit folks,
>
> I have rebooted the Network Information API recently. This is all in a
> relatively early stage, but I thought now would be a good time to get your
> feedback on the proposal:
>
> - Motivational doc:
> https://docs.google.com/document/d/1RDA23zSNdDuIcxZTX9Xo3zlD2fxf8dZg9-e0YaJQv0g/edit?usp=sharing
> - Explainer: https://github.com/tomayac/netinfo/blob/relaunch/README.md
> - Spec draft: https://ghcdn.rawgit.org/tomayac/netinfo/relaunch/index.html
>
> Here is the short version:
>
> ```js
> // Is the current network a metered network according to the OS-level
> setting
> // in, e.g., Android or Windows, i.e., _without_ the UA guesstimating it.
> The UA
> // may provide its own (override) setting, though:
> navigator.connection.metered;
> // false
>
> // What is the sustained connection speed, as measured on the OS-level (à
> la
> // `nettop`) for a sliding window and bucketed in buckets of exponentially
> // growing size in bit per second, e.g., 25,000,000 (25 Mbit/s), 50,000,000
> // (50 Mbit/s). It's fine to report `Infinity` if the user agent doesn't
> want to
> // reveal more, or if the sustained speed isn't known yet.
> navigator.connection.metered;
> // 5000
>
> // Changes to either of the attributes are exposed via an event:
> navigator.connection.addEventListener("change", (event) => {
>   console.log(event);
> });
> ```
>
> Each of the attributes is accompanied by a client hint header that
> reflects the attribute:
>
> ```bash
> Sec-CH-Metered-Connection: 1
> Sec-CH-Sustained-Speed: 5000
> ```
>
> Thanks in advance for your thoughts, here, or in the motivational document.
>
> Cheers,
> Tom
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Identifiers in Log and Blame

2021-08-17 Thread Ryosuke Niwa via webkit-dev
Seems like a good improvement but I really don't use command line tools to
see my blame. What I need is this getting applied to online tools like trac
and GitHub.

- R. Niwa

On Tue, Aug 17, 2021 at 10:57 AM Jonathan Bedard via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> Hi folks,
>
> As we move towards using Git as our version control system, more services
> and scripts will be using identifiers instead of revisions or hashes.
> Already, build.webkit.org, results.webkit.org and ews-build.webkit.org
>  all display identifiers alongside revisions.
> Early in the transition process, we added the git-webkit find command,
> which converts between hashes, revisions and identifiers.  Recently, we
> added the git-webkit log and git-webkit blame commands to better support
> identifiers and native Git checkouts.
>
> git-webkit log is a wrapper around git log or svn log (depending on your
> checkout) and annotates the output of those commands with identifiers and
> revisions. git-webkit log passes the arguments you provide it to your
> native source code management system, it’s output looks something like this:
>
> commit 240602@main (fe5476762fc34d2a5547b7d2d8116faa7275acd7, r281148)
> Author: Eric Hutchison 
> Date:   Tue Aug 17 17:46:39 2021 +
>
> [Monterey wk2 Release]
> performance-api/paint-timing/paint-timing-with-worker.html is a flaky crash.
> rdar://82036119.
> ...
>
> git-webkit blame is a wrapper around git blame or svn blame (again,
> depending on your checkout) and also annotates the output of these commands
> with identifiers:
>
> 230258@main (Keith Rollin2020-10-08 19:10:32 +  1) MODULES =
> Source Tools
> 184786@main (Jonathan Bedard 2017-02-02 18:42:02 +  2)
> 229628@main (Keith Rollin2020-09-22 18:37:51 +  3) define
> build_target_for_each_module
> 229628@main (Keith Rollin2020-09-22 18:37:51 +  4)  for dir
> in $(MODULES); do \
> 229628@main (Keith Rollin2020-09-22 18:37:51 +  5)
> ${MAKE} $@ -C $$dir PATH_FROM_ROOT=$(PATH_FROM_ROOT)/$${dir}; \
> 229628@main (Keith Rollin2020-09-22 18:37:51 +  6)
> exit_status=$$?; \
> 229628@main (Keith Rollin2020-09-22 18:37:51 +  7)  [
> $$exit_status -ne 0 ] && exit $$exit_status; \
> 229628@main (Keith Rollin2020-09-22 18:37:51 +  8)  done; true
> 229628@main (Keith Rollin2020-09-22 18:37:51 +  9) endef
> ...
>
> Both commands can switch the commit representation they display with the
> --identifier, --hash and --revision options.
>
> Additionally, for those using Git checkouts, the conversion from
> Subversion revisions to Git hashes no longer requires your checkout to be
> configured with git-svn. Contributors may find that something like git
> checkout r281146 satisfies whatever need they have to interact with
> Subversion from Git.
>
> All of this has been landed on trunk/main as of r280864/240404@main.
>
> Jonathan
> ___
> 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] content-visibility (Was Re: Request For Position on CSS containment)

2021-06-24 Thread Ryosuke Niwa via webkit-dev
Please rename the subject when you're going to discuss the work on a new
feature.

On Thu, Jun 24, 2021 at 9:44 AM cathiechen via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> We made a lot of progress regarding CSS containment [1].
> Rob and I have finished the layout containment and size containment [2].\o/
> And the patches of paint containment and style containment are ready for
> review now [3].
>
> So we think now it's time to move on to content-visibility:
> (https://www.w3.org/TR/css-contain-2/#content-visibility)
>

That seems premature. Have we implemented all the perf optimizations for
layout, size, & paint containment? I'd rather not start piling on more
features before we get to a point where we're happy with the performance of
these features.

Since content-visibility depends on paint and style containment, we will do
> some specification research first, then prototype it based on Rob's patches.
>

Does the research part also include making a judgement call as to whether
it's a good idea at all? It's wholly unclear to me that content-visibility
is a feature we'd like to implement in WebKit given its implications to the
accessibility and other browser features.

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


[webkit-dev] WeakHashMap

2021-06-11 Thread Ryosuke Niwa via webkit-dev
Hi all,

I've added WeakHashMap to WTF in https://commits.webkit.org/r278803, which
allows the use of WeakPtr as keys. Like WeakHashSet, WeakHashMap does not
immediately delete the key or the value when the object pointed by
WeakPtr goes away (i.e. WeakPtrImpl::m_ptr becomes nullptr).

Instead, it relies on rehashing and amortized deletion to remove these
entries. This happens either when enough items are inserted or removed such
that the underlying HashMap goes through rehashing or when WeakHashMap's
entry is accessed (get, find, advancing an iterator, etc...) or mutation
(inserting, removing, etc...) more than twice the number of items in the
underlying HashMap.

Due to this amortized deletion behavior, there is no unbound growth of
HashMap even if no attempt to cleanup null WeakPtr is made. However, if
WeakHashMap is never accessed or mutated, all WeakPtrImpl as well as the
corresponding hash map values will be kept alive. In the situation where
this is undesirable (e.g. WeakHashMap could retain a large object as its
values or a large number of keys could become stale), call
WeakHashMap::nullReferences() to trigger the cleanup manually.

- 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: Compute Pressure API

2021-05-06 Thread Ryosuke Niwa via webkit-dev
On Thu, May 6, 2021 at 10:55 AM Olivier Yiptong 
wrote:
>
> Hi, and thank you for your prompt response. Replies inline.
>>
>>1. CPU utilization isn't something which can be easily computed or
>>reasoned on asymmetric multi-core CPUs, not to mention the dynamic
>>adjustment of CPU frequency further complicates the matter.
>
>
> Are you alluding to CPU architectures like big.LITTLE? and of dynamic
clock frequencies?
>
> This proposal takes this into account, here's how:
>
...
>
> The goal of CPU Speed is to abstract away those details and provide clock
frequency data that is actionable and yet preserves user privacy.

The issue isn't that it's unclear to come up with some number that
represents the current CPU load. I'm sure we can come up with some number.
The issue lies in how such a number can be interpreted.

In our experience with iOS and macOS, CPU utilization & speed are poor
metric to use in order to adjust any software behavior because those things
are highly dynamic and respond quickly based on what an application is
doing. It's a lot better to *measure* the actual runtime taken to do a
specific task and adjust the behavior accordingly.

>>2. Whether the system itself is under a heavy CPU load or not should
not
>>have any bearing on how much CPU time a website is entitled to use
because
>>the background CPU utilization may spontaneously change, and the
reason of
>>a high or a low CPU utilization may depend on what the website is
doing;
>>e.g. a daemon which wakes up in a response to a network request or
some
>>file access.
>
> On the web, people write one-size-fits-all applications. Those need to
run across devices of varying compute power capabilities.
> For compute-intensive applications, this poses problems and leads to bad
UX in the absence of hints from the system.

This is precisely why we can't rely on CPU utilization or speed to
determine how fast the application or specific task thereof will complete.
There is a huge variability in each CPU's instructions per cycle, and how
much work can be performed in each cycle. The size of L1/L2/L3, cache
coherency mechanisms (with other cores potentially), prefetcher, the
capability and size of the branch predictor, etc... can all influence how
fast a given application will run. We can't estimate how fast an
application will run based purely on the percentage of CPU utilization or
at what fraction of the maximum frequency / power CPU is operating.

> The proposal does not enforce any additional usage of resources, but
instead allows apps to make informed decisions.
> It is common for compute-intensive applications to self-throttle to
provide a good UX.
> One example is gaming: reducing drawing distance, effects, texture sizes
or level of detail for geometries if it's affecting frame rate.

Those games are better off dynamically adjusting their behavior based on
how long each frame is taking to draw.

> On the Nintendo Switch, game engines have the feature to reduce the
rendering resolution when framerate drops occur or are anticipated.
> On the Nintendo Switch, the compute power capability depends on whether
the device is plugged in or in portable mode.
> There might also be thermal factors.

Here is the thing. On Apple's platforms, if an application adjusts itself
to do less work, then we'd start throttling CPU or stop using P-cores
automatically to conserve the battery so then you might drop frames because
CPU is running at a slower speed or no longer running in P-cores and takes
sometime to ramp up again. It is impractical for an application to respond
to these changes based on CPU utilization or speed information because the
states are changing so dynamically over time.

It's also highly inappropriate for a web app to assume that it can use all
the remaining CPU resources when there could be other windows and
applications the user is interacting with.

> For the Compute Pressure API, we've examined a few use-cases, and they
are detailed in the explainer.
> This is similar to video conferencing needs, reducing the number of
simultaneous video feeds, or diminishing the processing of image processing
effects.
>
> Indeed, the reason for the load might be intrinsic to the application, or
extrinsic, based on what's going on with the system.
> This API, as proposed, provides system-level hints that help applications
make informed decisions to provide a good UX for users.

We're very much uncomfortable with exposing this kind of invasive system
information in a Web API, and more importantly, web applications to adjust
its workload based on such information. JavaScriptCore's is a highly
sophisticated JIT engine that is known to perform very well across variety
of hardware classes and generations; yet it doesn't adjust its workload
based on CPU utilization or power state of the system. Given that, we are
highly skeptical with your premise that an API like this is needed to
create a performant application in the first 

Re: [webkit-dev] Request for Position: Compute Pressure API

2021-05-05 Thread Ryosuke Niwa via webkit-dev
On Wed, May 5, 2021 at 11:37 AM Olivier Yiptong via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

>
> We propose a new API that conveys the utilization of CPU resources on the
> user's device. This API targets applications that can trade off CPU
> resources for an improved user experience. For example, many applications
> can render video effects with varying degrees of sophistication. These
> applications aim to provide the best user experience, while avoiding
> driving the user's device in a high CPU utilization regime.
>
> High CPU utilization is undesirable because it strongly degrades the user
> experience. Many smartphones, tablets and laptops become uncomfortably hot
> to the touch. The fans in laptops and desktops become so loud that they
> disrupt conversations or the users’ ability to focus. In many cases, a
> device under high CPU utilization appears to be unresponsive, as the
> operating system may fail to schedule the threads advancing the task that
> the user is waiting for.
>
> Thanks!
>
>
>- Specification Title: Compute Pressure API
>- Specification URL: https://oyiptong.github.io/compute-pressure/
>- Explainger:
>https://github.com/oyiptong/compute-pressure/blob/main/README.md
>- ChromeStatus.com entry:
>https://chromestatus.com/features/5597608644968448
>- TAG design review request:
>https://github.com/w3ctag/design-reviews/issues/621
>- Mozilla Request for Position:
>https://github.com/mozilla/standards-positions/issues/521
>
> We do not support this proposal for the reasons including but not limited
to:

   1. CPU utilization isn't something which can be easily computed or
   reasoned on asymmetric multi-core CPUs, not to mention the dynamic
   adjustment of CPU frequency further complicates the matter.
   2. Whether the system itself is under a heavy CPU load or not should not
   have any bearing on how much CPU time a website is entitled to use because
   the background CPU utilization may spontaneously change, and the reason of
   a high or a low CPU utilization may depend on what the website is doing;
   e.g. a daemon which wakes up in a response to a network request or some
   file access.
   3. The proposal as it currently stands seems to allow a side channel
   communication between different top-level origins (i.e. bypasses storage
   partitioning). A possible attack may involve busy looping or doing some
   heavy computation in one origin and then observing that CPU utilization
   goes up in another. We've reported an attack of a similar nature in
   https://bugs.chromium.org/p/chromium/issues/detail?id=1126324.

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


Re: [webkit-dev] New EWS Non-Unified builder

2021-05-01 Thread Ryosuke Niwa via webkit-dev
On Fri, Apr 30, 2021 at 10:16 AM Alexey Proskuryakov via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> These points from my yesterday email remain without responses:
>
> 1. Cannot have an EWS without corresponding post-commit queue.
>

Yeah, we should first add a bot.

2. It doesn't appear like we looked into whether there are any ways to
> mitigate the problem other that this most costly one.


The reason build may break when a new file is added or removed is because
all existing files shift. We could mitigate this if we always added a new
file at the end of existing unified build files, and always left an empty
spot when removing a file. I believe we don't unify files across top-level
directories so I could imagine, for example, we can say that we always add
a file at the end of Sources.txt per top-level directory. We could then
periodically sort files lexicologically with an understanding that this
will require a lot of build fixes to be applied at the same time.

For ports that don't use unified builds, one solution might be to create
wrapper translation units or unified header files. Say we're compiling
A.cpp and B.cpp as Unified1.cpp, then we'd basically create the union of
header files included in A.cpp and B.cpp and put into Unified1.h. Then this
port will build wrapper translation units A-unified.cpp and B-unified.cpp
each of which respectively includes A.cpp and B.cpp as well as Unified1.h.

- R. Niwa

> 30 апр. 2021 г., в 8:43 AM, Darin Adler via webkit-dev <
> webkit-dev@lists.webkit.org> написал(а):
>
>
> > OK. I acknowledge my view on this is different from the others
> commenting here, perhaps because of different ideas about what is hard and
> requires expertise. I won’t stand in the way of changes you want to make.
> You know my view now.
> >
> > — Darin
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] New EWS Non-Unified builder

2021-05-01 Thread Ryosuke Niwa via webkit-dev
On Thu, Apr 29, 2021 at 9:18 PM Darin Adler via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> > On Apr 29, 2021, at 9:06 PM, Tim Horton via webkit-dev <
> webkit-dev@lists.webkit.org> wrote:
> >
> > it is definitely highly annoying
>
> It’s possible that where my thinking differs from others on this is that I
> don’t think shifting annoying work from one set of commits (the ones adding
> a new file) to a different set (the ones unknowingly adding need for a new
> include for non-unified builds) is a significant improvement. Adding more
> EWS bubbles has a cost.
>

One key benefit of keeping non-unified builds working is that it would make
build brokerage more predictable. Today, when you're adding, removing, or
renaming an existing new file, it may compile just fine on the particular
port / platform you're using locally yet can still cause a build failure in
other ports / platforms since different ports / platforms almost always
compile a different set of translation units. If we kept unified builds
always working, then the build failure will happen more consistently,
making it easier to detect before uploading a patch instead of after
observing EWS failures or worse after landing commits because EWS didn't
have coverage.

Every time someone new starts working on the WebKit project, the topic of
mysterious build failures caused by the unified build system comes up as a
topic. It's yet another random thing a new developer would have to learn.
Anything we can do to reduce the total amount of random knowledge someone
has to have to have to be productive in the WebKit project is a positive
change in my opinion.

- 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 First-Party Sets

2021-04-14 Thread Ryosuke Niwa via webkit-dev
On Tue, Apr 13, 2021 at 1:52 PM Kaustubha Govind via webkit-dev
 wrote:
>
> [Resending after subscribing to webkit-dev, since my previous message bounced 
> back]
>
> On Tue, Apr 13, 2021 at 4:47 PM Kaustubha Govind  
> wrote:
>>
>> Hi Maciej, Webkit team,
>>
>> Now that First-Party Sets has been incubating within PrivacyCG for ~6 
>> months, I wanted to check with you to see if you have reconsidered your 
>> position on the proposal. It seems WebKit may intend to use First-Party Sets 
>> relationships to apply to browser policies other than cookie blocking 
>> (https://github.com/w3ctag/design-reviews/issues/342#issuecomment-801517385),
>>  but I wasn't sure whether to construe that as positive progress in your 
>> position.

I'm not certain in what way John's comment could be interpreted like
that but WebKit does not have such a plan and Apple's WebKit team
continues to oppose this proposal. I don't think there has been
substantive changes to address the various concerns we have raised so
far.

- 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: Aligning high-resolution timer granularity to cross-origin isolated capability

2021-03-18 Thread Ryosuke Niwa via webkit-dev
On Thu, Mar 18, 2021 at 12:26 AM Yoav Weiss via webkit-dev
 wrote:
>
> On Wed, Mar 17, 2021 at 5:51 PM Geoff Garen  wrote:
>>
>> For the 100 microsecond value — our research suggests that you need a much 
>> higher value in vulnerable contexts.
>>
>> For the guaranteed isolated case — have you considered the use of high 
>> precision time to carry out non-Spectre timing attacks?
>
> Could you elaborate on those 2 points?

We've made a conclusion, based on our prior research, that in order to
successfully mitigate Spectre / Meltdown class of attacks, we can't
allow 100μs precision timing measurements. As such, we have no plan or
desire to increase the precision of "high precision" time from 1ms to
100μs. I'm not going to provide details as to how or why due to the
nature of the topic.

The second point is that there are dangerous timing attacks besides
from Spectre/Meltdown that are effective with a precision meaningfully
higher than 100μs. This is why the precision of WebKit's high
resolution time had been reduced to 100μs in
https://trac.webkit.org/r209462 even prior to the issue of Spectre /
Meltdown were identified. There are a number of literatures on various
kinds of timing attacks possible, but again, I'd refrain from
disclosing details here.

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

2021-03-15 Thread Ryosuke Niwa via webkit-dev
On Mon, Mar 15, 2021 at 7:32 AM Daniel Vogelheim via webkit-dev
 wrote:
>
> I'd like to request a position statement on the proposed Sanitizer API.
>
> The Sanitizer API wants to build an HTML Sanitizer right into the web 
> platform. The goal is to make it easier to build XSS-free web applications. 
> The intended contributions of the Sanitizer API are: Making a sanitizer more 
> easily accessible to web developers; be easy to use and safe by default; and 
> shift part of the maintenance burden to the platform.
>
> Currently available are an explainer and an early spec draft, and early 
> prototype implementations in Chromium & Firefox, behind flags.

I'm gathering more feedback internally at Apple but here's immediate
feedback I can give you: even if this was an useful API for web
developers, we won't use it to sanitize the content from / to the
system pasteboard (a.k.a clipboard on Windows) since we rely on style
& rendering information and apply various transformations such as
inlining all the style rules for that purpose. Secondly, we probably
won't reuse this code for sanitizing contents inside our engine since
using hash maps of element names and attribute names per element to
allow or block markup would be simply too inefficient. Reusing
concepts defined in this specification as a mechanism involved by
other specifications seems okay provided we agree that this API / spec
is an overall good idea based on more broader discussion.

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

2021-02-23 Thread Ryosuke Niwa via webkit-dev
On Tue, Feb 23, 2021 at 5:06 PM Mason Freed via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> > On Fri Feb 19 20:36:12 PST 2021 Ryosuke Niwa via webkit-dev <
> > webkit-dev at lists.webkit.org> wrote:
> >
> > I replied in the issues directly so that people outside of the WebKit
> > community can follow the discussion.
>
> Thanks! I've replied there also.
>

The issue with the semantics of getInnerHTML is problematic enough that
we'd object to this feature as long as that's included in its current shape.

> How does one specify a declarative shadow root to use a specific custom
> > element registry?
>
> Well, I do see this as something that is better designed as part of the
> scoped custom element registry proposal. But the basic idea would be to
> just to add an attribute that allows the declarative shadow root to opt
> out of automatically using the global registry:
>
> 
>
> and that would keep any custom elements contained within the shadow root
> from automatically upgrading based on the global registry. Maybe by just
> assigning an empty custom registry to that shadow root. We'll need to add
> an attribute to ShadowRoot, as part of the SCER proposal, to allow custom
> elements to then set the appropriate custom registry later.
>

That seems to indicate that none of the custom elements inside a
declarative shadow root can be upgraded until all its ancestor custom
elements which use a custom element registry have been upgraded. This would
make the declarative shadow DOM's perf benefit less attractive IMO.

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

2021-02-19 Thread Ryosuke Niwa via webkit-dev
On Fri, Feb 19, 2021 at 2:38 PM Mason Freed via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> On Thu Feb 18 17:08:18 PST 2021 Ryosuke Niwa via webkit-dev <
> webkit-dev at lists.webkit.org> wrote:
>
> > The latest proposal does solve much of the problems we've identified in
> the
> > past, and it's looking to be a promising direction. Do you have any
> example
> > website or app that you can share with which resulted in the observed 15%
> > improvement in FCP? That would be a very intriguing observation and would
> > substantiate the support for this feature.
>
> Glad to hear you think it's promising! The example is from the AMP team,
> and you can see more detail at the Origin Trial results summary here:
>
> https://docs.google.com/document/d/1QmBKxQLE81PsMzyPCvYhzqRAn4hxz61Jzk0uXJAhaVc/edit
>
>
> > However, as I commented on https://github.com/whatwg/dom/pull/892 and
> have
> > previously stated during the last F2F and other avenues, the currently
> > proposed semantics of getInnerHTML is deeply problematic. We want
> > consistent semantics across different kinds of Web API, and what's being
> > proposed is very much different from what we had discussed what we would
> do
> > for selection.
>
> I just replied to the comment you made yesterday on DOM issue #892. I
> looked
> back at the F2F minutes (
> https://www.w3.org/2020/03/23-components-minutes.html)
> to refresh my memory, and it turns out the current API was actually
> suggested
> (by annevk) at that meeting. I don't see any comments from you about the
> API
> shape there, but perhaps I missed it?
>
> In terms of API shape, can you clarify what you feel is deeply problematic
> about it? I assume you're talking about the need to pass in closed shadow
> roots, to enable them to be serialized. I see that your comment there
> suggests
> the requirement to pass in *all* shadow roots, even open ones. But the
> linked
> comment on selection actually refers to just closed shadow roots also. I'm
> unclear why you would want/need to pass in open shadow roots?
>

I replied in the issues directly so that people outside of the WebKit
community can follow the discussion.

> Also, have people figured out how scoped custom element registries can
> > integrate with this feature in the future? Given that's the other most
> > frequently requested feature, it would be very regrettable if we later
> > found out some inconsistencies or awkwardness in their integrations.
>
> Yes, I've talked several times to justinfagnani about Scoped Custom Element
> Registries, and he sees no problem integrating with DSD. We'll likely
> just need to add an attribute that opts the shadow root out of using the
> global registry, but that seems straightforward. Do you have any particular
> concerns?
>

How does one specify a declarative shadow root to use a specific custom
element registry?

- R. Niwa

On Thu, Feb 18, 2021 at 3:16 PM Mason Freed  wrote:
>
>> Hello WebKit,
>>
>> I just wanted to send a final heads-up that Chromium is intending to ship
>> the Declarative Shadow DOM feature. We haven't heard much back from WebKit
>> in the last 5 months or so, but in the meantime there has been some good
>> discussion with Mozilla and the broader community. Several more performance
>> investigations have been performed, around the overhead of Shadow DOM
>> generally, and around the potential polyfill alternatives for DSD. You can
>> see a summary of these, plus all of the other changes that we've
>> incorporated, in this comment on the Mozilla Standards Position thread
>> <https://github.com/mozilla/standards-positions/issues/335#issuecomment-781697858>.
>> These changes are the result of your (and the community's) involvement and
>> feedback, so thanks. At this point, we believe all of the feedback has been
>> addressed.
>>
>> Thanks,
>> Mason
>>
>>
>> On Tue, Aug 11, 2020 at 10:27 AM Mason Freed 
>> wrote:
>>
>>> Yes, thanks! Welcome back!
>>>
>>> On Mon, Aug 10, 2020 at 3:24 PM Ryosuke Niwa  wrote:
>>>
>>>> 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 orig

Re: [webkit-dev] Position on emerging standard: Declarative Shadow DOM

2021-02-18 Thread Ryosuke Niwa via webkit-dev
On Thu, Feb 18, 2021 at 3:17 PM Mason Freed via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> I just wanted to send a final heads-up that Chromium is intending to ship
> the Declarative Shadow DOM feature. We haven't heard much back from WebKit
> in the last 5 months or so, but in the meantime there has been some good
> discussion with Mozilla and the broader community. Several more performance
> investigations have been performed, around the overhead of Shadow DOM
> generally, and around the potential polyfill alternatives for DSD. You can
> see a summary of these, plus all of the other changes that we've
> incorporated, in this comment on the Mozilla Standards Position thread
> .
> These changes are the result of your (and the community's) involvement and
> feedback, so thanks. At this point, we believe all of the feedback has been
> addressed.
>

The latest proposal does solve much of the problems we've identified in the
past, and it's looking to be a promising direction. Do you have any example
website or app that you can share with which resulted in the observed 15%
improvement in FCP? That would be a very intriguing observation and would
substantiate the support for this feature.

However, as I commented on https://github.com/whatwg/dom/pull/892 and have
previously stated during the last F2F and other avenues, the currently
proposed semantics of getInnerHTML is deeply problematic. We want
consistent semantics across different kinds of Web API, and what's being
proposed is very much different from what we had discussed what we would do
for selection.

Also, have people figured out how scoped custom element registries can
integrate with this feature in the future? Given that's the other most
frequently requested feature, it would be very regrettable if we later
found out some inconsistencies or awkwardness in their integrations.

- R. Niwa

On Tue, Aug 11, 2020 at 10:27 AM Mason Freed 
> wrote:
>
>> Yes, thanks! Welcome back!
>>
>> On Mon, Aug 10, 2020 at 3:24 PM
>> - R. Niwa
>>  wrote:
>>
>>> 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
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Identifier Conversion Tooling

2021-02-12 Thread Ryosuke Niwa via webkit-dev
On Fri, Feb 12, 2021 at 2:58 PM Jonathan Bedard via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> Hello contributors,
>
> As we move forward with the transition to GitHub, we are starting to adopt
> identifiers  in tooling
> and infrastructure. This is going to take a few weeks, but you will start
> seeing links based on identifiers more frequently. During this transition
> period, not all tooling will work with identifiers, and it’s possible there
> are tools you rely on that aren’t in common use so will be slow in
> receiving support. To that end, I would like to share the tools available
> to translate between hashes, revisions and identifiers in WebKit, along
> with the Python libraries backing that tooling if you feel motivated to
> expedite the transition for a workflow that is particularly important to
> you.
>
> Tools/Scripts/git-webkit find  is the local script that can convert
> between revisions, hashes and identifiers. By default, it uses your local
> checkout, which means it may be restricted by your checkout’s
> configuration. For example, a pure Subversion checkout will be unable to
> convert hashes and a pure Git checkout will be unable to convert revisions,
> while a Git-Svn checkout will be able to translate all three formats.
>
> If you want to be certain that a hash or revision can be converted to an
> identifier, running Tools/Scripts/git-webkit -C
> https://svn.webkit.org/repository/webkit find  or 
> Tools/Scripts/git-webkit
> -C https://github.com/WebKit/Webkit find  are options. These command
> operate entirely on the network, instead of relying on your local checkout.
>
> Both variations of git-webkit find are ultimately thin wrappers around
> webkitscmpy local.Scm and remote.Scm classes, so if you find yourself
> working with Python code, consider leveraging the APIs directly.
>
> Lastly, along with redirecting to trac/GitHub, the site
> https://commits.webkit.org has a JSON API which vends a representation of
> a commit which includes the hash, revision and identifier and looks like
> this: https://commits.webkit.org/234036@main/json. commits.webkit.org is
> a service we are dedicated to maintaining permanently, since it allows us
> to vend commit links with identifiers instead of hashes.
>

Can we add some simple UI to that site so that it's more human friendly?

- 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: Critical-CH response header, part of Client Hints Reliability proposal

2021-01-28 Thread Ryosuke Niwa via webkit-dev
I'm still confused here. In what scenario would a browser decide to not
send client hints but later decide it's okay to send them?

On Thu, Jan 28, 2021 at 7:13 PM Aaron Tagliaboschi 
wrote:

> The Critical-CH header can trigger a request re-try. It's for situations
> where the browser could be unaware of the site's CH preferences (like the
> first navigation request to a site before the browser has received and
> stored CH preferences) or if a site has changed those references, and the
> site would rather drop the request and retry over getting a potentially
> "incomplete" request
>
> This would *not* override potential mitigations or reductions in
> fingerprinting surfaces imposed by the browser. Any headers that would be
> blocked would still be silently dropped.
>
> (cc davidben, mjs who I forgot to CC the first time)
>
> On Thu, Jan 28, 2021 at 9:35 PM Ryosuke Niwa  wrote:
>
>> What's the point of specifying Critical-CH as opposed to relying on CH
>> provided by the browser?
>>
>> Is the idea that some browsers may decide to hide some client hints to
>> reduce the fingerprinting surface?
>> If so, then this new header seems to just defeat that because a website
>> can specify all the client hints as critical.
>>
>> - R. Niwa
>>
>> On Wed, Jan 27, 2021 at 4:40 AM Aaron Tagliaboschi via webkit-dev <
>> webkit-dev@lists.webkit.org> wrote:
>>
>>> Explainer:
>>> https://github.com/WICG/client-hints-infrastructure/blob/master/reliability.md#critical-ch
>>> Draft Spec:
>>> https://tools.ietf.org/html/draft-davidben-http-client-hint-reliability-02#section-3
>>>
>>> The Client Hint Reliability proposal is a set of features aimed at
>>> making Client Hints
>>> <https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-15> more
>>> reliably available and mitigating
>>> mis-matches between a site's preferences and the preferences stored in
>>> the browser. The idea
>>> behind the Critical-CH response header is to signal to browsers that
>>> there are hints the server
>>> would rather pay a round trip than not have not the first request. The
>>> basic algorithm is as follows:
>>>
>>> If, after receiving a request with Critical-CH and Accept-CH headers,
>>> there is a hint indicated in
>>> the Critical-CH header that the browser did not send but would not block
>>> sending, the browser
>>> should store the new CH preferences, drop the request, and start a new
>>> one with the new
>>> headers included.
>>>
>>> Aaron Tagliaboschi | Software Engineer, Chrome Trust & Safety
>>> ___
>>> 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: Critical-CH response header, part of Client Hints Reliability proposal

2021-01-28 Thread Ryosuke Niwa via webkit-dev
What's the point of specifying Critical-CH as opposed to relying on CH
provided by the browser?

Is the idea that some browsers may decide to hide some client hints to
reduce the fingerprinting surface?
If so, then this new header seems to just defeat that because a website can
specify all the client hints as critical.

- R. Niwa

On Wed, Jan 27, 2021 at 4:40 AM Aaron Tagliaboschi via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> Explainer:
> https://github.com/WICG/client-hints-infrastructure/blob/master/reliability.md#critical-ch
> Draft Spec:
> https://tools.ietf.org/html/draft-davidben-http-client-hint-reliability-02#section-3
>
> The Client Hint Reliability proposal is a set of features aimed at making
> Client Hints
>  more
> reliably available and mitigating
> mis-matches between a site's preferences and the preferences stored in the
> browser. The idea
> behind the Critical-CH response header is to signal to browsers that there
> are hints the server
> would rather pay a round trip than not have not the first request. The
> basic algorithm is as follows:
>
> If, after receiving a request with Critical-CH and Accept-CH headers,
> there is a hint indicated in
> the Critical-CH header that the browser did not send but would not block
> sending, the browser
> should store the new CH preferences, drop the request, and start a new one
> with the new
> headers included.
>
> Aaron Tagliaboschi | Software Engineer, Chrome Trust & Safety
> ___
> 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] Github mirror is not updating

2020-11-30 Thread Ryosuke Niwa via webkit-dev
On Thu, Nov 26, 2020 at 11:33 PM Adrien Destugues via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

>
> I noticed that the github mirror at https://github.com/webkit/webkit is
> not getting
> the latest commits from WebKit (it is now about a month behind). Is that
> intentional?
>

We're actively working on resolving this issue. This current disruption is
caused by GitHub repository preferring to Git repository created off of
accessing the source-of-the-truth subversion repository over HTTPS instead
of accessing it over HTTP. However, since we're in the midst of Git
transition and this transition requires us adding a new numeric
identifier to each commit message, we're doing that work so that we can
push one new Git repository to GitHub instead of temporarily fixing this
issue and then later causing a disruption again. Sorry for the
inconveniences & thanks for your understanding.

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

2020-11-26 Thread Ryosuke Niwa via webkit-dev
On Wed, Nov 25, 2020 at 8:04 AM Nicolás Peña Moreno  wrote:

> Chromium also does tiling for paint, but I'm still not sure about the
> relevance of that. In our implementation, we just observe that the loaded
> element has painted in the renderer process, and then wait for the
> presentation timestamp of the committed frame.
>

The relevance is that just because the tile gets painted, it doesn't mean
the content is also painted. Teasing out the two will involve some
housekeeping which isn't readily available.

At this point, I'm going to stop responding to this thread. However, the
lack of further response does not imply endorsement of this API nor does it
mean previously stated problems have become irrelevant or
adequately addressed. All the previously stated problems continue to exist
with the specification and as such, we do not support this API.

- R. Niwa

On Tue, Nov 24, 2020 at 1:41 PM Ryosuke Niwa  wrote:
>
>>
>> On Tue, Nov 24, 2020 at 8:23 AM Nicolás Peña Moreno 
>> wrote:
>>
>>> Thanks for taking the time to review. I received this on my spam folder
>>> for some reason so apologies for the delay in replying.
>>>
>>> On Tue, Nov 3, 2020 at 3:31 AM Ryosuke Niwa  wrote:
>>>
>>>> On Fri, Oct 30, 2020 at 1:58 PM Nicolás Peña Moreno 
>>>> wrote:
>>>> >
>>>> > Hi, I'd like to request WebKit's position on the Element Timing API,
>>>> which lets web developers annotate images or text whose performance they
>>>> care about. They can then obtain rendering timestamps from the
>>>> PerformanceObserver. For cross-origin images the detailed information is
>>>> gated on Timing-Allow-Origin. The proposed specification is at
>>>> https://wicg.github.io/element-timing/ and is currently shipped in
>>>> Chromium. Thanks!
>>>>
>>>> Apple's WebKit team reviewed this API and we have a few
>>>> concerns including but not limited to:
>>>>
>>>>- The proposed API exposes timing at which a given element is
>>>>painted. Implemented naively, this exposes the implementation detail of
>>>>what kind of compositing tiles are used on a given web page. Hiding this
>>>>implementation detail and recording the exact theoretical paint timing 
>>>> will
>>>>be prohibitively expensive to do on all websites.
>>>>
>>>> Note that this only requires exposing the paint timestamp when the
>>> developer requires it explicitly.
>>>
>>
>> I don't see how that's relevant.
>>
>>
>>> It is also implemented similarly to the 'mark paint timing' algorithm,
>>> which is already implemented in WebKit.
>>>
>>
>> Mark paint timing is easier to implement because the granularity is for
>> the whole document, not per element basis. Because WebKit splits the
>> viewport into multiple tiles, and paint invalidation & painting is done per
>> tile, there isn't an easy way to isolate elements being painted from how
>> tiles are generated.
>>
>>>
>>>>- The definition of the set of owned text nodes and how they
>>>>compute intersectionRect seems inadequate. It's unclear what "border 
>>>> box"
>>>>of *Text* node would mean. The spec doesn't seem to ever populate
>>>>"set of elements with rendered text" either.
>>>>
>>>>
>>> Indeed, the border box issue is tracked on
>>> https://github.com/WICG/element-timing/issues/33 and
>>> https://github.com/w3c/csswg-drafts/issues/4197. The set is populated
>>> on https://wicg.github.io/element-timing/#sec-element-processing.
>>>
>>>
>>>>
>>>>- The use of this API seems to incur a significant runtime as well
>>>>as memory cost.
>>>>
>>>> The computations and memory should be limited to the annotated
>>> elements, thus not impacting developers that do not use the API. I'll send
>>> a PR to make that better in the spec, and additional suggestions on
>>> mitigation are welcome.
>>>
>>
>> That is still a major concern since painting time is one of the most
>> costly operations that happens during page loads still.
>>
>> - 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 Element Timing

2020-11-24 Thread Ryosuke Niwa via webkit-dev
On Tue, Nov 24, 2020 at 8:23 AM Nicolás Peña Moreno  wrote:

> Thanks for taking the time to review. I received this on my spam folder
> for some reason so apologies for the delay in replying.
>
> On Tue, Nov 3, 2020 at 3:31 AM Ryosuke Niwa  wrote:
>
>> On Fri, Oct 30, 2020 at 1:58 PM Nicolás Peña Moreno 
>> wrote:
>> >
>> > Hi, I'd like to request WebKit's position on the Element Timing API,
>> which lets web developers annotate images or text whose performance they
>> care about. They can then obtain rendering timestamps from the
>> PerformanceObserver. For cross-origin images the detailed information is
>> gated on Timing-Allow-Origin. The proposed specification is at
>> https://wicg.github.io/element-timing/ and is currently shipped in
>> Chromium. Thanks!
>>
>> Apple's WebKit team reviewed this API and we have a few
>> concerns including but not limited to:
>>
>>- The proposed API exposes timing at which a given element is
>>painted. Implemented naively, this exposes the implementation detail of
>>what kind of compositing tiles are used on a given web page. Hiding this
>>implementation detail and recording the exact theoretical paint timing 
>> will
>>be prohibitively expensive to do on all websites.
>>
>> Note that this only requires exposing the paint timestamp when the
> developer requires it explicitly.
>

I don't see how that's relevant.


> It is also implemented similarly to the 'mark paint timing' algorithm,
> which is already implemented in WebKit.
>

Mark paint timing is easier to implement because the granularity is for the
whole document, not per element basis. Because WebKit splits the viewport
into multiple tiles, and paint invalidation & painting is done per tile,
there isn't an easy way to isolate elements being painted from how tiles
are generated.

>
>>- The definition of the set of owned text nodes and how they compute
>>intersectionRect seems inadequate. It's unclear what "border box" of
>>*Text* node would mean. The spec doesn't seem to ever populate "set
>>of elements with rendered text" either.
>>
>>
> Indeed, the border box issue is tracked on
> https://github.com/WICG/element-timing/issues/33 and
> https://github.com/w3c/csswg-drafts/issues/4197. The set is populated on
> https://wicg.github.io/element-timing/#sec-element-processing.
>
>
>>
>>- The use of this API seems to incur a significant runtime as well as
>>memory cost.
>>
>> The computations and memory should be limited to the annotated elements,
> thus not impacting developers that do not use the API. I'll send a PR to
> make that better in the spec, and additional suggestions on mitigation are
> welcome.
>

That is still a major concern since painting time is one of the most costly
operations that happens during page loads still.

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

2020-11-11 Thread Ryosuke Niwa
On Fri, Oct 30, 2020 at 1:58 PM Nicolás Peña Moreno  wrote:
>
> Hi, I'd like to request WebKit's position on the Element Timing API,
which lets web developers annotate images or text whose performance they
care about. They can then obtain rendering timestamps from the
PerformanceObserver. For cross-origin images the detailed information is
gated on Timing-Allow-Origin. The proposed specification is at
https://wicg.github.io/element-timing/ and is currently shipped in
Chromium. Thanks!

Apple's WebKit team reviewed this API and we have a few concerns including
but not limited to:

   - The proposed API exposes timing at which a given element is painted.
   Implemented naively, this exposes the implementation detail of what kind of
   compositing tiles are used on a given web page. Hiding this
   implementation detail and recording the exact theoretical paint timing will
   be prohibitively expensive to do on all websites.
   - The definition of the set of owned text nodes and how they compute
   intersectionRect seems inadequate. It's unclear what "border box" of
   *Text* node would mean. The spec doesn't seem to ever populate "set of
   elements with rendered text" either.
   - The use of this API seems to incur a significant runtime as well as
   memory cost.

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


Re: [webkit-dev] Embedding Identifiers in Commit Messages

2020-11-02 Thread Ryosuke Niwa
On Mon, Nov 2, 2020 at 2:04 PM Jonathan Bedard  wrote:
>
> We appreciate everyone’s feedback on transitioning away from Subversion to 
> Git, I’ll be releasing an expected timeline of up-coming changes in the next 
> week before the contributors meeting.
>
> In the mean time, we’re preparing on adding identifiers to new commit 
> messages, that work is tracked in 
> https://bugs.webkit.org/show_bug.cgi?id=218407. At the moment, we’re likely 
> going to be appending the identifiers to commit messages (as the current 
> change proposes), but I wanted to provide a chance for folks to object to 
> this change before it becomes canonical.

I'm a bit confused here. It looks like the patch only affects commits
made via webkit-patch. Given there are a lot of people who don't use
webkit-patch land, I'm not certain this strategy is sound even in the
short term. Furthermore, the proposed patch seems to have a race
condition when multiple commits are made concurrency? Why don't we do
this in post commit hook instead?

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


Re: [webkit-dev] Request for a position on the Idle Detection API

2020-10-29 Thread Ryosuke Niwa
On Thu, Oct 29, 2020 at 12:54 PM Reilly Grant  wrote:
>
> On Wed, Oct 28, 2020 at 9:20 PM Ryosuke Niwa  wrote:
> >
> > On Wed, Oct 28, 2020 at 4:56 PM Reilly Grant  wrote:
> >>
> >> I would like to request an official position from the WebKit team on the 
> >> emerging Idle Detection API specification. I am aware that this API was 
> >> included in a list of APIs which you have decided not to implement due to 
> >> fingerprinting concerns. I assume that this objection was based on the 
> >> original explainer provided for this API.
> >
> > Our position has not changed. Our concerns are not limited to 
> > fingerprinting. There is an obvious privacy concern that this API lets a 
> > website observe whether a person is near the device or not. This could be 
> > used, for example, to start mining bitcoins when the user is not around or 
> > start deploying security exploits, etc...
>
> Thank you for expanding on your concerns. I agree that malicious sites
> may attempt to hide their activity from the user by waiting until they
> appear to not be paying attention. There are plenty of mechanisms
> currently available for this, for example, a site can already tell
> that it has been placed in the background and can observe that the
> user has not interacted with it in a long time, which likely means
> that the user is no longer at their computer.

If that were the case, then it seems like we don't need this API in
the first place.

> It is true that this
> capability would allow a site to be more precise about targeting a
> time when the user is not present. I think the mitigation in that
> case, especially for activity such as cryptocurrency mining, is the
> work that is being done elsewhere to define the semantics for
> throttling the work that sites are allowed to do in the background.

Throttling isn't enough to mitigate all security attacks. Some attacks
might be more of visual cue like going to full screen, etc...

> >> Since that list was posted the API has been extended to include a 
> >> permission that sites must acquire before being granted access to user 
> >> presence signals. I would like to start a conversation to understand the 
> >> fingerprinting risks you foresee from this API.
> >
> > This kind of action-at-a-distance permission prompt is problematic because 
> > it's unclear to the user why such a permission should be granted and for 
> > what purpose.
>
> It is the site's job to present a compelling case for why the user
> should grant it a permission.

That doesn't make any sense. We can't let the user make a judgement on
whether something is a good idea or not based on a text which is
supplied by malicious content.

> > Additionally, the use cases listed at 
> > https://github.com/WICG/idle-detection/blob/master/README.md are rather 
> > weak.
> >
> >> Chat application: presenting a user's status to other users and delivering 
> >> notifications to the device where the user is active.
> >
> > Why does delivering a notification to all devices considered bad? That's 
> > what happens to most notifications I receive and modern operating systems 
> > have ways to hide & dismiss old notifications anyway. It's also unclear how 
> > users are supposed to know of this use case when assessing whether to allow 
> > a permission for this API or not.
>
> Developers we have talked to (see the WICG discourse thread for
> supportive comments from Slack and Google Chat) have identified that
> receiving notifications on all their devices simultaneously is in fact
> a frequent user complaint. In the introduction section of the
> specification I explain the user scenario in more detail. Being able
> to hide or dismiss old notifications is helpful but does not address
> the core issue, which is that user's want to receive notifications on
> only the device they are currently using. The current tools for this
> are lacking because they cannot distinguish between the user leaving
> their computer and simply switching to another application.

That doesn't seem like a strong enough use case for this API. For
starters, there is no guarantee that the user won't immediately come
back to the device. Also, who is such a service supposed to know what
other device user might be using at any given point? We're definitely
not going to let a website know all the devices a given user might be
using at any given point. That's a very serious breach of the said
user's privacy. It seems to me that such a suppression / distribution
mechanism is best left for the underlying operating systems / web
browsers to handle.

I'm going to stop responding to this thread at this point because none
of the 

Re: [webkit-dev] Request for a position on the Idle Detection API

2020-10-28 Thread Ryosuke Niwa
On Wed, Oct 28, 2020 at 4:56 PM Reilly Grant  wrote:

> I would like to request an official position from the WebKit team on the
> emerging Idle Detection API  
> specification.
> I am aware that this API was included in a list of APIs
>  which you have decided not to
> implement due to fingerprinting concerns. I assume that this objection was
> based on the original explainer provided for this API.
>

Our position has not changed. Our concerns are not limited to
fingerprinting. There is an obvious privacy concern that this API lets a
website observe whether a person is near the device or not. This could be
used, for example, to start mining bitcoins when the user is not around or
start deploying security exploits, etc...


> Since that list was posted the API has been extended to include a
> permission that sites must acquire before being granted access to user
> presence signals. I would like to start a conversation to understand the
> fingerprinting risks you foresee from this API.
>

This kind of action-at-a-distance permission prompt is problematic because
it's unclear to the user why such a permission should be granted and for
what purpose.

Additionally, the use cases listed at
https://github.com/WICG/idle-detection/blob/master/README.md are rather
weak.

Chat application: presenting a user's status to other users and delivering
> notifications to the device where the user is active.


Why does delivering a notification to all devices considered bad? That's
what happens to most notifications I receive and modern operating systems
have ways to hide & dismiss old notifications anyway. It's also unclear how
users are supposed to know of this use case when assessing whether to allow
a permission for this API or not.

Showing timely notifications - e.g. deferring displaying feedback until the
> user returns to an active state.


Again, it's unclear why this is desirable. If I'm not at a computer, it's
okay for the notification to still arrive. I'd see it when I come back to
my computer.

Updating an outdated service worker when there's no unsaved state by
> triggering reloading of the tab.


This doesn't seem like something you'd need idle detection API to do. It's
sufficient to realize that you haven't recently received user inputs on
your website. I have plenty of tabs & windows that I don't touch for hours
if not days. Any websites loaded in such browsing contexts should consider
doing that kind of updates / synchronization. If the argument is that the
user may go back to such tabs / windows if they're currently present, then
this user idle detection API won't help either because the user may come
back to it at any moment.

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

2020-10-27 Thread Ryosuke Niwa
On Tue, Oct 27, 2020 at 2:23 PM Domenic Denicola  wrote:
>
> For the last couple of years myself some other Chrome folks have been working 
> on the import maps proposal. This allows controlling the behavior of 
> JavaScript import statements and import() expressions, in particular by 
> allowing the page to customize the translation of the module specifiers used 
> there into URLs. Developer reception of the feature has been very positive, 
> with continual prompting for when it'll be widely available in more browsers, 
> and a plethora of community-created tools and polyfills.
>
> Chrome is working toward shipping this in an imminent release, and we'd love 
> any thoughts or contributions from the WebKit community.

How does this feature supposed to work with CSP subresource integrity?
As far as I've read various specs and the proposal, it's not currently
possible to specify any integrity checks on modules loaded via import
this. This is a pretty serious downside because it would mean that any
remote server ever referenced by an import map becomes a security
liability for a given website. It's a lot worse compared to normal
scripts because of the action-at-a-distance of import maps. There is
no indication that a given module import could involve access to
cross-origin servers isn't obvious from where the import statement
appears.

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

2020-10-22 Thread Ryosuke Niwa
No. Our concerns have not been addressed.
We're continued to be concerned with the proliferation of these X timing APIs.

We would like to have a holistic study of these APIs and how they fit
together before we'll be comfortable implementing them.

- R. Niwa

On Thu, Oct 22, 2020 at 12:28 AM Rob Buis  wrote:
>
> Hi Ryosuke, Simon,
>
> Have the raised concerns been addressed now, given the document shared by 
> Nicolás and github issue discussions? I would like to avoid bitrot for my 
> prototype :)
>
> Regards,
>
> Rob.
>
> Am 30.09.20 um 00:10 schrieb Nicolás Peña Moreno:
>
> I've written a doc to explain our perspective on the use-cases of these two 
> APIs: 
> https://docs.google.com/document/d/1UrPQD0lOhHKgQy1oy1Cs0F9AsBb83q_bx8cAvu_sKrI.
>
>
> On Tue, Sep 29, 2020 at 5:16 PM Yoav Weiss  wrote:
>>
>> +Nicolás Peña
>>
>> On Sun, Aug 9, 2020 at 5:40 AM Ryosuke Niwa  wrote:
>>>
>>> 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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Shrinking Git clone size (WebKit Transition to Git)

2020-10-18 Thread Ryosuke Niwa
Hi all,

While we're making the transition to Git, I think we should try to
shrink the Git clone size. Right now, it's 10GB and I suspect we can
cut it down quite a bit without sacrificing much. For example, we can
exclude any history for LayoutTests/platform/chromium* and
LayoutTests/platforn/*qt*. I bet that would reduce the clone size
considerably.

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


Re: [webkit-dev] Reducing / removing use of Makefile based DerivedSources.make

2020-10-18 Thread Ryosuke Niwa
On Sat, Oct 17, 2020 at 10:00 AM Sam Weinig  wrote:
>
> Hi webkit-dev,
>
> I’d like to propose, and gauge feedback on, reducing (with the goal of 
> ultimately removing) the use of Makefile based DerivedSources.make.
>
> My understanding is that currently only the Xcode based ports still use 
> DerivedSources.make, as all the CMake based ones have moved derived source 
> generation to within CMake, so that should limit the scope of who this might 
> affect.
>
>
> Why do we use Makefiles today?
>
> While I can’t recall the initial reasons for using Makefiles for derived 
> sources, over the years there have been a number of advantages to it that I 
> do know of. One clear advantage, that is no longer applicable, was code 
> sharing, as earlier in the project, at least the Apple Windows port did 
> utilize these Makefiles. Another was to work around some limitations in what 
> dependencies Xcode was able to track with build rules. It seems at least some 
> of the problems with build rules are no longer an issue, as we can now 
> specify inputs to build rules, but I don’t if other problems will still be 
> there, but for some prototyping I did, nothing yet has come up.
>
>
> What would we move to?
>
> As this only affects the Xcode based ports, we would move to distinct script 
> phases and build rules in the Xcode project.
>
>
> Why make this change? What’s the benefit?
>
> There are few reasons to consider this. One advantage is simplifying the 
> build system. Rather than two dependency systems (one for Xcode, one for the 
> Makefile) we reduce it down to one. And with additional knowledge of the 
> stages and dependencies, Xcode could potentially parallelize more phases. We 
> would would also save some time by avoiding invoking make in the first place.
>
> We also have a bit of an issue with make itself, as due to system 
> requirements, we are forever stuck with Make 3.81, which is coming up on 
> being 15 years old. More than once in the last year I have tried to 
> troubleshoot makefile issues, looking for resources on the web, only to be 
> stymied because the solutions I found required newer make.
>
>
> What are the downsides?
>
> One potential downside will be that it will be a bit harder for those without 
> Xcode to add new types of derived sources. I am not sure how much a real 
> problem in practice this will be, as editing project.pbxproj files is already 
> required for just adding new files, but I want to call it out anyway.

Do we need to dig up some kind of bespoke Xcode UI to add a new IDL
file after this? I always find all those build phase things in Xcode
to be impossible to edit.

> What are your thoughts on this? Are there additional reasons we might want to 
> stick with or move away from Makefile based derived sources?

Is there some way we can use something like Sources.txt to list the
files from which derived sources are created? DerivedSources.make is
annoying to edit but the equivalent CMake file is equally annoying to
edit. If we had a simple list of files like we do for unified sources,
it would make an average WebKit contributor's life way easier.

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


Re: [webkit-dev] WebKit Transition to Git

2020-10-13 Thread Ryosuke Niwa
On Tue, Oct 13, 2020 at 4:12 PM Konstantin Tokarev  wrote:
>
>
>
> 14.10.2020, 02:01, "Ryosuke Niwa" :
> > On Tue, Oct 13, 2020 at 3:53 PM Konstantin Tokarev  
> > wrote:
> >>  14.10.2020, 01:45, "Ryosuke Niwa" :
> >>  > On Tue, Oct 13, 2020 at 3:40 PM Konstantin Tokarev  
> >> wrote:
> >>  >> 14.10.2020, 01:30, "Ryosuke Niwa" :
> >>  >> > On Tue, Oct 13, 2020 at 2:37 PM Konstantin Tokarev 
> >>  wrote:
> >>  >> >> 13.10.2020, 22:33, "Maciej Stachowiak" :
> >>  >> >> >> On Oct 2, 2020, at 10:59 AM, Michael Catanzaro 
> >>  wrote:
> >>  >> >> >>
> >>  >> >> >> On Fri, Oct 2, 2020 at 6:36 pm, Philippe Normand 
> >>  wrote:
> >>  >> >> >>> Would you also consider preventing merge commits in order to 
> >> keep a
> >>  >> >> >>> clean mainline branch?
> >>  >> >> >>
> >>  >> >> >> Big +1 to blocking merge commits. Merge commits in a huge 
> >> project like WebKit would make commit archaeology very frustrating. (I 
> >> assume this is implied by the monotonic commit identifiers proposal, but 
> >> it doesn't exactly say that.)
> >>  >> >> >
> >>  >> >> > I’m assuming your objection is to regular merges, but how do you 
> >> feel about squash merges? Or do you think all PRs should be landed by 
> >> rebasing?
> >>  >> >>
> >>  >> >> I'm not Michael but will add my 2 dollars anyway :)
> >>  >> >>
> >>  >> >> In these two approaches commits inside PR have different meaning, 
> >> and workflow is different.
> >>  >> >>
> >>  >> >> Below I use a term "atomic change" to describe minimal code change 
> >> which is a self-contained work unit with following properties:
> >>  >> >> * It implements well-defined task which can be summarized as a 
> >> short English sentence (typical soft limit is 60 characters)
> >>  >> >> * It doesn't introduce defects (e.g. bugs, compilation breakages, 
> >> style errors, typos) which were discovered during review process
> >>  >> >> * It doesn't include any code changes unrelated to main topic. This 
> >> separation is sometimes subjective, but it's usually recommended to split 
> >> refactoring and implementation of feature based on that, bug fix and new 
> >> feature, big style change and fix or feature.
> >>  >> >>
> >>  >> >> AFAIU our current review process has similar requirements to 
> >> patches submitted to Bugzilla, though sometimes patches include unrelated 
> >> changes. This can be justified by weakness of webkit-patch/Bugzilla 
> >> tooling which has no support for patch series, and by fact that SVN 
> >> doesn't support keeping local patch series at all.
> >>  >> >>
> >>  >> >> 1. Workflow 1 - "Squash merge" policy
> >>  >> >>
> >>  >> >> * Whole PR is considered to be a single atomic change of WebKit 
> >> source tree. If work is supposed to be landed as a series of changes which 
> >> depend on each other (e.g. refactoring and feature based on it, or 
> >> individual separate features touching same parts of code), each change 
> >> needs a separate PR, and, as a consequence, only one of them can be 
> >> efficiently reviewed at the moment of time
> >>  >> >> * Commits in PR represent review iterations or intermediate 
> >> implementation progress
> >>  >> >> * Reviewers' comments are addressed by pushing new commits without 
> >> rewriting history, which works around GitHub's lack of "commit revisions". 
> >> Also this workflow has lower entry barrier for people who haven't mastered 
> >> git yet, as it requires only "git commit" and "git push" without rebases.
> >>  >> >>
> >>  >> >> 2. Workflow 2 - "Rebase" ("cherry-pick")) or "Merge" policy
> >>  >> >>
> >>  >> >> * PR is considered to be a series of atomic changes. If work 
> >> consists of several atomic changes, each commit represent an atomic change
> >>  >> >> * Review iterations are done by fixing commits in place and 
> >

Re: [webkit-dev] WebKit Transition to Git

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

Re: [webkit-dev] WebKit Transition to Git

2020-10-13 Thread Ryosuke Niwa
On Tue, Oct 13, 2020 at 3:19 PM Michael Catanzaro  wrote:
>
> Detailed descriptions are very important. I don't think function-level
> changelogs are; documenting changes in individual functions is
> generally busywork to say what you can plainly see by just looking at
> the diff.

They certainly can be quite informative. e.g.
https://trac.webkit.org/changeset/268365/webkit/trunk/Source/WebCore/ChangeLog

It's true that you can certainly split each logical step into its own
commit but that seems like more of a busy work to me. I mostly use a
Subversion checkout to do my work, and even if I'm using a Git clone,
I normally wouldn't commit anything until the whole patch is written.
e.g. I wrote the entirety of https://trac.webkit.org/r268239 and
posted in one chunk other than a few WIP patches I had posted. Having
to go back & split that into multiple commits would be a total waste
of time.

> Regarding line-by-line commit review... well, it would be nice to have,
> of course.  But I don't think it's as important as you suggest.
> Problems with commit messages are usually general problems with the
> entire commit message rather than problems with a specific line of the
> commit message.

I disagree. I often have specific commentary on specific lines of
change logs like missing function-level comments or typos, or need
some elaboration on specific details.

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


Re: [webkit-dev] WebKit Transition to Git

2020-10-13 Thread Ryosuke Niwa
On Tue, Oct 13, 2020 at 3:40 PM Konstantin Tokarev  wrote:
>
> 14.10.2020, 01:30, "Ryosuke Niwa" :
> > On Tue, Oct 13, 2020 at 2:37 PM Konstantin Tokarev  
> > wrote:
> >>  13.10.2020, 22:33, "Maciej Stachowiak" :
> >>  >> On Oct 2, 2020, at 10:59 AM, Michael Catanzaro  
> >> wrote:
> >>  >>
> >>  >> On Fri, Oct 2, 2020 at 6:36 pm, Philippe Normand  
> >> wrote:
> >>  >>> Would you also consider preventing merge commits in order to keep a
> >>  >>> clean mainline branch?
> >>  >>
> >>  >> Big +1 to blocking merge commits. Merge commits in a huge project like 
> >> WebKit would make commit archaeology very frustrating. (I assume this is 
> >> implied by the monotonic commit identifiers proposal, but it doesn't 
> >> exactly say that.)
> >>  >
> >>  > I’m assuming your objection is to regular merges, but how do you feel 
> >> about squash merges? Or do you think all PRs should be landed by rebasing?
> >>
> >>  I'm not Michael but will add my 2 dollars anyway :)
> >>
> >>  In these two approaches commits inside PR have different meaning, and 
> >> workflow is different.
> >>
> >>  Below I use a term "atomic change" to describe minimal code change which 
> >> is a self-contained work unit with following properties:
> >>  * It implements well-defined task which can be summarized as a short 
> >> English sentence (typical soft limit is 60 characters)
> >>  * It doesn't introduce defects (e.g. bugs, compilation breakages, style 
> >> errors, typos) which were discovered during review process
> >>  * It doesn't include any code changes unrelated to main topic. This 
> >> separation is sometimes subjective, but it's usually recommended to split 
> >> refactoring and implementation of feature based on that, bug fix and new 
> >> feature, big style change and fix or feature.
> >>
> >>  AFAIU our current review process has similar requirements to patches 
> >> submitted to Bugzilla, though sometimes patches include unrelated changes. 
> >> This can be justified by weakness of webkit-patch/Bugzilla tooling which 
> >> has no support for patch series, and by fact that SVN doesn't support 
> >> keeping local patch series at all.
> >>
> >>  1. Workflow 1 - "Squash merge" policy
> >>
> >>  * Whole PR is considered to be a single atomic change of WebKit source 
> >> tree. If work is supposed to be landed as a series of changes which depend 
> >> on each other (e.g. refactoring and feature based on it, or individual 
> >> separate features touching same parts of code), each change needs a 
> >> separate PR, and, as a consequence, only one of them can be efficiently 
> >> reviewed at the moment of time
> >>  * Commits in PR represent review iterations or intermediate 
> >> implementation progress
> >>  * Reviewers' comments are addressed by pushing new commits without 
> >> rewriting history, which works around GitHub's lack of "commit revisions". 
> >> Also this workflow has lower entry barrier for people who haven't mastered 
> >> git yet, as it requires only "git commit" and "git push" without rebases.
> >>
> >>  2. Workflow 2 - "Rebase" ("cherry-pick")) or "Merge" policy
> >>
> >>  * PR is considered to be a series of atomic changes. If work consists of 
> >> several atomic changes, each commit represent an atomic change
> >>  * Review iterations are done by fixing commits in place and reuploading 
> >> entire series using force push (of course if review discovers that 
> >> substantial part of work is missing it can be added as a new atomic commit 
> >> to the series)
> >>  * It's possible to review each commit in the series separately
> >>  * Workflow requires developers to have more discipline and experience 
> >> with using git rebase for history rewriting. Entry barrier can be lowered 
> >> by providing step by step instructions like e.g. [1].
> >
> > I really dislike this workflow due to its inherent complexity. Having
> > to use Git is enough of a burden already. I don't want to deal with an
> > extra layer of complexity to deal with.
>
> There is simplified version of workflow 2 when you have only one commit in 
> PR. In this case you can easily edit this single commit with gic commit 
> --amend or GUI tools to address review comments. At the same time those who 
> are more comfortable with git can use longer patch series.

Except that reviewers would still have to review each commit
separately, and the time comes to revert someone's patch, we still
need to remember how to revert a sequence of commits that belong to a
single PR.

I don't feel comfortable accepting this level of new complexity into
our contribution process in addition to being forced to use Git &
GitHub.

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


Re: [webkit-dev] WebKit Transition to Git

2020-10-13 Thread Ryosuke Niwa
On Tue, Oct 13, 2020 at 3:19 PM Michael Catanzaro  wrote:
>
> I suppose what I'm describing is Konstantin's Workflow 2, which is
> overwhelmingly popular.
>
> On Tue, Oct 13, 2020 at 2:19 pm, Ryosuke Niwa  wrote:
> > Not squashing only helps if each commit can stand on its own. At that
> > point, I'd suggest such a sequence of commits be made into multiple
> > PRs instead of multiple commits in a single PR, each of which requires
> > a separate code review.
>
> Commits are certainly expected to stand on their own (not introduce
> defects). If they can't, then they should be combined into another
> commit! Hence, we should not approve MRs if the MR contains commits
> that fail to meet our usual standards. Such commits should just fail
> code review. (But if you aren't willing to review MRs commit-by-commit,
> then indeed you'll never notice when such problems exist.)

Right, so this will be a problem unless we're gonna review each commit
separately. But if we're doing that, we might as well as create a
separate PR for each commit.

If we have 5-10 separate commits each of which make substantial
changes, we don't all of them to be landed / merged all at once into
the main branch even if they're logically related. Without
intermediate test runs & perf test results, we wouldn't be able to
pin-point what caused it, in which case, we'd be likely forced to
revert all of them anyway.

Furthermore, reverting a part of a sequence of commits coming from a
single PR would be very confusing just reverting just one of many
patches posted on Bugzilla would be confusing.

For all these reasons, I don't see much benefit in allowing multiple
commits from being merged from PR.

> If I have to open a separate MR for each change, though, I'm going to
> wind up combining multiple lightly-related changes into one big commit,
> because a new MR for every tiny cleanup I want to make requires effort.
> Such commits may be common in WebKit, but they would fail code review
> in most other open source projects. E.g. in
> https://trac.webkit.org/changeset/268394/webkit I snuck in a drive-by
> one-line fix that's unrelated to the rest of the commit. I would rarely
> dare to do that outside WebKit, knowing it would probably fail review,
> but we do it commonly in WebKit because we discourage multiple patches
> per bug and don't want to create new bugs for every small cleanup.

That seems totally okay. I land one line fix like that all the time though.

> > This to me is a show stopper. When I'm trying to bisect an issue,
> > etc..., the biggest obstacle I face is any intermediate revisions
> > where builds are broken or otherwise non-functional. I don't think we
> > should let anyone merge a commit into the main branch unless the
> > commit meets the same standards as a regular Bugzilla patch we land
> > today.
>
> I agree. But I would say that a MR with such history should fail
> review, and be rewritten to not suffer from these problems.

The problem is that you're presuming that all WebKit reviewers would
be able to and would be willing to do that review. I certainly do not
feel comfortable having to do that given how troublesome it has been
in WPT land.

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


Re: [webkit-dev] WebKit Transition to Git

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

I really dislike this workflow due to its inherent complexity. Having
to use Git is enough of a burden already. I don't want to deal with an
extra layer of complexity to deal with.

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


Re: [webkit-dev] WebKit Transition to Git

2020-10-13 Thread Ryosuke Niwa
On Tue, Oct 13, 2020 at 1:57 PM Michael Catanzaro  wrote:
>
> On Tue, Oct 13, 2020 at 12:32 pm, Maciej Stachowiak 
> wrote:
> > I’m assuming your objection is to regular merges, but how do you
> > feel about squash merges? Or do you think all PRs should be landed by
> > rebasing?
>
> If we want a linear history (we do), all PRs ultimately have to land as
> fast-forward merges, one way or the other. I think rebasing is the
> simplest way to accomplish that, but squashes work too if all your
> changes are sufficiently self-contained to land as one commit.
>
> I suggest leaving this up to the discretion of the developer and
> reviewer rather than mandating one way or the other, because there are
> advantages and disadvantages to both approaches. If your local commit
> history is a mess, sometimes squashing it all into one commit is an
> easy way to make it acceptable for upstream. If you hate rewriting
> history to make it look good, and your MR isn't too huge, a squash
> might be appropriate. But more often than not, I'd say that would
> result in a worse commit history.

FWIW, I think we should always squash all commits and have a single
change log entry / commit message for all changes.

In the case we want to rebase and keep multiple commits, then we
should have a change log / descriptive commit message that follows the
current change log format for each commit, rather than a short
description of each change.

> > My own preference would be to require squash merge, because it keeps
> > the history simple for the main branch, but does not risk putting
> > intermediate revisions which may work or even build on the main
> > branch.
>
> The disadvantage is that if you squash before merging, you encourage
> fewer, bigger commits that might be harder to read and potentially much
> less fun to discover at the end of a bisect.

Not squashing only helps if each commit can stand on its own. At that
point, I'd suggest such a sequence of commits be made into multiple
PRs instead of multiple commits in a single PR, each of which requires
a separate code review.

> On the other hand, if you don't squash, it's indeed possible that your
> commit history might be messy, e.g. intermediate commits might break
> tests fixed by subsequent commits, or intermediate commits might not
> build at all.

This to me is a show stopper. When I'm trying to bisect an issue,
etc..., the biggest obstacle I face is any intermediate revisions
where builds are broken or otherwise non-functional. I don't think we
should let anyone merge a commit into the main branch unless the
commit meets the same standards as a regular Bugzilla patch we land
today.

> Sometimes I see the
> opposite, where too many changes are bundled into one big commit. (This
> is more common in WebKit, since we normally try to have one patch per
> bug, and splitting changes into multiple bugs is inconvenient.) But
> usually the developer submitting a MR has found a good balance between
> the two extremes. Ultimately, what's most important is landing a clean
> commit history with reviewable commits. Again, the scope of commits is
> subject to review just like code changes are.

I often review test changes in WPT or spec changes in WHATWG / W3C,
and I often find a PR with multiple commits to be annoying to review.
I'd rather have each PR have a single large commit to review. In
practice, I'd never review commit by commit because I need to see the
whole picture to review what's happening.

> Instead, I suggest
> developers should aggressively use 'git add -p' and 'git rebase -i' to
> selectively commit, rewrite, and reorder history to look good before
> opening the MR. This isn't optional for most open source projects: if
> you propose an MR with ugly commit history, it won't be merged until
> fixed. For a typical MR of moderate complexity, I'll use 'git rebase
> -i' at least a couple times before the history is clean enough for a
> MR, and to make fixup commits disappear into the most-appropriate
> commit in the sequence.

I'm afraid that this will still result in random intermediary commits
being merged into the main branch because there is no mechanical
enforcement.

> Regarding commit messages, I don't understand why there's any
> expectation that they need to be checked into files in order to be
> detailed and complete. If a commit message doesn't adequately describe
> what it's fixing, then the reviewer should open a review thread to
> complain and request more detailed commit messages.

The problem is that I've seen multiple projects which moved to Git and
did this, and their commit log message's quality materially degraded.
If GitHub and other tools allowed inline comments being added for each
line of the commit message, I have less of concern. Github doesn't.

> If a change is very
> straightforward and obvious, sometimes a quick sentence might suffice,
> but usually a good commit message should be at least a paragraph or
> two, and often more. Function-level 

Re: [webkit-dev] WebKit Transition to Git

2020-10-06 Thread Ryosuke Niwa
On Mon, Oct 5, 2020 at 5:13 PM Konstantin Tokarev  wrote:
>
>
> 05.10.2020, 23:41, "Yusuke Suzuki" :
> > I think security component is special in terms of how to handle it already 
> > (e.g. not posting a test with the patch etc.)
> > To me, handling non-security issues in GitHub and security issues in 
> > Bugzilla is OK.
> > By nature, security issues are not open. Since one of our motivation of 
> > moving to GitHub is openness for feedback collection, security issue in 
> > Bugzilla does not matter for this motivation.
> > Ideally, handling both in GitHub is better. But to me, rather than 
> > continuing using Bugzilla, using GitHub for non security issues sounds 
> > improvement.
>
> To me it sounds as a huge step backwards. Asides from situation with security 
> issues, it has other significant drawbacks in domain of issue triaging and 
> management:
>
> 1. Sub-par support for linking issues to each other
> 
>
> Traditional bug tracking systems (like Bugzilla or JIRA) have support of 
> "related" or "linked" issues. Most important relations are
>
> * A depends on B (B blocks A) - blockers and umbrella issues
> * B is duplicate of A
> * A and B are related in other unspecified way
>
> All GitHub can offer here now is mentions (and, to some extent, milestones 
> for case of "umbrella issues" [1]). Mention is created every time someone 
> uses "#" (e.g. "#123") in the text of issue or in the comment, where 
> number is a sequential number of issue or pull request [2]. When comment is 
> published in issue A which mentions issue B, there is a pseudo-comment added 
> to B, and subscribers of B receive email notification.
>
> At first glance this naive approach seems to work, but
>
> * There is no easily visible list of relations: if you are not closely 
> following all activity on A, to find all issues related to it you have to 
> browse through all its (pseudo-)comments, which in some cases might be long.
> * There is no *stateful* list of relations: if A was believed to have common 
> source with B, but then it was discovered they are not related, you cannot 
> delete relationship between A and B because there is no relationship, just a 
> set of comments.
> * "#" is not a safe reference format. Sometimes users' comments may 
> have other data in "#" format with a different meaning than 
> references to GitHub issues. For example, may the force be with you if 
> someone pastes gdb or lldb backtrace into comment without escaping it into 
> markdown raw text block (```). Also, GitHub parses mentions in git commit 
> messages, so care must be taken to avoid any occurrences of "#" with 
> a meaning different from reference to issue number.

Yeah, this is a pretty significant functional regression to me. I use
bug dependencies all the time (e.g.
https://bugs.webkit.org/showdependencytree.cgi?id=148695_resolved=1)
and not having this capability will significantly hinder my ability to
track & triage some bugs.

> 3. Sub-par attachments
> --
>
> Traditional bug trackers allow attaching files to issue. GitHub goes further 
> and allows to attach files to every comment. Enjoy the progress -  now you 
> can look for attached test cases and proposed patches through all comment 
> feed, instead of having them in one place at the top.
>
> Also, on test cases. You probably like this feature of Bugzilla when you can 
> attach self-contained HTML file to the issue and then simply open it by URL 
> in any browser including your build of WebKit to try it out. Forget this - 
> GitHub simply forbids HTML or JS attachments (without wrapping them in 
> archive):
>
> "We don’t support that file type. with a GIF, JPEG, JPG, PNG, DOCX, GZ, 
> LOG, PDF, PPTX, TXT, XLSX or ZIP."
>
> And yes, take care not to use tar.xz or tar.bz2 or any other unapproved 
> archive type.
>
> But you can attach funny cat picture to your comment and it will be displayed 
> inline :)

This is another massive functional regression. I open test cases on
Bugzilla without downloading all the time, not to mention that it's a
great way to test iOS devices as well. Not being able to do that would
significantly reduce my productivity.

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


Re: [webkit-dev] WebKit Transition to Git

2020-10-04 Thread Ryosuke Niwa
On Sun, Oct 4, 2020 at 2:41 PM Konstantin Tokarev  wrote:
>
> 02.10.2020, 19:46, "Jonathan Bedard" :
> > Monotonic Commit Identifiers
> > Of great interest to Apple’s engineers has been retaining some kind of 
> > ordered tag we can use to refer to commits to make defending CI and 
> > bisection easier. We’ve developed a scheme for this that assigns commits an 
> > ordered identifier per-branch, outlined in 
> > https://trac.webkit.org/wiki/commit-identifiers, designed to be used 
> > alongside git hashes. These identifiers can be used in our current 
> > Subversion repository, and we would like to start using them before the 
> > project has transitions to git.
>
> AFAIU, this is very close to what `git describe` does: you give it git hash, 
> it gives you new identifier consisting of 3 parts:
>
> --

We don't want to be using a number from the closest tag. We need a
contiguous monotonically increasing number on the main branch.

> Note that resulting identifier can be used in all git operations which 
> require git reference (like `git log` or `git show`).
> So, if you push git tags to main repository (maybe lightweight tags, if you 
> are planning to have lots of them), there is no need to invent any other 
> identifiers.
>
> As for bisection, git bisect works just fine when given two commit hashes.

"git bisect" is wholly inadequate for our purposes. Not only can
building between each step can take ages (15-40min depending on a
machine) even for correctness bisections, some of our performance
tests will require many hours to measure statistically significant
results. On top of that, many of our bisections can take weeks if not
months to conduct and could span hundreds of commits in between. In
some cases, we have to compare time series charts of performance data
across multiple operating systems and device classes. Furthermore, we
have to communicate all this information between different teams
working on the bisection, someone who wrote the original patch, QA
people testing various builds, etc... It's extremely important that we
have a **human readable number** which is easy to memorize and intuit
during these analyses and communications.

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


Re: [webkit-dev] WebKit Transition to Git

2020-10-03 Thread Ryosuke Niwa
On Sat, Oct 3, 2020 at 2:25 AM Adrien Destugues
 wrote:
>
> On Fri, Oct 02, 2020 at 07:05:21PM -0500, Michael Catanzaro wrote:
> > > I realize that Gerrit might not integrate at all with hosting the repo
> > > on Github, but has any thought been given to this aspect of the
> > > transition?
> >
> > That sounds like it would be a significant barrier to contribution, and
> > frankly defeat the point of switching. If we have serious concerns with
> > GitHub's code review functionality (which, again, I'm not familiar with),
> > then we should just use GitLab and have everything in one place. (GitLab
> > accepts GitHub logins via OAuth, both on gitlab.com and self-hosted
> > instances, so the barrier to contributing remains low either way.)
>
> Gerrit accepts GitHub and other OAuth providers as well, so that's not a
> problem. We have been using this for Haiku code reviews for a few years
> now, and interestingly we got some complaints from people who don't want
> to have a Github account (for various reasons) and won't use our code
> review tool because of that.
>
> I think the integration referred to was rather in terms of having
> reviews synchronized between Gerrit and Github pull requests, which is
> also possible, but I think if the point is to use Github, it doesn't
> work this way: if your workflow is too different from the standard way
> to use Github, people will still be confused by it and it will still be
> a barrier to contribution.

But using Gerrit would make that situation any better either.

> I think having to create an account on a website isn't the main thing
> preventing people to contribute anyway? It's more about having to use
> project-specific tools to prepare the patch for submission (in the case
> of WebKit, having to write the commit message in the Changelog file, for
> example).

It's about all those things. We've definitely heard of people
complaining or refusing to create a Bugzilla account to report bugs.
I've gotta say I'm very much concerned about getting rid of change
logs when we move to Git. We put a lot of useful information about
what was causing the bug, how we fixed it, and why we fixed the way we
did in a change log. I've seen a few projects which transitioned to
Git and somehow lost the rigor in maintaining an equally high quality
commit message, partly because most code review tools don't let you
add inline comments to commit messages.

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


Re: [webkit-dev] Issue reports, merge requests, etc. (was: WebKit Transition to Git)

2020-10-02 Thread Ryosuke Niwa
I feel like I should write longer replies but here we go.

On Fri, Oct 2, 2020 at 12:53 PM Michael Catanzaro  wrote:
>
> On Fri, Oct 2, 2020 at 11:51 am, Ryosuke Niwa  wrote:
> > Since Igalia has a lot
> > more experience working with other open source projects, do you have
> > some suggestions in how to approach that?
>
> Sorry for a long-ish mail. I didn't mean for this to turn into an
> essay. Too late. :P
>
> I actually moved to Red Hat, but anyway, I would say first step is to
> ensure every incoming issue is triaged, at least once when initially
> reported, and every merge request given at least cursory review within
> a reasonable amount of time. That's how open source projects attract
> and retain community contributors, and it's been a weakness for WebKit
> for a while (we're not the worst at this, but certainly not good at it
> either). One possible answer for this is to have a "project manager" or
> similar role to triage and prioritize issues, but of course it can also
> be done by developers working together (possibly according to some
> rotation).
>
> WebKit is such a big project that I suspect almost nobody has enough
> expertise to triage all incoming bugs, but most of us have enough
> expertise to figure out which issue labels to apply to an incoming bug
> to pass the issue off to more specialized experts. On GNOME GitLab we
> label incoming issues with Bug, Crash, Enhancement, or Feature (the
> difference between Enhancement and Feature is hazy) and have a variety
> of global and per-project labels that can also be applied to issues
> [1]. The list of current components in WebKit Bugzilla would be a good
> starting point to use here. Every new issue gets reviewed and either
> gets closed or else gets a label applied to indicate it has been
> triaged, usually within one business day. If an issue is open and
> doesn't have any labels, we know it has not been triaged.
>
> A lot of bugs can be closed immediately because they're reported in the
> wrong place, for instance. Most crashes are reported without a
> backtrace; to those, we attach a Needs Information label and point the
> reporter to instructions for getting a backtrace with gdb, and close
> after a few days if not provided. The details don't matter so much as
> the fact that the issue has received minimal human attention. In the
> rare cases where a bug report is perfect and all I need to do is add
> issue labels, I give the issue an upvote to indicate I've seen it, so
> the reporter knows it hasn't been *completely* ignored, even if nobody
> fixes it. The details don't matter so much as that contributors and
> issue reporters feel like they've received at least some attention and
> aren't shouting into a bug wasteland.

Yeah, good bug triaging seems to be a key. A lot of people complain
about how we don't fix bugs they filed as well.

> Then developers subscribe to project-specific labels in accordance with
> their expertise and tolerance for mail. E.g. I watch all issues for
> some projects, but for GLib I'm only subscribed to networking-related
> labels, since problems in the network-related code often impact WebKit.
> Some developers will want to watch only for CSS bugs, only layout bugs,
> only JSC bugs, only WebKitGTK bugs, etc.
>
> Of course, triaging issues doesn't mean they actually get fixed, but
> it's a necessary first step. (And once isn't really enough, either.
> Most of our bugs from 2008 are probably no longer valid, but it takes
> time to review old bugs, and not many people have enough specialized
> technical expertise to triage outside their area of expertise. Anyway,
> once is a starting point.)

Right,  we'd probably continue to receive more bugs than we can chew
on so we'd need some process for prioritization as well.

> Responding to merge requests (or patch reviews) in a timely manner is
> also important (otherwise, contributors disappear). Merge requests take
> longer than issues, but it's good to get to each one within a couple
> days; otherwise, they really start to pile up. We currently have
> patches awaiting review from 2017 [2], and that's just the last time
> somebody decided to mass-deny old review requests. And a lot of these
> are from Apple/Igalia/Sony, who all know who to CC for reviews; imagine
> how much harder it is for someone not familiar with the WebKit
> community to get a patch reviewed. ;) GitHub will probably help with
> this because it puts merge requests front-and-center in its UI, instead
> of requiring us to first discover then take the time to sort through
> the request queue. It's hard to use GitHub without habitually reviewing
> pending requests. ;) The number of open issues and MRs is even clearly
> displayed as a sort of challenge to reduce t

Re: [webkit-dev] WebKit Transition to Git

2020-10-02 Thread Ryosuke Niwa
On Fri, Oct 2, 2020 at 5:06 PM Michael Catanzaro  wrote:
>
> On Fri, Oct 2, 2020 at 13:48, Ken Russell  wrote:
> > Github's code review UI has a couple of feature gaps in my opinion.
> > It's difficult to look at earlier versions of the pull request, in
> > particular to verify that issues found during code review have been
> > fixed. I remember it also being difficult to figure out whether all
> > comments on earlier versions have been addressed.
>
> I'm not familiar with reviews on GitHub. I just want to add that GitLab
> reviews are great and have none of these problems. It's very easy to
> view older versions of merge requests and compare the differences
> between arbitrary revisions of the merge request. (That's often
> important when reviewing small changes to a large merge request.) Every
> discussion thread is clearly marked as either resolved (green!) or
> unresolved, and you can (and should) configure GitLab to block merges
> until all discussions are resolved. (I would be disappointed if GitHub
> doesn't have the same convenience features, as this helps prevent
> mistakes from being forgotten.)

GitHub totally offers this. See, for example:
https://github.com/whatwg/html/pull/5912

> > I realize that Gerrit might not integrate at all with hosting the
> > repo on Github, but has any thought been given to this aspect of the
> > transition?
>
> That sounds like it would be a significant barrier to contribution, and
> frankly defeat the point of switching. If we have serious concerns with
> GitHub's code review functionality (which, again, I'm not familiar
> with), then we should just use GitLab and have everything in one place.
> (GitLab accepts GitHub logins via OAuth, both on gitlab.com and
> self-hosted instances, so the barrier to contributing remains low
> either way.)

Indeed. Gerrit's UI is also quite dense and hard to use for someone
new to it too:
https://gerrit-review.googlesource.com/c/plugins/replication/+/282176

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


Re: [webkit-dev] WebKit Transition to Git

2020-10-02 Thread Ryosuke Niwa
On Fri, Oct 2, 2020 at 11:00 AM Michael Catanzaro  wrote:
>
> On Fri, Oct 2, 2020 at 6:36 pm, Philippe Normand 
> wrote:
> > Would you also consider preventing merge commits in order to keep a
> > clean mainline branch?
>
> Big +1 to blocking merge commits. Merge commits in a huge project like
> WebKit would make commit archaeology very frustrating. (I assume this
> is implied by the monotonic commit identifiers proposal, but it doesn't
> exactly say that.)
>
> I'm sure transition to git and GitHub should go well. I would have
> selected GitLab myself -- it's nicer and also overwhelmingly popular --
> but whatever. (Does GitHub have merge request approvals? Replicating
> our reviewer/owner permissions with GitLab merge request approvals
> would be easy.)
>
> One downside is that using github.com might actually make it *too* easy
> to spam us with low-quality issue reports and merge requests. We've
> historically been pretty bad at maintaining a clean issue tracker --
> the quantity of untriaged issues on Bugzilla is very high -- and GitHub
> will make this worse. That's not an issue with the GitHub platform,
> though. Just something to stay on top of.

Since one of the goals is to engage better with the web developer
community, it's imperative that we improve this process. e.g. we need
some way to review & triage newly filed issues. Since Igalia has a lot
more experience working with other open source projects, do you have
some suggestions in how to approach that?

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

2020-09-29 Thread Ryosuke Niwa
On Tue, Sep 29, 2020 at 1:44 PM Andrew Comminos  wrote:

> Thanks for the response Ryosuke, comments inline.
>
> On 9/23/20 12:37 AM, Ryosuke Niwa wrote:
> > As we have discussed in other avenues, we're skeptical that this API is
> > needed given native apps on iOS and macOS don't need such an API and
> > many iOS apps are considered as a pinnacle of good performance.
>
> Our thesis is that the cooperative multitasking environment on the web
> is significantly more hostile to developers than the native platforms
> that you mention. Developers have little control over what else gets
> scheduled on the event loop, especially across different UAs. Many web
> frameworks seek to yield less often because it guarantees that they
> won't be interrupted due to work in other frames, analytics and other
> third-party scripts, as well as any other work/throttling the UA is
> doing that may be lower priority.
>

If that were the case, then what we need is a way to detect any other high
priority work that may need to be processed, not just user input events.

We've seen these benefits in the origin trial we ran for isInputPending
> in Chrome. For instance, the Google Slides team was able to see a
> substantial improvement in render time (about 25%) of the left-hand-side
> filmstrip UI for complex content by yielding less (which is only really
> possible with isInputPending, as otherwise there would be unacceptable
> input delay). At Facebook, we were able to reduce event latency at p95
> by 100ms (while retaining our scheduler’s throughput) by integrating
> isInputPending.
>
> > Furthermore, a well performing app should be yielding at least every
> > frame, and in that case, there is no need for isInputPending since
> > AppKit will only send at most one NSEvent of a given type per frame by
> > design.
>
> As mentioned above, there are real incentives for developers to yield
> less often than a frame. For these situations, isInputPending allows
> developers to get the throughput wins they want from yielding less,
> while still being responsive to user input (a strict improvement over
> the status quo, where sites are yielding less ungracefully).


That sounds like a terrible incentive to give. We need the main thread to
be not blocked when we need to paint. If you're telling us that adding this
API will allow websites not to do that, then that sounds like even more of
a reason not to add this API.

- 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

2020-09-28 Thread Ryosuke Niwa
On Fri, Sep 25, 2020 at 12:47 AM Frédéric Wang  wrote:

> On 02/09/2019 16:11, Frédéric Wang wrote:
>
> Hello,
>
> 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)
>
> Hi,
>
> An update on this, we have been discussing these and new properties with
> the CSSWG:
>
> https://github.com/w3c/csswg-drafts/issues/5384
>
> The math-depth / math-style CSS properties are being implemented in
> Chromium and renamed/exposed/tweaked in Gecko:
>
> https://mathml-refresh.github.io/mathml-core/#the-math-style-property
>
>
> https://mathml-refresh.github.io/mathml-core/#the-math-script-level-property
>
> So it makes sense to implement them in WebKit (it seems we still don't
> have a "intent to" mechanism, but people can follow
> https://bugs.webkit.org/show_bug.cgi?id=195797).
>
> The CSSWG is fine with a new text-transform value for automatic italic but
> using it for other values is controversial (see
> https://github.com/w3c/csswg-drafts/issues/3775). So if we want to
> preserve backward compatibility and fix existing bugs with mathvariant, we
> should probably re-implement it using an internal math-transform property
> (like what Gecko does) which according to our previous discussion is
> nowadays possible in WebKit.
>
Adding the support for new properties sounds good! My concern here is
really only about backwards compatibility.

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


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

2020-09-24 Thread Ryosuke Niwa
On Thu, Sep 24, 2020 at 8:19 AM David Bokan  wrote:

> Can you clarify what question you’re looking to have answered? Are you
>> asking for a new standards position in light of the replies below?
>>
>
>  There are two specific points:
>
>  - As I understand it, HTML requires multi-vendor interest to merge
> changes to specs. Is Apple's position sufficient to start that process? I'd
> be happy to start turning the spec into PRs but I interpreted the earlier
> position in this thread more as "not-opposed" rather than support (is that
> a fair reading?)
>

Given we're concerned about compatibility and this affects how URL, which
is a pretty fundamental part of the Web, is interpreted, it's fair to say
we're not ready to endorse such a motion.

 - Would Apple accept contributions to WebKit implementing this feature?
>
> Google Search uses this on supporting UAs - user surveys have found this
> improves the user experience. A recently published extension
> 
> to generate links to text already has over 50,000 users. This is clearly
> useful to users but would really be helped if we can make it interoperable
> across browsers.
>

Given the number of internet users is roughly 3.4 billion, and Chrome seems
to have ~1 billion users, 50,000 (0.005%?) seems like a rather small number
of users. I'm not saying that there aren't any user interests and I
disagree with the underlying use cases. However, the fact this may pose a
compatibility issue and affect millions of users who are using (sometimes
very) old browsers to browse the internet, that doesn't seem to suggest a
good risk-reward tradeoff.

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


Re: [webkit-dev] Smart Pointer Analysis Tool for WebKit

2020-09-23 Thread Ryosuke Niwa
On Wed, Sep 23, 2020 at 10:32 AM Darin Adler  wrote:

> On Sep 16, 2020, at 11:32 PM, Ryosuke Niwa  wrote:
>
>1. Every data member to a ref counted object must use either Ref,
>RefPtr, or WeakPtr. webkit.NoUncountedMemberChecker
>
> <https://github.com/llvm/llvm-project/blob/master/clang/docs/analyzer/checkers.rst#id17>
>
> My only worry here is performance. Do we know yet if we can afford it?
>

We still need to find that out. So far, our deployment of smart pointers in
various DOM objects haven't caused perf regressions yet.

The worst case here is Ref, which is much worse than a reference since we
> end up having to use -> instead of . everywhere and you can’t see that
> there is no null involved.
>

In practice, this may not matter much because in many of our codebases,
most of references are used as function arguments, in which case, they're
still allowed without having to store in a local Ref / RefPtr. There are
quite a few cases where data members are references but then those can also
be replaced by a simple member function which retrieves the value of the
smart pointer member variable and returns a reference.

>
>1. Every ref counted base class, if it has a derived class, must
>define a virtual destructor. webkit.RefCntblBaseVirtualDtor
>
> <https://github.com/llvm/llvm-project/blob/master/clang/docs/analyzer/checkers.rst#id16>
>
> The style system has an optimization that intentionally violates this for
> performance reasons (StyleRuleBase).
>

Interesting. I wasn't aware of this example. We're planning to add some
kind of compiler-level annotations to exempt these warnings so we may need
to apply that here if it's important for performance.

>
>1. 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
>
> <https://github.com/llvm/llvm-project/blob/master/clang/docs/analyzer/checkers.rst#id21>
>
> What is a non-trivial function?
>

For now, a trivial function is defined as a member function defined in the
class declaration whose definition simply returns a member variable (the
result of get() or a copy if the member variable is a smart pointer).

>
>1. Every ref counted object must be captured using Ref or RefPtr for
>lambda. webkit.UncountedLambdaCapturesChecker
>
> <https://github.com/llvm/llvm-project/blob/master/clang/docs/analyzer/checkers.rst#id18>
>
> Ref, RefPtr, or WeakPtr, right?
>
> Same concern about Ref vs references.
>

This is an interesting point. We should probably amend the rule to allow
WeakPtr as well.

Jan: do we currently allow WeakPtr or just Ref / RefPtr?

We probably also need to figure out a way to exempt all lambda functions
that never get stored anywhere. We have a bunch of helper functions like
WTF::map which just calls lambdas on each item while iterating over an
array, etc... and there is no need to create a separate Ref / RefPtr in
those cases since lambdas are never stored and re-used later.

I wonder if there is a way for your tool to automatically figure that out?
e.g. notice that a function never stores lambda anywhere, and then
propagate that information as some kind of function attribute. Then any
function that doesn't store lambda anywhere and only calls those functions
that also don't store lambda anywhere can marked as "safe".

>
>1. Local variables - we’re still working on this (
>https://reviews.llvm.org/D83259)
>
> I am looking forward to learning more about the proposal here.
>
> Same concern about Ref vs. references.
>
> I really want to see before/after for some non-trivial source files with
> significant problems; where will this drive the most change and what will
> things look like after?
>

Right, for both performance measurements and code changes, we probably want
to fix warnings in a large quality in some important files and see
before/after.

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


Re: [webkit-dev] Smart Pointer Analysis Tool for WebKit

2020-09-23 Thread Ryosuke Niwa
On Thu, Sep 17, 2020 at 2:51 AM Emilio Cobos Álvarez 
wrote:

> Interesting. This looks fairly similar to some of the checkers we use in
> mozilla-central, fwiw.
>
> One interesting difference is that we opted for explicitly annotating
> the functions that can run script (think updateStyleIfNeeded(),
> dispatchEvent() etc equivalents) to be able to not warn for cases where
> using raw pointers is fine. See [1] for the current rules we're using.
>

That's an interesting alternative. We should consider that if the current
approach proves to cause perf issues.

So, I wonder... for a concrete example like [2], what is what would
> allow you to use shadowHost() without storing it on a local RefPtr
> otherwise, for example? Or is the plan to either pay the refcount churn,
> or silence the warnings on a per-case basis?
>

In this case, we'd like to store shadowHost() on a local RefPtr. "contains"
might be a common enough function that we could consider marking as safe
but in more generic case, there is no guarantee that contains would never
trigger a style or layout update, either of which may execute arbitrary
scripts. Also, script execution isn't the only way to get to memory
unsafely. Any piece of code that manipulates a complex enough data
structure may lead to use-after-free even if there was no arbitrary script
execution involved.

[1]:
>
> https://searchfox.org/mozilla-central/rev/f4b4008f5ee00f5afa3095f48c54f16828e4b22b/build/clang-plugin/CanRunScriptChecker.cpp#5-49
> [2]:
>
> https://webkit-search.igalia.com/webkit/rev/4c54a6d287d7fba30e1fb37d5afda692fb12a758/Source/WebCore/dom/Node.cpp#1041


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


Re: [webkit-dev] Smart Pointer Analysis Tool for WebKit

2020-09-23 Thread Ryosuke Niwa
On Thu, Sep 17, 2020 at 2:11 AM Konstantin Tokarev 
wrote:

>
> Sounds great! A few questions:
> * Do I understand correctly that analyzer is a part of upstream clang and
> can work on any platform?
>

Yes.

* Does it require WebKit trunk or can work with older branches?


It should work with older branches as well as trunk since it doesn't rely
on any code-level annotations for now.

However, the plan is to add some annotations in the future to suppress
warnings where appropriate although we're hoping that we wouldn't need them
in too many places.

* Any plans to detect other kinds of misuses like circular references?
>

Not for now. For now, our primary focus is to detect dangerous use of
RefCounted objects and possibly any objects that can make WeakPtr in the
future.

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

2020-09-23 Thread Ryosuke Niwa
On Fri, Sep 18, 2020 at 11:56 AM Andrew Comminos  wrote:

> We're looking to gather a position from WebKit folks on isInputPending,
> an API to query for the presence of pending input events. It allows
> sites to reduce event latency by yielding during longer computational
> tasks, without sacrificing throughput otherwise.
>
> Explainer: https://github.com/WICG/is-input-pending/
>
> Spec: https://wicg.github.io/is-input-pending/
>

As we have discussed in other avenues, we're skeptical that this API is
needed given native apps on iOS and macOS don't need such an API and many
iOS apps are considered as a pinnacle of good performance.

Also, there are many other things an app needs to yield to respond /
process. There could be another frame pending to be rendered, or a network
request for which a response is ready. There are no ways to inspect whether
such a task is pending or not, and we don't want to end up with isXPending
for every X we can think of in the future.

Furthermore, a well performing app should be yielding at least every frame,
and in that case, there is no need for isInputPending since AppKit will
only send at most one NSEvent of a given type per frame by design.

As such, Apple's WebKit team does not support the current proposal.

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


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

2020-09-23 Thread Ryosuke Niwa
On Fri, Sep 18, 2020 at 7:35 AM David Bokan  wrote:

> Friendly ping to get an answer here.
>
> Do my answers above address those points or is there anything else I can
> clarify?
>
> Thanks,
> David
>
> On Mon, Aug 31, 2020 at 1:42 PM David Bokan  wrote:
>
>> [sending (again, sorry) from correct e-mail]
>>
>> I think Nick's replies
>>  
>> mostly
>> still apply, some updated answers to those questions.
>>
>> (1) We’re concerned about compatibility issues in a world where some
>>> browsers support this but not all. Aware browsers will strip `:~:`, but
>>> unaware browsers won’t. I saw that on the blink-dev ItS thread, it was
>>> mentioned that at least one site (webmd.com) totally breaks if any
>>> fragment ID is exposed to the page. This makes it difficult to create a
>>> link that uses this feature but which is safe in all browsers:
>>> - Since there is no feature detection mechanism, it’s hard for a webpage
>>> to know whether it should issue such a link. It would have to be based on
>>> UA string checks, which is regrettable.
>>> - A link meant for a supporting browser can end up in a non-supporting
>>> browser, at the very least by copy paste from the URL field, and perhaps
>>> through other features to share a link.
>>>
>>
>> We do have a feature detection
>> 
>>  mechanism
>> for this.
>>
>> On the latter point, this is true but we think implementing fragment
>> directive stripping (removing the part after and including `:~:`) is
>> trivial even if the UA doesn't wish to implement the text-fragment feature.
>> FWIW, we haven't seen or heard of another such example since.
>>
>
We're continued to be concerned about this backwards compatibility issue.

(3) Text fragment trumping a regular fragment ID seems a bit strange. The
>>> more natural semantic would be that the text search starts at the fragment,
>>> so if there are multiple matches it’s possible to scroll to a more specific
>>> one. It’s not clear why the fragment is instead entirely ignored.
>>>
>>
>> This was discussed in more detail in issue#75
>> ; I agree
>> with Nick's point that the disambiguation syntax is already specific enough
>> that starting from a fragment isn't necessary. This also keeps us
>> mostly-compatible with the TextQuoteSelector
>>  specified
>> in WebAnnotations which I think may have benefits for interaction with
>> annotation applications.
>>
>
This will limit the utility of this feature. For something as board
impacting as a URL format change, it seems rather short sighted.

Also, Web Annotations Data Model allows other kinds of annotations:
https://www.w3.org/TR/2017/REC-annotation-model-20170223/#selectors

Is there any reason this particular matching algorithm was picked and only
picked with no possibility of the future extensibility?

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


[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


  1   2   3   4   5   6   7   8   9   10   >