[webkit-dev] WebKit SVN Tree clousure (Nov 22nd - Nov 26th, 2020)

[Ling Ho via webkit-dev]

Hello WebKit,

Some of our critical continuous integration services will be unavailable 
due to planned underlying infrastructure maintenance.


Most EWS and post-commit bots will be down, so we will be closing the 
WebKit SVN tree to avoid accumulating difficult to diagnose regressions 
during this lengthy outage.


The planned closure of the tree will begin at *8 pm (PST) on Sunday, Nov 
22nd, 2020* until no later than *11 pm (PST) on Thursday, Nov 26th**, 2020.


*Please email ad...@webkit.org if you have any questions or concerns.

Thanks,

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

[webkit-dev] Request for position on Readable Byte Streams

[Nidhi Jaju via webkit-dev]

Hello Webkit-dev,

I would like to ask for Webkit's official position on the readable byte
streams API 
specification. For streams representing bytes, readable byte streams are an
extended version of readable streams which are provided to handle bytes
efficiently, and allow for BYOB (bring-your-own-buffer) readers to be
acquired.

TAG Review: https://github.com/w3ctag/design-reviews/issues/567
Chrome Platform Status Entry:
https://chromestatus.com/feature/4535319661641728
Request for Mozilla Position:
https://github.com/mozilla/standards-positions/issues/457

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

[webkit-dev] Change to the lists.webkit.org From header field

[Ling Ho via webkit-dev]

To counter the recent increase in bounced mails due to DMARC enforcement 
by many receipient domains, we have made a configuration change. This is 
to prevent bounces which are causing list users from being unsubcribed 
from the webkit-dev and other WebKit mailing lists.


The "From" header field will now shows "Full Name via webki-dev 
". The "Reply to" field will show the 
correct sender and therefore Reply, Reply To and Reply List functions in 
your email clients should work correctly.


Please let me know if you see any issue.

Thanks,

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

Re: [webkit-dev] Reminder: include everything that you use in implementation files

[Peng (WebKit) Liu via webkit-dev]

Hi Brian,

Any way/option to turn off the unified build completely or partially in a local 
build? That would be very helpful for a developer to locally verify that header 
files are included correctly in a patch. Thanks!

Best regards
Peng

> On Nov 6, 2020, at 11:21 AM, Brian Burg via webkit-dev 
>  wrote:
> 
> Hello folks,
> 
> I'd like to remind everyone to please include what you use in .cpp,  .mm, and 
> other files. When reviewing patches, please
> ensure that new mentions of classes, structs, etc. within an implementation 
> file have a corresponding header include. 
> All of our headers have #pragma once, so there is no downside to being more 
> explicit.
> 
> I've been noticing an uptick in the number of unified sources-related build 
> failures. I can't remember the last nontrivial patch
> I wrote that did *not* include unrelated build fixes. Typically these 
> failures aren't found until EWS results come back, reducing developer 
> velocity.
> And obviosuly it's super annoying to encounter completely unrelated build 
> failures that must be nonetheless addressed.
> 
> Let's all do our part so that hacking on WebKit remains delightful.
> 
> Thanks,
> 
> Brian Burg (he/they)
>  WebKit Developer Experience
> ___
> 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] Position on WebXr Lighting Estimation Module

[Alex Cooper via webkit-dev]

Hello Webkit,

I'd like to ask for WebKit's position on the WebXR Lighting Estimation
Module. It's an extension of the WebXr Device API from the Immersive Web
Community Group. The API allows web applications to request both the
spherical harmonics representing ambient light as well as a reflection map.
More details can be found in the explainer and specification draft.

Explainer:
https://github.com/immersive-web/lighting-estimation/blob/main/lighting-estimation-explainer.md
Spec Draft: https://immersive-web.github.io/lighting-estimation/
Chromestatus: https://www.chromestatus.com/features/5704707957850112

Could I get your position on this?

Thanks,
Alex Cooper
___
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

[Jonathan Bedard]

Forgot to update this thread: taking a different approach, will be tracked by 
the same bug. Will answer inline.

> On Nov 11, 2020, at 7:56 AM, Michael Catanzaro  wrote:
> 
> On Wed, Nov 4, 2020 at 11:51 am, Jonathan Bedard  wrote:
>> We don´t have post commit hooks in SVN to do this sort of thing, and I don´t 
>> intend to add them now. We are going to have a system on GitHub to do this 
>> (not post commit hooks, but I won´t dive into the details here).
>> There really aren´t a lot of people who land changes outside of 
>> webkit-patch, among things that would break if folks were regularly not 
>> using webkit-patch is trac.webkit.org, which relies on the commit message 
>> being set.
> 
> Probably not often on trunk. But on stable branches, I assume 100% of changes 
> are landed without webkit-patch? At least, I always used 'git svn dcommit' on 
> stable branches. I also used this on trunk when I needed to fix an error in a 
> ChangeLog (something webkit-patch is not good at doing).

Turns out, directly using svn commit (or git svn dcommit) was far more common 
than I originally thought. We can edit SVN changelogs after a change has 
landed, that’s what I’m intending on doing.

> 
>> Lastly, this doesn´t add a race-condition that wasn´t already there. One of 
>> the downsides of SVN is that, unlike git, it is a centralized version 
>> control system, so clients must be synced to upstream before committing. 
>> This is true now, even if you haven´t noticed it. If we didn´t have this 
>> race condition, our changeling history would be full of weird conflicts.
> 
> There should be no race condition because our GitHub repo should only allow 
> fast-forward commits. A server hook can ensure the commit identifiers are 
> sequential. Right?
> 
> 

Server hooks on GitHub are a bit difficult because GitHub (understandably) 
doesn’t let you run arbitrary code inside a commit action. Most projects handle 
this by having a merge-queue that runs code prior to landing a change (which is 
what we’re intending on doing).
___
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

[Michael Catanzaro]

On Wed, Nov 4, 2020 at 11:51 am, Jonathan Bedard  
wrote:
We don’t have post commit hooks in SVN to do this sort of thing, 
and I don’t intend to add them now. We are going to have a system 
on GitHub to do this (not post commit hooks, but I won’t dive into 
the details here).


There really aren’t a lot of people who land changes outside of 
webkit-patch, among things that would break if folks were regularly 
not using webkit-patch is trac.webkit.org, which relies on the commit 
message being set.


Probably not often on trunk. But on stable branches, I assume 100% of 
changes are landed without webkit-patch? At least, I always used 'git 
svn dcommit' on stable branches. I also used this on trunk when I 
needed to fix an error in a ChangeLog (something webkit-patch is not 
good at doing).


Lastly, this doesn’t add a race-condition that wasn’t already 
there. One of the downsides of SVN is that, unlike git, it is a 
centralized version control system, so clients must be synced to 
upstream before committing. This is true now, even if you haven’t 
noticed it. If we didn’t have this race condition, our changeling 
history would be full of weird conflicts.


There should be no race condition because our GitHub repo should only 
allow fast-forward commits. A server hook can ensure the commit 
identifiers are sequential. Right?



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

[webkit-dev] Missing mails since Nov 2, 2020.

[Ling Ho]

Looks like there was a hiccup in the webkit-dev list this past week.

I am sending this out to make sure every one can receive mails now.

I don't know if it is possible to have them resent, so I'd like to 
encourage everyone to take a look at the list archive 
https://lists.webkit.org/pipermail/webkit-dev/2020-November/thread.html 
for any reply you were expecting, or new mails.


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

[webkit-dev] 2020 WebKit Contributors Meeting - Registration Reminder

[Jonathan Davis via webkit-dev]

Hello WebKit Contributors,

Reminder to register for the WebKit Contributors Meeting! You can register at: 
https://webkit.org/meeting/ . Registration is open 
to active contributors to the WebKit open-source project and the meeting is 
free of charge.

The virtual WebKit Contributors Meeting hosted online via WebEx on Monday, 
November 16th from 8 AM to around noon Pacific and Tuesday, November 17th from 
1 PM to around 6 PM Pacific.

Best regards,
Jon Davis



smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Reminder: include everything that you use in implementation files

[Brian Burg via webkit-dev]

Hello folks,

I'd like to remind everyone to please include what you use in .cpp,  .mm, and 
other files. When reviewing patches, please
ensure that new mentions of classes, structs, etc. within an implementation 
file have a corresponding header include. 
All of our headers have #pragma once, so there is no downside to being more 
explicit.

I've been noticing an uptick in the number of unified sources-related build 
failures. I can't remember the last nontrivial patch
I wrote that did *not* include unrelated build fixes. Typically these failures 
aren't found until EWS results come back, reducing developer velocity.
And obviosuly it's super annoying to encounter completely unrelated build 
failures that must be nonetheless addressed.

Let's all do our part so that hacking on WebKit remains delightful.

Thanks,

Brian Burg (he/they)
 WebKit Developer Experience
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Request for position on changing click, auxclick, contextmenu to PointerEvent

[Liviu Tinta via webkit-dev]

Hello WebKit-dev,

I'd like to ask for Webkit's official position on changing “click”,
“contextmenu”, “auxclick” events to PointerEvent (instead of MouseEvent) to
let developers:

- distinguish between mouse, pen and individual fingers in a multitouch
interaction through pointerType and pointerId attributes, and

- utilize fractional event coordinates for high precision use cases

There were concerns about compat implications of this change but our compat
study (see below) does not support those concerns.

The "click" and "contextmenu" events were defined as MouseEvents decades
ago when a mouse was the only source of pointer-like events.  The "auxclick"
event was defined similarly only a few years ago.  The ability to
distinguish these events by input source in a multi-pointer environment is
a long-standing developer request (e.g. this MSDN request [1]).
PointerEvents spec discussion [2] reached consensus that it would be a
useful change and also expressed compat concerns [3].

Compat Study

To better understand compat implications, Chrome committed [4] to
experimenting in the wild. Chrome made the change available as an
experimental web-platform feature in Sep 2019, started an experiment in
Canary in Aug 2020, and gradually expanded the scope of the experiment to
cover Canary, Dev and Beta by Nov 3rd 2020. So far there were no related
bug reports.

Related specification changes:

   -

   PointerEvents pending PR [5]
   -

   UIEvents merged PR [6]
   -

   Html pending PR1 [7]
   -

   Html pending PR2 [8]


Mozilla standards-position:
https://github.com/mozilla/standards-positions/issues/455

TAG Review: The TAG
review process is being skipped because this change does not involve a
design decision.

[1]
https://social.msdn.microsoft.com/Forums/en-US/d50efbfd-fb96-47d8-86e3-98c0c65409c0/create-event-for-quotmouse-clickquot-and-quottouch-clickquot-separately?forum=winappswithhtml5

[2] https://github.com/w3c/pointerevents/issues/100

[3] https://github.com/w3c/pointerevents/issues/100#issuecomment-304941643

[4]
https://lists.w3.org/Archives/Public/public-pointer-events/2019AprJun/0071.html

[5] https://github.com/w3c/pointerevents/pull/317

[6] https://github.com/w3c/uievents/pull/259

[7] https://github.com/whatwg/html/pull/5324

[8] https://github.com/whatwg/html/pull/6126

Thank you,

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

[webkit-dev] Build bot workers aperez-{wpe, gtk}-ews to be rebooted for maintenance

[Adrian Perez de Castro via webkit-dev]

Hi all,

Quick PSA: the two build bot workers I run will be brought down for a short
period of time at 05:30 PST due to a kernel update; the machine where they
are hosted is going to be rebooted. Most likely this will take only a few
minutes =)

Cheers,
—Adrián


pgpLIHd8suLcc.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Build bot workers aperez-{wpe, gtk}-ews to be rebooted for maintenance

[Adrian Perez de Castro via webkit-dev]

On Fri, 06 Nov 2020 15:05:59 +0200 Adrian Perez de Castro  
wrote:
 
> Quick PSA: the two build bot workers I run will be brought down for a short
> period of time at 05:30 PST due to a kernel update; the machine where they
> are hosted is going to be rebooted. Most likely this will take only a few
> minutes =)

Done! The machine is back, along with the EWS builders.

Cheers,
—Adrián


pgpKfupEJ_rw0.pgp
Description: PGP signature
___
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

[David Bokan via webkit-dev]

Thanks Maciej, that's helpful feedback. I'll work on the spec text to
clarify all these cases and circle back when that's done.

On Sun, Nov 1, 2020 at 8:24 PM Maciej Stachowiak  wrote:

>
>
> On Oct 30, 2020, at 1:40 PM, David Bokan  wrote:
>
> Hi Ryosuke,
>
> Would just like to clarify one point.
>
> On Fri, Sep 25, 2020 at 12:42 PM David Bokan  wrote:
>
>> [Sorry, meant to reply-all]
>>
>> On Fri, Sep 25, 2020 at 1:25 AM Ryosuke Niwa  wrote:
>>
>>>
>>> On Thu, Sep 24, 2020 at 8:19 AM David Bokan  wrote:
>>>
 Can you clarify what question you’re looking to have answered? Are you
> asking for a new standards position in light of the replies below?
>

  There are two specific points:

  - As I understand it, HTML requires multi-vendor interest to merge
 changes to specs. Is Apple's position sufficient to start that process? I'd
 be happy to start turning the spec into PRs but I interpreted the earlier
 position in this thread more as "not-opposed" rather than support (is that
 a fair reading?)

>>>
>>> Given we're concerned about compatibility and this affects how URL,
>>> which is a pretty fundamental part of the Web, is interpreted, it's fair to
>>> say we're not ready to endorse such a motion.
>>>
>>
> The change we've proposed and implemented in Chrome doesn't touch anything
> in the URL spec or handling; it's entirely an extension to fragment
> processing in HTML documents only. If this were implemented in WebKit and
> Gecko I think that'd address any compat issues? If you don't agree, could
> you clarify what you see as the main compat risk?
>
>
> It looks like the current spec does not affect URL per se, but does have
> this remark re the fragment directive: "It is reserved for UA instructions,
> such as text=, and is stripped from the URL during loading so that author
> scripts can’t directly interact with it.” <
> https://wicg.github.io/scroll-to-text-fragment/#the-fragment-directive>
>
> The is not specified precisely enough for interop. What does it mean to
> strop the fragment directive from the UR? When during loading does this
> occur?
>
> Section 3.3.1 is more specific <
> https://wicg.github.io/scroll-to-text-fragment/#parsing-the-fragment-directive>
> in that it monkeypatches the HTML create and initialize a Document object
> steps in a way that would affect what JavaScript sees.  However, it’s not
> clear what happens to other ways the UA exposes the URL, such as in the
> location field, or if the page is bookmarked or shared.
>
> Regards,
> Maciej
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Container Queries

[Anders Hartvoll Ruud via webkit-dev]

Hi,

We're about to start looking at Container Queries
 in
Chromium. The syntax is a bit up in the air at the moment, so ignoring
that, I was wondering what Webkit's feelings are regarding the underlying
feature?

As far as I understand this is a top requested
 feature from
authors.

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

[Jonathan Bedard]

> > 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
We don’t have post commit hooks in SVN to do this sort of thing, and I don’t 
intend to add them now. We are going to have a system on GitHub to do this (not 
post commit hooks, but I won’t dive into the details here).

There really aren’t a lot of people who land changes outside of webkit-patch, 
among things that would break if folks were regularly not using webkit-patch is 
trac.webkit.org , which relies on the commit message 
being set. The types of changes that would fall outside of this change would be 
ones that don’t map well to a git world anyways, like the creation of a tag or 
branch. Notably, commit-queue is using this script.

Lastly, this doesn’t add a race-condition that wasn’t already there. One of the 
downsides of SVN is that, unlike git, it is a centralized version control 
system, so clients must be synced to upstream before committing. This is true 
now, even if you haven’t noticed it. If we didn’t have this race condition, our 
changeling history would be full of weird conflicts.

Jonathan___
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

[Jonathan Bedard]

>> 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. Why don't we do this in post commit hook instead?

> Yes, if your reason for switching to Git is making things easy for people 
> using Git to contribute,
> please try to use the standard Git commands as much as possible. Otherwise, 
> from a developer experience
> point of view you are still doing your custom system, and it does not matter 
> that the backend is Git.

> You can use an approach similar to the hook used for Gerrit:
> https://gerrit-review.googlesource.com/Documentation/cmd-hook-commit-msg.html 
> 

> Note that this hook runs locally on developer's machine, but you can 
> additionally have a server-side hook that
> checks that the id is indeed present in the commit message, and rejects the 
> commit otherwise (Gerrit also does
> this for its Change-Id). I think it is not possible to alter the commit 
> message from server-side with a standard
> Git server, it would create confusion because the local branch from the 
> developer machine would not match what's
> on the server.

> -- 
> Adrien.
The long term plan is to have the default branch be protected and all commits 
go though commit-queue. This means that contributors are using the default set 
of git commands, but most contributors (even committers and reviewers) would 
not have push access to the default branch (and other “production” branches, 
although we need to define exactly what that means), and are instead sending 
pull requests to commit-queue (or merge-queue, if you prefer, it may be 
re-branded) to be landed.

The mechanics of the current change operate on SVN, not Git. And we already 
rely pretty heavily on contributors using webkit-patch to land changes, 
trac.webkit.org  wouldn’t work well if the vast 
majority of contributors were not using it to land change.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] User Agent Client Hints

[Yoav Weiss]

On Tue, Nov 3, 2020 at 8:03 PM Alex Christensen 
wrote:

> If I understand this correctly, the state of having received an Accept-CH
> header field in a response to a previous request is used to determine
> whether these new Sec-CH-* header fields will be sent.  Not only does this
> add a new place to store bits on the client (as acknowledged by
> https://wicg.github.io/client-hints-infrastructure/#accept-ch-cache-definition
>  )
> but it also seems to not provide a method for a server to receive client
> hint header fields on the first request from a client.  Would both of these
> concerns be resolved if we used something like ALPN instead of needing to
> store state on the client?
>

+David Benjamin 's Client Hints reliability proposal
and its ALPS part

are
planned to tackle something very similar to your ALPN proposal.

FWIW, the Accept-CH cache can only be set by HTTP response headers on the
top-level document, and are cleared whenever client state (e.g. cookies)
are cleared. So while it is another place to store state, it doesn't
outlive current same-origin client-side storage.

 Am I understanding the Client Hints Infrastructure correctly?
>
> On Nov 2, 2020, at 3:32 PM, Maciej Stachowiak  wrote:
>
>
>
> On Nov 2, 2020, at 8:56 AM, Yoav Weiss  wrote:
>
> Thanks for re-reviewing, Maciej!
>
> Adding Mike Taylor, who's likely to take a closer look at this.
>
> On Mon, Nov 2, 2020 at 2:17 AM Maciej Stachowiak  wrote:
>
>>
>> I just did a fresh review of that spec and explainer. Thanks for
>> addressing many of the previous issues. This addresses many of the
>> potential objections.
>>
>> Here’s the new issues I filed:
>>
>> https://github.com/WICG/ua-client-hints/issues/141
>> https://github.com/WICG/ua-client-hints/issues/142
>> https://github.com/WICG/ua-client-hints/issues/143
>> https://github.com/WICG/ua-client-hints/issues/144
>> https://github.com/WICG/ua-client-hints/issues/145
>> https://github.com/WICG/ua-client-hints/issues/146
>> https://github.com/WICG/ua-client-hints/issues/147
>> https://github.com/WICG/ua-client-hints/issues/148
>> https://github.com/WICG/ua-client-hints/issues/149
>> https://github.com/WICG/ua-client-hints/issues/150
>> https://github.com/WICG/ua-client-hints/issues/151
>>
>>
> Thanks for filing those! We'll take a look and respond shortly.
>
>
>> Most of these are minor/editorial, but I think 151 is potentially a
>> deal-breaker. I may be misreading the spec, but as written
>> getHighEntropyValues seems to give access to all of the high entropy client
>> hints to third-party scripts in the first party context, and scripts
>> running in third-party iframes, regardless of which ones the site has opted
>> into via the relevant HTTP header.
>>
>
> That's indeed the case, as we didn't consider the Client Hints opt-in to
> be something that impacts the availability of the JS API. (as it doesn't do
> that for other hints)
>
>
> We’re currently deeply skeptical of implementing any of the other client
> hints due to their expansion of fingerprinting surface, so I don’t feel
> particularly compelled by that precedent. That said, it’s likely the other
> client hints have this same problem, where they expose fingerprinting
> surface way more widely than they may be intending to.
>
> That would be a huge problem, as it would grant a lot of active
>> fingerprinting surface unnecessarily
>>
>
> We did discuss
>  
> adding
> a Feature Policy (now Permission Policy) to that effect. Would that help
> with your concerns?
>
>
> My understanding is that feature policy applies at the frame level, and
> therefore could not be used to control what happens when a third-party
> script in a first party context calls the API. Even for third-party
> iframes, it seems like Feature Policy could only default-deny this JS API
> entirely, and would not be able to filter the results down to the set
> delegated via HTTP headers (or otherwise). Maybe you intend a feature
> policy per individual high entropy hint, but first of all that seems like
> overkill, and second, the spec is clearly not written to support such
> filtering.
>
> So no, it would not address the concerns.
>
> I think the best approach is to limit the hints to those opted into (or,
> in case of a third-party frame, delegated). That or remove the script API
> entirely. The origin-based delegation model that works well at the HTTP
> level is not well aligned with the widespread practice of including
> third-party scripts in the top frame.
>
> The spec does not eve allow denying the request entirely as written. A
> non-normative Note suggests that is allowed, but I can’t find any step in
> the algorithm that would ever reject the promise.
>
>
>
>> (perhaps even expanding beyond what is currently possible with the UA
>> string).
>>
>
> Can you expand on 

Re: [webkit-dev] User Agent Client Hints

[Alex Christensen]

If I understand this correctly, the state of having received an Accept-CH 
header field in a response to a previous request is used to determine whether 
these new Sec-CH-* header fields will be sent.  Not only does this add a new 
place to store bits on the client (as acknowledged by 
https://wicg.github.io/client-hints-infrastructure/#accept-ch-cache-definition 

 ) but it also seems to not provide a method for a server to receive client 
hint header fields on the first request from a client.  Would both of these 
concerns be resolved if we used something like ALPN instead of needing to store 
state on the client?  Am I understanding the Client Hints Infrastructure 
correctly?

> On Nov 2, 2020, at 3:32 PM, Maciej Stachowiak  wrote:
> 
> 
> 
>> On Nov 2, 2020, at 8:56 AM, Yoav Weiss mailto:y...@yoav.ws>> 
>> wrote:
>> 
>> Thanks for re-reviewing, Maciej!
>> 
>> Adding Mike Taylor, who's likely to take a closer look at this.
>> 
>> On Mon, Nov 2, 2020 at 2:17 AM Maciej Stachowiak > > wrote:
>> 
>> I just did a fresh review of that spec and explainer. Thanks for addressing 
>> many of the previous issues. This addresses many of the potential objections.
>> 
>> Here’s the new issues I filed:
>> 
>> https://github.com/WICG/ua-client-hints/issues/141 
>> 
>> https://github.com/WICG/ua-client-hints/issues/142 
>> 
>> https://github.com/WICG/ua-client-hints/issues/143 
>> 
>> https://github.com/WICG/ua-client-hints/issues/144 
>> 
>> https://github.com/WICG/ua-client-hints/issues/145 
>> 
>> https://github.com/WICG/ua-client-hints/issues/146 
>> 
>> https://github.com/WICG/ua-client-hints/issues/147 
>> 
>> https://github.com/WICG/ua-client-hints/issues/148 
>> 
>> https://github.com/WICG/ua-client-hints/issues/149 
>> 
>> https://github.com/WICG/ua-client-hints/issues/150 
>> 
>> https://github.com/WICG/ua-client-hints/issues/151 
>> 
>> 
>> 
>> Thanks for filing those! We'll take a look and respond shortly.
>>  
>> Most of these are minor/editorial, but I think 151 is potentially a 
>> deal-breaker. I may be misreading the spec, but as written 
>> getHighEntropyValues seems to give access to all of the high entropy client 
>> hints to third-party scripts in the first party context, and scripts running 
>> in third-party iframes, regardless of which ones the site has opted into via 
>> the relevant HTTP header. 
>> 
>> That's indeed the case, as we didn't consider the Client Hints opt-in to be 
>> something that impacts the availability of the JS API. (as it doesn't do 
>> that for other hints)
> 
> We’re currently deeply skeptical of implementing any of the other client 
> hints due to their expansion of fingerprinting surface, so I don’t feel 
> particularly compelled by that precedent. That said, it’s likely the other 
> client hints have this same problem, where they expose fingerprinting surface 
> way more widely than they may be intending to.
> 
>> That would be a huge problem, as it would grant a lot of active 
>> fingerprinting surface unnecessarily 
>> 
>> We did discuss 
>>  
>> adding a Feature Policy (now Permission Policy) to that effect. Would that 
>> help with your concerns?
> 
> My understanding is that feature policy applies at the frame level, and 
> therefore could not be used to control what happens when a third-party script 
> in a first party context calls the API. Even for third-party iframes, it 
> seems like Feature Policy could only default-deny this JS API entirely, and 
> would not be able to filter the results down to the set delegated via HTTP 
> headers (or otherwise). Maybe you intend a feature policy per individual high 
> entropy hint, but first of all that seems like overkill, and second, the spec 
> is clearly not written to support such filtering.
> 
> So no, it would not address the concerns.
> 
> I think the best approach is to limit the hints to those opted into (or, in 
> case of a third-party frame, delegated). That or remove the script API 
> entirely. The origin-based delegation model that works well at the HTTP level 
> is not well aligned with the widespread practice of including third-party 
> scripts in the top frame.
> 
> The spec does not eve allow denying the request entirely as written. A 
> non-normative Note suggests 

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

[Adrien Destugues]

3 novembre 2020 00:10 "Ryosuke Niwa"  a écrit:

> 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. Why don't we do this in post commit hook instead?

Yes, if your reason for switching to Git is making things easy for people using 
Git to contribute,
please try to use the standard Git commands as much as possible. Otherwise, 
from a developer experience
point of view you are still doing your custom system, and it does not matter 
that the backend is Git.

You can use an approach similar to the hook used for Gerrit:
https://gerrit-review.googlesource.com/Documentation/cmd-hook-commit-msg.html

Note that this hook runs locally on developer's machine, but you can 
additionally have a server-side hook that
checks that the id is indeed present in the commit message, and rejects the 
commit otherwise (Gerrit also does
this for its Change-Id). I think it is not possible to alter the commit message 
from server-side with a standard
Git server, it would create confusion because the local branch from the 
developer machine would not match what's
on the server.

-- 
Adrien.

___
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

[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] User Agent Client Hints

[Yoav Weiss]

Thanks for the background. Let's continue to discuss on the issue.

On Tue, Nov 3, 2020 at 12:32 AM Maciej Stachowiak  wrote:

>
>
> On Nov 2, 2020, at 8:56 AM, Yoav Weiss  wrote:
>
> Thanks for re-reviewing, Maciej!
>
> Adding Mike Taylor, who's likely to take a closer look at this.
>
> On Mon, Nov 2, 2020 at 2:17 AM Maciej Stachowiak  wrote:
>
>>
>> I just did a fresh review of that spec and explainer. Thanks for
>> addressing many of the previous issues. This addresses many of the
>> potential objections.
>>
>> Here’s the new issues I filed:
>>
>> https://github.com/WICG/ua-client-hints/issues/141
>> https://github.com/WICG/ua-client-hints/issues/142
>> https://github.com/WICG/ua-client-hints/issues/143
>> https://github.com/WICG/ua-client-hints/issues/144
>> https://github.com/WICG/ua-client-hints/issues/145
>> https://github.com/WICG/ua-client-hints/issues/146
>> https://github.com/WICG/ua-client-hints/issues/147
>> https://github.com/WICG/ua-client-hints/issues/148
>> https://github.com/WICG/ua-client-hints/issues/149
>> https://github.com/WICG/ua-client-hints/issues/150
>> https://github.com/WICG/ua-client-hints/issues/151
>>
>>
> Thanks for filing those! We'll take a look and respond shortly.
>
>
>> Most of these are minor/editorial, but I think 151 is potentially a
>> deal-breaker. I may be misreading the spec, but as written
>> getHighEntropyValues seems to give access to all of the high entropy client
>> hints to third-party scripts in the first party context, and scripts
>> running in third-party iframes, regardless of which ones the site has opted
>> into via the relevant HTTP header.
>>
>
> That's indeed the case, as we didn't consider the Client Hints opt-in to
> be something that impacts the availability of the JS API. (as it doesn't do
> that for other hints)
>
>
> We’re currently deeply skeptical of implementing any of the other client
> hints due to their expansion of fingerprinting surface, so I don’t feel
> particularly compelled by that precedent. That said, it’s likely the other
> client hints have this same problem, where they expose fingerprinting
> surface way more widely than they may be intending to.
>
> That would be a huge problem, as it would grant a lot of active
>> fingerprinting surface unnecessarily
>>
>
> We did discuss
>  
> adding
> a Feature Policy (now Permission Policy) to that effect. Would that help
> with your concerns?
>
>
> My understanding is that feature policy applies at the frame level, and
> therefore could not be used to control what happens when a third-party
> script in a first party context calls the API. Even for third-party
> iframes, it seems like Feature Policy could only default-deny this JS API
> entirely, and would not be able to filter the results down to the set
> delegated via HTTP headers (or otherwise). Maybe you intend a feature
> policy per individual high entropy hint, but first of all that seems like
> overkill, and second, the spec is clearly not written to support such
> filtering.
>
> So no, it would not address the concerns.
>
> I think the best approach is to limit the hints to those opted into (or,
> in case of a third-party frame, delegated). That or remove the script API
> entirely. The origin-based delegation model that works well at the HTTP
> level is not well aligned with the widespread practice of including
> third-party scripts in the top frame.
>
> The spec does not eve allow denying the request entirely as written. A
> non-normative Note suggests that is allowed, but I can’t find any step in
> the algorithm that would ever reject the promise.
>
>
>
>> (perhaps even expanding beyond what is currently possible with the UA
>> string).
>>
>
> Can you expand on that last point?
>
>
> I mean that the client hints might include info that is not in the UA
> sting (possibly not at all, or possibly frozen in UA string but could be
> unfrozen in the client hints).
>
>
>
>>
>> Regards,
>> Maciej
>>
>>
>> On Oct 27, 2020, at 12:35 AM, Yoav Weiss  wrote:
>>
>> Yet-another ping! :)
>>
>> On Wed, Oct 7, 2020 at 8:23 AM Yoav Weiss  wrote:
>>
>>> Friendly ping! :)
>>>
>>> On Wed, Sep 30, 2020 at 9:29 AM Yoav Weiss  wrote:
>>>
 Hi WebKit folks,

 Circling back on the previous discussion
  about
 User-Agent ClientHint. The feature was implemented in Chromium and is being
 rolled out in Chrome.

 There were some concerns mentioned in the previous thread, that we
 believe were since addressed. Would the feature be something that WebKit
 would consider shipping?

 Cheers :)
 Yoav

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