[webkit-dev] Site isolation platform code

Hey everyone! I’ve been doing a bunch of work on site isolation recently, and I’ve been doing my best to make all my changes platform-independent so it just works for everyone. However, there are two places I could use some collaboration with other WebKit developers: 1. createNewPage in

Re: [webkit-dev] Proposal: Dropping MSVC support and use clang-cl exclusively on Windows

Herb, if you run “git log --grep MSVC” in a git checkout of WebKit, you’ll find many quirks we’ve done in our code to get it to compile with MSVC. Here are some of the most recent ones: https://commits.webkit.org/272595@main https://commits.webkit.org/271031@main Some warning differences in

[webkit-dev] maybe_unused vs UNUSED_PARAM

For many years we have used the UNUSED_PARAM macros, and we have almost 3000 of them. C++17 introduced [[maybe_unused]] for this purpose, and a few uses of it are starting to pop up in WebKit. Should we switch, should we transition, should we allow both, or should we just stick with

[webkit-dev] ENABLE macro placement between includes

Our coding style says to include config.h, then the primary header, then other headers. It does not say where to put any ENABLE macros in that list. We have about 1700 places where we follow this pattern: #include "config.h" #include "RemoteSampler.h" #if ENABLE(GPU_PROCESS) … #endif We have

[webkit-dev] Site isolation

The SiteIsolation feature is beginning to work in the simplest of cases, but I had to do some work in the Source/WebKit/Shared/RemoteLayerTree directory, which is platform-specific. Basically all the use of LayerHostingContextIdentifier in that directory needs an equivalent implementation for

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

If you are subtracting things that have not been verified to produce a positive value, then you hopefully aren’t dealing with values that can’t be negative, so this wouldn’t apply then. Forgetting to verify things is a bug in many places. I also think that a buffer offset of -1 is just about

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

If a value represents a size or a count or something that inherently cannot be negative, I strongly prefer using unsigned types. It reduces the number of places where we need to ask ourselves “what if it’s negative?” when it can never be negative, leading to more straightforward code that

[webkit-dev] GPU Process on all platforms eventually?

I remember several years ago there was a configuration to run WebKit2 without a network process, which was eventually removed. Given the current work to make the GPU Process on more platforms, is there an agreement that eventually (like in a year or two or three) all platforms running WebKit

Re: [webkit-dev] InjectedBundle deprecation

By the way, we have many of the same hurdles that you do and we don’t have good solutions to all the problems yet. > On Aug 16, 2022, at 6:46 PM, Alex Christensen via webkit-dev > wrote: > > Thanks for the analysis, Carlos! We are only at the beginning of this > journey, but

Re: [webkit-dev] InjectedBundle deprecation

e could expose this without using injected bundle at all. > > > User messages > - > > API to send custom messages between UI and web process. > > We might need this depending on how we migrate other features. > > > > > El dom, 14-08-202

Re: [webkit-dev] InjectedBundle deprecation

t; On Fri, Aug 12 2022 at 01:40:02 PM -0700, Alex Christensen via webkit-dev > wrote: >> Would the maintainers of the GTK and WPE APIs be willing to assist in >> migrating from those APIs and designing replacements in the UI process? > > Sigh... we'll need to dis

[webkit-dev] InjectedBundle deprecation

Hello WebKit developers! We are ramping up to do some serious work on Site Isolation which includes putting cross-origin iframes in a different process than the parent frame. Similar efforts have been done in other browser engines and some related work has already been done in WebKit, but not

Re: [webkit-dev] WebKit is now on GitHub

It may be worth considering doing one more commit with a message explaining that we moved the repository. I often find old repositories places without knowing where all the newest things are, and sometimes they have a last git commit pointing to the new repository location and I find that

Re: [webkit-dev] Request for position on COEP reflection

Seems reasonable. > On May 31, 2022, at 6:14 AM, Arthur Sonzogni via webkit-dev > wrote: > > Greetings webkit-dev, > > I am requesting your feedback about exposing: > ```js > self.crossOriginEmbedderPolicy; > ``` > It reflects the environment's crossOriginEmbedderPolicy's value. > > More

Re: [webkit-dev] Request for position on FedCM (was WebID)

We are generally supportive and interested in working together to make this coexist well with passkeys. > On Mar 10, 2022, at 3:42 PM, Sam Goto via webkit-dev > wrote: > > Hi WebKit-Dev, > > We've been working on a Web Platform API that allows users to login to > websites with their

Re: [webkit-dev] Using C++20 in WebKit

sen via webkit-dev > wrote: > > Ok. We won’t raise the minimum CMake version for all of WebKit right now > then, just on Windows when we start requiring VS2022. > >> On Jan 22, 2022, at 1:44 PM, Carlos Alberto Lopez Perez via webkit-dev >> wrote: >> >>

Re: [webkit-dev] Request for Position: Fetch Metadata

I’m interested in this work, and would be happy to review patches. I noticed that Chrome and Firefox both implement it and we don’t. Some of the implementation might be a little involved, so I’m happy to answer questions and point in the right direction when I can. I’m not thrilled that it

Re: [webkit-dev] Using C++20 in WebKit

Ok. We won’t raise the minimum CMake version for all of WebKit right now then, just on Windows when we start requiring VS2022. > On Jan 22, 2022, at 1:44 PM, Carlos Alberto Lopez Perez via webkit-dev > wrote: > > On 22/01/2022 01:51, Alex Christensen via webkit-dev wrote: &g

Re: [webkit-dev] Using C++20 in WebKit

.@apple.com>> wrote: >>> >>> We cannot use char8_t since it is not available in GCC 8.3.0 :) >>> >>> -Yusuke >>> >>>> On Jan 5, 2022, at 7:43 PM, Alex Christensen via webkit-dev >>>> mailto:webkit-dev@lists.webkit.org>&g

Re: [webkit-dev] Using C++20 in WebKit

uki wrote: > > We cannot use char8_t since it is not available in GCC 8.3.0 :) > > -Yusuke > >> On Jan 5, 2022, at 7:43 PM, Alex Christensen via webkit-dev >> mailto:webkit-dev@lists.webkit.org>> wrote: >> >> I, with great help from several of you,

Re: [webkit-dev] Using C++20 in WebKit

I, with great help from several of you, got https://bugs.webkit.org/show_bug.cgi?id=233963 compiling on all platforms, but several of the JSC bots are still red. I’m under the impression that they either need a clean build or I’ve missed

Re: [webkit-dev] Using C++20 in WebKit

itialized bit-field bugs. > > class A { > bool m_test : 1 : { false }; > }; > > -Yusuke > >> On Dec 6, 2021, at 12:52 PM, Alex Christensen via webkit-dev >> mailto:webkit-dev@lists.webkit.org>> wrote: >> >> In April 2019 in https://bugs.webki

[webkit-dev] Using C++20 in WebKit

In April 2019 in https://bugs.webkit.org/show_bug.cgi?id=197131 I increased WebKit’s minimum C++ language requirement from C++14 to C++17. In 2022 I’m planning to increase WebKit’s minimum C++ requirement from C++17 to C++20. Would April 2022

[webkit-dev] Raw string literals

Right now, our style checker disapproves of raw string literals, which were introduced in C++11. It complains with this message: Multi-line string ("...") found. This lint script doesn't do well with such strings, and may give bogus warnings. They're ugly and unnecessary, and you should use

[webkit-dev] Review request time limit

I just removed r? on all the bugs in http://webkit.org/pending-review that had requested review in 2018 or before and had been untouched since then. I imagine that did not interrupt anyone’s work. I was thinking of removing review requests on bugs that

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

Has anyone discussed how this can increase the precision of fingerprinting? It seems to reveal more information or more precise information about what else is going on on a user’s system. > On May 5, 2021, at 11:37 AM, Olivier Yiptong via webkit-dev > wrote: > > Hello WebKit devs, > > We'd

Re: [webkit-dev] Request for position: Removing 3DES from TLS

Thanks, David. I think we’re on the same page now. > On Apr 29, 2021, at 12:47 PM, David Benjamin wrote: > > Ah yes, that is confusing. Not quite. What's going on here is that we've > moved 3DES (and SHA-1 server signatures) under a fallback connection, so our > first connection won't

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

I don’t see the goal as “keep non-Unified-Source building” but rather “prevent unrelated build fixes when we add another file later”. Right now when we add a new file we often have to sprinkle includes, declarations, and other build fixes in files unrelated to the current change. If we had a

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

I’d be excited to have this. Those build failures have been bothering me ever since we started using unified builds. We would have a way to see more problems in our code that are currently hidden. > On Apr 28, 2021, at 11:45 PM, dpino via webkit-dev > wrote: > > Hi everyone, > > In Igalia

Re: [webkit-dev] Request for position: Removing 3DES from TLS

already removed support, how would one use it? I’ll admit I haven’t gone through all the possibilities of renegotiation that TLS has. > On Apr 28, 2021, at 8:21 AM, Alex Christensen via webkit-dev > wrote: > > Your measurement of 0.00% use in Chrome is exciting. > > Making

Re: [webkit-dev] Request for position: Removing 3DES from TLS

Your measurement of 0.00% use in Chrome is exciting. Making this change would almost certainly not be a change in WebKit but I’ve reached out to the people who manage our crypto code. > On Apr 28, 2021, at 7:14 AM, Michael Catanzaro via webkit-dev > wrote: > > > Looks like this change is

Re: [webkit-dev] Request for position: ALPS and ACCEPT_CH HTTP/2 and HTTP/3 frames

I’m also wondering why https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md#retry-limits says it should only retry GET requests. Is that just to avoid re-uploading large POST requests? > On Apr 6, 2021, at 10:02 AM, David Benjamin wrote: > > Hi Alex, thanks for the

Re: [webkit-dev] Request for position: ALPS and ACCEPT_CH HTTP/2 and HTTP/3 frames

I’m glad to see ALPS and bytes sent over the network used instead of additional reliance on state on the client. We don’t want to introduce a super cookie on the client, and we want to minimize breakage when a user agent decides to remove state to prevent tracking. I can’t say I’ve followed