Re: [webkit-dev] maybe_unused vs UNUSED_PARAM

If we’re adopting [[maybe_unused]], do we just write that directly in each function declaration / definition? Or do we define some a macro to do that anyway? What bout other kinds of attributes like [[noreturn]], [[fallthrough]], and [[likely]]? Are we gonna start writing them directly in

Re: [webkit-dev] Approving / Rejects PRs on GitHub when not a reviewer?

I don't think non-reviewers should be able to reject/block PRs as well.- R. NiwaOn Nov 29, 2023, at 07:45, Chris Dumez via webkit-dev wrote:FYI, our official documentation on WebKit.org says:```Making unofficial reviews before you become a reviewer is encouraged. This is an excellent way to show

Re: [webkit-dev] Smart Pointers Usage Guidelines

> On Aug 21, 2023, at 4:51 PM, Ryosuke Niwa via webkit-dev > wrote: > >> On Aug 21, 2023, at 4:50 PM, Tim Horton wrote: >> >>> On Aug 21, 2023, at 4:42 PM, Ryosuke Niwa wrote: >>> >>>> On Aug 21, 2023, at 4:41 PM, Darin Adler wrote: &g

Re: [webkit-dev] Smart Pointers Usage Guidelines

> On Aug 21, 2023, at 4:50 PM, Tim Horton wrote: > > > >> On Aug 21, 2023, at 4:42 PM, Ryosuke Niwa wrote: >> >> >> >>> On Aug 21, 2023, at 4:41 PM, Darin Adler wrote: >>> On Aug 21, 2023, at 4:39 PM, Ryosuke Niwa wrote: Alternatively, we could add a new member

Re: [webkit-dev] Smart Pointers Usage Guidelines

> On Aug 21, 2023, at 4:41 PM, Darin Adler wrote: > >> On Aug 21, 2023, at 4:39 PM, Ryosuke Niwa wrote: >> >> Alternatively, we could add a new member function which returns CheckedPtr >> like `pageChecked()`. > > Yes, I think that would be a good approach that would complement the static

Re: [webkit-dev] Smart Pointers Usage Guidelines

> On Aug 21, 2023, at 4:34 PM, Darin Adler wrote: > > >> On Aug 21, 2023, at 4:31 PM, Tim Horton via webkit-dev >> wrote: >> >>> One subtle thing is that even when a member variable is already Ref / >>> RefPtr / CheckedRef / CheckedPtr, we must create another one in stack as >>> seen

[webkit-dev] Smart Pointers Usage Guidelines

Hi all, It has been a while since I last announced the plan to adopt smart pointers using clang static analyzer: https://lists.webkit.org/pipermail/webkit-dev/2020-September/031386.html Here are some updates. 1. We’ve made a progress in implementing all the rules including rules for local

Re: [webkit-dev] Removal of trailing whitespace

> On Apr 12, 2023, at 12:34 PM, Chris Dumez wrote: > >> On Apr 12, 2023, at 10:23 AM, Ryosuke Niwa via webkit-dev >> wrote: >> >> Yeah, enforcing that new or otherwise modified lines don’t have trailing >> whitespaces would be good. > > Yes, I woul

Re: [webkit-dev] Removal of trailing whitespace

w-diff in PR. > But at the same time, I think there is no reason to add a new trailing > whitespace via a new commit. > It is nice if we can enforce this rule only for newly added code (via > style-checker) not to add new trailing spaces. > > -Yusuke > >> On Apr 12, 2023, a

Re: [webkit-dev] Removal of trailing whitespace

WebKi proejctt’s long term policy has been to not do this: https://lists.webkit.org/pipermail/webkit-dev/2009-August/009665.html I don’t think we should change that. - R. Niwa > On Apr 12, 2023, at 9:17 AM, Chris Dumez via webkit-dev > wrote: > > I am against this because it adds a lot of

Re: [webkit-dev] WebKit Documentation

> On Mar 9, 2023, at 10:48 AM, Brandon Stewart via webkit-dev > wrote: > > Sorry for the delay on the documentation update. > > For getting the documentation system online, we were trying to settle on a > subdomain. > > What would people prefer we use as the official documentation

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

> On Jan 30, 2023, at 6:29 PM, Fujii Hironori via webkit-dev > wrote: > > On Tue, Jan 31, 2023 at 8:28 AM Ryosuke Niwa via webkit-dev > wrote: >> >> I’ve posted https://github.com/WebKit/WebKit/wiki/Smart-Pointer-Usage-Rules >> >> > Ver

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

> On Jan 30, 2023, at 12:11 PM, Ryosuke Niwa via webkit-dev > wrote: > >> On Jan 30, 2023, at 10:47 AM, Alexey Proskuryakov wrote: >> >> Reviving this old thread, reading it again made me wish for two things: >> >> - a wiki document that describes what

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

> On Jan 30, 2023, at 10:47 AM, Alexey Proskuryakov wrote: > > Reviving this old thread, reading it again made me wish for two things: > > - a wiki document that describes what we are trying to do, not just a thread > which patches the proposal with clarifications; Yeah, let me go make one.

Re: [webkit-dev] Unsigned to avoid negative values

> On Jan 24, 2023, at 2:00 AM, Myles Maxfield via webkit-dev > wrote: > > I recently learned that the C++ core guidelines recommend against using > unsigned to avoid negative values. Section 4.4 on page 73 of The C++ > Programming Language says unsigned types should be used for bitfields and

Re: [webkit-dev] Stop Using Raw Pointers & References in New Code

> On Jan 24, 2023, at 5:30 AM, Alicia Boya García via webkit-dev > wrote: > > On 12/01/2023 06.21, Ryosuke Niwa via webkit-dev wrote: >> I suggest we stop using raw pointers and references in any local or heap >> stored variable. > I don't think this is feasibl

Re: [webkit-dev] Stop Using Raw Pointers & References in New Code

> On Jan 13, 2023, at 11:06 AM, Ryosuke Niwa via webkit-dev > wrote: > >> On Jan 13, 2023, at 6:39 AM, Darin Adler wrote: >> >> I don’t think I can notice these patterns. I would be able to program this >> way if I had an analysis tool, but otherwise this

Re: [webkit-dev] Stop Using Raw Pointers & References in New Code

> On Jan 13, 2023, at 6:39 AM, Darin Adler wrote: > > I don’t think I can notice these patterns. I would be able to program this > way if I had an analysis tool, but otherwise this simply seems too > complicated. Yeah, I agree. > I can’t see the types of intermediate values to know if they

Re: [webkit-dev] Stop Using Raw Pointers & References in New Code

> On Jan 12, 2023, at 9:05 PM, Ryosuke Niwa via webkit-dev > wrote: > > >> On Jan 12, 2023, at 8:37 PM, Darin Adler wrote: >> >>> On Jan 12, 2023, at 9:35 PM, Ryosuke Niwa wrote: >>> >>> One alternative is to make bar() return Re

Re: [webkit-dev] Stop Using Raw Pointers & References in New Code

> On Jan 12, 2023, at 8:37 PM, Darin Adler wrote: > >> On Jan 12, 2023, at 9:35 PM, Ryosuke Niwa wrote: >> >> One alternative is to make bar() return RefPtr although that would be a bit >> heavy handed in the case of trivial function calls like this: >> document().frame()->ownerElement() >

Re: [webkit-dev] Stop Using Raw Pointers & References in New Code

> On Jan 12, 2023, at 6:50 PM, Michael Catanzaro wrote: > > On Thu, Jan 12 2023 at 12:35:09 PM -0800, Ryosuke Niwa via webkit-dev > wrote: >> So… instead of: >> foo(bar()); >> do: >> foo(RefPtr { bar() }.get()); > > What's the value

Re: [webkit-dev] Stop Using Raw Pointers & References in New Code

> On Jan 12, 2023, at 1:27 PM, Darin Adler wrote: > >> On Jan 12, 2023, at 3:35 PM, Ryosuke Niwa via webkit-dev >> wrote: >> >>> On Jan 12, 2023, at 6:13 AM, Darin Adler wrote: >>> >>>> On Jan 12, 2023, at 12:21 AM, Ryosuke Niwa via we

Re: [webkit-dev] Stop Using Raw Pointers & References in New Code

> On Jan 12, 2023, at 6:13 AM, Darin Adler wrote: > >> On Jan 12, 2023, at 12:21 AM, Ryosuke Niwa via webkit-dev >> wrote: >> >> assuming every local variable / variable in stack is stored in a smart >> pointer, function arguments are safe to be raw poin

[webkit-dev] Stop Using Raw Pointers & References in New Code

Hi all, Alex recently added ThreadSafeWeakPtr . That should address the last remaining use case of raw pointers (T*) and references (T&). I suggest we stop using raw pointers and references in any local or heap

Re: [webkit-dev] Update commit log template to add placeholder for explanation of why a patch fixes a bug

> On Nov 17, 2022, at 2:46 PM, Michael Catanzaro wrote: > > On Thu, Nov 17 2022 at 02:41:35 PM -0800, Ryosuke Niwa > wrote: >> We don´t want a description of what PR is; that´s obvious from diff. We want >> a description of why that PR fixes the bug. > > Problem is, that is not very useful

Re: [webkit-dev] Update commit log template to add placeholder for explanation of why a patch fixes a bug

> On Nov 17, 2022, at 2:37 PM, Michael Catanzaro via webkit-dev > wrote: > > On Thu, Nov 17 2022 at 12:23:54 PM -0800, David Kilzer via webkit-dev > wrote: >> Any feedback on this change? > > We could alternatively say "Explanation of this change (OOPS!)" or > "Explanation of this commit

Re: [webkit-dev] Update commit log template to add placeholder for explanation of why a patch fixes a bug

> On Nov 17, 2022, at 12:23 PM, David Kilzer via webkit-dev > wrote: > > The following PR adds placeholder text in the commit log template to remind > authors to explain why a change fixes a bug: > > Bug 248012: Update commit message template to request a brief explanation of > why a PR

Re: [webkit-dev] Style guide: enforce `while (true)` over `for (; ; )`

I do prefer for (;;) because of less typing but if the existing code mostly uses while (true) then we should go with it. > On Oct 5, 2022, at 8:58 PM, Yusuke Suzuki via webkit-dev > wrote: > > +1 > > -Yusuke > >> On Oct 5, 2022, at 5:07 PM, Tim Nguyen via webkit-dev >> wrote: >> >> Hi

Re: [webkit-dev] webkit-dev Digest, Vol 208, Issue 5

; >>>>> On Sep 20, 2022, at 1:52 PM, Brent Fulgham >>>> <mailto:bfulg...@apple.com>> wrote: >>>>> >>>>>> On Sep 20, 2022, at 1:16 AM, Ryosuke Niwa via webkit-dev >>>>>> mailto:webkit-dev@lists.webkit.org>> wrote: >

Re: [webkit-dev] webkit-dev Digest, Vol 208, Issue 5

> On Sep 29, 2022, at 11:48 AM, Jonathan Bedard via webkit-dev > wrote: > > >>> On Sep 20, 2022, at 1:52 PM, Brent Fulgham wrote: >>> >>>> On Sep 20, 2022, at 1:16 AM, Ryosuke Niwa via webkit-dev >>>> wrote: >>>>

Re: [webkit-dev] WebKit Documentation

> On Sep 21, 2022, at 6:50 AM, Michael Catanzaro wrote: > > On Tue, Sep 20 2022 at 08:03:12 PM -0700, Ryosuke Niwa via webkit-dev > wrote: >> (2) is particularly important because many people who are new to WebKit >> often don´t know what they don´t know. This is

Re: [webkit-dev] WebKit Documentation

> On Sep 20, 2022, at 1:52 PM, Brent Fulgham wrote: > >> On Sep 20, 2022, at 1:16 AM, Ryosuke Niwa via webkit-dev >> wrote: >> >>> On Sep 19, 2022, at 2:28 PM, Brandon Stewart via webkit-dev >>> mailto:webkit-dev@lists.webkit.org>> wrote: &g

Re: [webkit-dev] WebKit Documentation

> On Sep 20, 2022, at 6:04 AM, Michael Catanzaro wrote: > > On Tue, Sep 20 2022 at 01:16:53 AM -0700, Ryosuke Niwa via webkit-dev > wrote: >> I´ve been working on >> https://github.com/WebKit/WebKit/blob/main/Introduction.md for the past >> couple of years

Re: [webkit-dev] WebKit Documentation

> On Sep 19, 2022, at 2:58 PM, Michael Catanzaro via webkit-dev > wrote: > > Why not double-down on the GitHub wiki? It's very easy to learn to use, and > there are edit buttons everywhere so there is no "distance" between the docs > and the ability to edit them. The easier it is to edit

Re: [webkit-dev] WebKit Documentation

> On Sep 19, 2022, at 2:28 PM, Brandon Stewart via webkit-dev > wrote: > > Documentation is an important part of any open source project, especially for > a larger project like WebKit. Being able to ramp up during the onboarding > process, reading up on architectural decisions, and learning

Re: [webkit-dev] WebKit Documentation

> On Sep 19, 2022, at 4:48 PM, Fujii Hironori via webkit-dev > wrote: > > Why not double-down on WebKit Git repository? > The closer the document is to the source code, the easier to keep them > up-to-date. > We can modify both the source code and the document in a single commit > through

Re: [webkit-dev] Deployment of new EWS Non-Unified builder

> On Sep 8, 2022, at 5:41 AM, Adrian Perez de Castro via webkit-dev > wrote: > On Thu, 08 Sep 2022 02:27:53 + Alexey Proskuryakov via webkit-dev > wrote: >> Without non-unified EWS, or anyone fixing non-unified build manually: >> - a smaller number of patches gets rejected for breaking

[webkit-dev] Goal of Fixing non-Unified Build Failures (Was Deployment of new EWS Non-Unified builder)

> There is no such thing as "not maintaining the non-unified build"; there > never has been. We have covered that this is an *inherent* problem in a > unified build mechanism and that this would be an issue even if Mac were the > only platform. It appears to me that we’re lacking the clarify

Re: [webkit-dev] Deployment of new EWS Non-Unified builder

On Thu, Jun 2, 2022 at 4:28 AM Claudio Saavedra via webkit-dev wrote: > > On Wed, 2022-06-01 at 16:39 -0700, Ryosuke Niwa via webkit-dev wrote: > > One day per month for one beginner sounds like a really low > > maintenance cost compared to having every WebKit developer fi

Re: [webkit-dev] Deployment of new EWS Non-Unified builder

On Wed, Jun 1, 2022 at 16:10 Kirsling, Ross via webkit-dev < webkit-dev@lists.webkit.org> wrote: > I feel like this has been discussed adequately in the past, but one more > time for good measure: > > Any two platforms which don't build the exact same set of files will > undergo unification

Re: [webkit-dev] Proposal: Immediate Deprecation of ChangeLogs

On Wed, May 11, 2022 at 08:12 Chris Dumez wrote: > > On May 11, 2022, at 12:13 AM, Ryosuke Niwa via webkit-dev < > webkit-dev@lists.webkit.org> wrote: > > On Tue, May 10, 2022 at 9:27 PM Ryosuke Niwa wrote: > > > > On Tue, May 10, 2022 at 20:36 Chris Dumez wrot

Re: [webkit-dev] Proposal: Immediate Deprecation of ChangeLogs

On Tue, May 10, 2022 at 10:04 PM Chris Dumez wrote: > > On May 10, 2022, at 9:27 PM, Ryosuke Niwa wrote: >> >> Well, that's precisely my use case. I don't even write a patch in a pure >> Subversion checkout anymore these days. > > Also, I didn’t fully understand this comment. Did you mean that

Re: [webkit-dev] Proposal: Immediate Deprecation of ChangeLogs

g able to send a proper sender > ID due to it being a forwarding address. > >> On May 10, 2022, at 3:04 PM, Ryosuke Niwa via webkit-dev >> wrote: >> >> On Tue, May 10, 2022 at 3:01 PM Jonathan Bedard via webkit-dev >> wrote: >> >> &

Re: [webkit-dev] Proposal: Immediate Deprecation of ChangeLogs

On Tue, May 10, 2022 at 3:01 PM Jonathan Bedard via webkit-dev wrote: > > > On May 10, 2022, at 2:46 PM, Geoffrey Garen wrote: > > > > Do I undertand correctly that the proposal here is > > > > (a) Immediately Deprecate ChangeLogs > > Yes > > > (b) Immediately end support for posting

Re: [webkit-dev] Proposal: Immediate Deprecation of ChangeLogs

I don't think we should this. We haven't even had enough discussions about whether we want to deprecate change logs or not. On Tue, May 10, 2022 at 13:32 Jonathan Bedard via webkit-dev < webkit-dev@lists.webkit.org> wrote: > A few weeks ago, I started a discussion about deprecating ChangeLogs.

Re: [webkit-dev] Introduction.md: JS wrapper & Node lifecycle management

Sorry, I broke the link for DOM nodes due to a typo. See https://github.com/WebKit/WebKit/blob/main/Introduction.md#reference-counting-of-dom-nodes On Sat, May 7, 2022 at 11:05 AM Ryosuke Niwa wrote: > > Hi all, > > I've recently written up an overview of how the lifecycle of JS wrappers and >

[webkit-dev] Introduction.md: JS wrapper & Node lifecycle management

Hi all, I've recently written up an overview of how the lifecycle of JS wrappers and DOM nodes are managed in

Re: [webkit-dev] ChangeLog Deprecation Plan

On Mon, Apr 25, 2022 at 9:49 AM Jonathan Bedard via webkit-dev wrote: > > .. or robust solution. Bots need maintenance and intervention, and a bot with > commit access has another set of issues. Repository admins occasionally > rotating ChangeLogs is going to be less expensive than a bot doing

Re: [webkit-dev] ChangeLog Deprecation Plan

On Tue, Apr 19, 2022 at 9:33 AM Jonathan Bedard via webkit-dev < webkit-dev@lists.webkit.org> wrote: > > > To: Jonathan Bedard > > Cc: WebKit Development > > Subject: Re: [webkit-dev] ChangeLog Deprecation Plans > > Message-ID: > > <

Re: [webkit-dev] ChangeLog Deprecation Plans

On Mon, Apr 18, 2022 at 18:50 Fujii Hironori via webkit-dev < webkit-dev@lists.webkit.org> wrote: > > On Tue, Apr 19, 2022 at 6:55 AM Yusuke Suzuki via webkit-dev < > webkit-dev@lists.webkit.org> wrote: > >> I think this is important. We are using commit message / ChangeLog as a >> document tied

Re: [webkit-dev] ChangeLog Deprecation Plans

On Mon, Apr 18, 2022 at 13:34 Ryosuke Niwa wrote: > > On Mon, Apr 18, 2022 at 08:30 Jonathan Bedard via webkit-dev < > webkit-dev@lists.webkit.org> wrote: > >> As we migrate WebKit from Subversion to git, I would like to migrate the >> project away from ChangeLogs. The reason for this is that

Re: [webkit-dev] ChangeLog Deprecation Plans

On Mon, Apr 18, 2022 at 8:30 AM Jonathan Bedard via webkit-dev < webkit-dev@lists.webkit.org> wrote: > As we migrate WebKit from Subversion to git, I would like to migrate the > project away from ChangeLogs. The reason for this is that ChangeLogs make > some of the features of git hard to use,

Re: [webkit-dev] GitHub Labels

On Thu, Mar 10, 2022 at 10:49 AM Jonathan Bedard via webkit-dev < webkit-dev@lists.webkit.org> wrote: > Hey folks, > > We’re in the final stage of bringing up support for GitHub pull-requests. > To support this effort, we’re starting to add labels to our project. We > intend to use labels as a

Re: [webkit-dev] Great function for Cocoa platform, bridge_cast

On Wed, Feb 16, 2022 at 6:13 AM Darin Adler wrote: > I think of it as following the same naming pattern as downcast<> or > static_cast<>, but you don’t have to specify a template argument since it > infers it for you. > I guess the closer analogy might be with const_cast, which does the "right

Re: [webkit-dev] Great function for Cocoa platform, bridge_cast

On Tue, Feb 15, 2022 at 9:44 AM Darin Adler via webkit-dev < webkit-dev@lists.webkit.org> wrote: > For those of you doing work with Objective-C on Cocoa platforms, I want to > draw your attention to a great new idiom. Back in October, David Kilzer > added bridge_cast, a type-safe set of functions

Re: [webkit-dev] OK to flatten WTF's header directory?

On Tue, Feb 1, 2022 at 12:30 PM Elliott Williams via webkit-dev < webkit-dev@lists.webkit.org> wrote: > I’m working on fixing some ambiguities in our Xcode projects to permit > adoption of Xcode’s new build system and better parallelize our builds. I > noticed that WTF’s headers

Re: [webkit-dev] WPT first test policy proposal

On Fri, Nov 19, 2021 at 1:06 PM Tim Nguyen via webkit-dev < webkit-dev@lists.webkit.org> wrote: > Hello everyone, > > I would like to start a discussion on a policy to enforce WPT usage as a > first choice, that would be enforced via check-webkit-style on Changelog > files. > > *Why use WPT?* > >

Re: [webkit-dev] Raw string literals

On Wed, Nov 17, 2021 at 2:59 PM Alex Christensen via webkit-dev < webkit-dev@lists.webkit.org> wrote: > Right now, our style checker disapproves of raw string literals, which > were introduced in C++11. It complains with this message: > > Multi-line string ("...") found. This lint script

Re: [webkit-dev] Fuzzy Reftest Plans, and Metadata Locations

On Thu, Oct 28, 2021 at 10:24 AM Sam Sneddon via webkit-dev < webkit-dev@lists.webkit.org> wrote: > As part of the ongoing work on GPU Process, we’re interested in adding > support for reftest fuzzy matching (i.e., allowing a certain amount of > tolerance when comparing the generated images). > >

Re: [webkit-dev] -Wreturn-type and -Wredundant-move reminders

On Tue, Oct 19, 2021 at 1:15 PM Michael Catanzaro via webkit-dev < webkit-dev@lists.webkit.org> wrote: > A reminder about this common idiom: > > switch (...) { > case Foo: > return ...; > case Bar: > return ...; > } > RELEASE_ASSERT_NOT_REACHED(); > > When it's intended that the code

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

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

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

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

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

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,

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

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

[webkit-dev] content-visibility (Was Re: Request For Position on CSS containment)

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

[webkit-dev] WeakHashMap

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

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

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

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

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

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

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

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

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

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

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

Re: [webkit-dev] Request for position: Aligning high-resolution timer granularity to cross-origin isolated capability

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

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

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

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

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

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

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 i

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

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

Re: [webkit-dev] Identifier Conversion Tooling

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

Re: [webkit-dev] Request for position: Critical-CH response header, part of Client Hints Reliability proposal

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

Re: [webkit-dev] Request for position: Critical-CH response header, part of Client Hints Reliability proposal

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

Re: [webkit-dev] Github mirror is not updating

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

Re: [webkit-dev] Request for position on Element Timing

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

Re: [webkit-dev] Request for position on Element Timing

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