[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

the maintainers of the GTK and WPE APIs be willing to assist in migrating from those APIs and designing replacements in the UI process? Alex Christensen ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo

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

Apple and Sony are finishing updating our build infrastructure to Visual Studio 2022, and we are considering requiring it to build WebKit starting next week. If anyone has a reason to delay further, please let me know on this list or directly. > On Jan 24, 2022, at 1:43 PM, Alex Christen

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

ote: > > It sounds nice! New CMake (3.21~) already supports VS 2022. > > -Yusuke > >> On Jan 21, 2022, at 10:36 AM, Alex Christensen > <mailto:achristen...@apple.com>> wrote: >> >> Related to the C++20 change, I’m working on moving the Visual Studio

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

x, thanks for the comments! Responses inline. > > On Mon, Apr 5, 2021 at 9:04 PM Alex Christensen <mailto:achristen...@apple.com>> wrote: > 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

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

Re: [webkit-dev] User Agent Client Hints

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

Re: [webkit-dev] Moving things around a bit in libsoup code

There were also a few lines of PLATFORM(PLAYSTATION) code I wasn’t sure what to do with, too. > On Aug 12, 2020, at 9:06 AM, Alex Christensen wrote: > > I’m preparing a fairly substantial change to the ownership of some important > objects in WebKit in https://bugs.webkit.org/sho

[webkit-dev] Moving things around a bit in libsoup code

I’m preparing a fairly substantial change to the ownership of some important objects in WebKit in https://bugs.webkit.org/show_bug.cgi?id=203547 and it has required some moving of settings from WebProcessPool to WebsiteDataStoreConfiguration.

Re: [webkit-dev] [webkit-changes] [264332] trunk/Source

I think it is still quite useful to fix non-unified builds. Otherwise adding a file usually involves many unrelated build fixes. > On Jul 14, 2020, at 5:25 PM, Fujii Hironori wrote: > > > > On Wed, Jul 15, 2020 at 6:32 AM Sam Weinig > wrote: > While I don’t want to

Re: [webkit-dev] Switching open source Debug bots to building and testing with configuration --force-opt=O3

It sounds to me like Mark’s suggestion does not lose anything. It’s just for JSC “Debug” which currently is not running because it’s too slow. If he called it “ReleaseWithAssert” it would make it more clear what is going on and we would all appreciate the additional information those bots

Re: [webkit-dev] Position on User-Agent Client Hints

Last I recall talking about this, we did not oppose to client hits header fields in general, just some specific ones that expose information we do not wish to expose to reduce fingerprinting information. For example, I think we do oppose adding Device-Memory because that currently cannot be

Re: [webkit-dev] Use of [[maybe_unused]]

I think that would still use 1 extra byte per object, which isn’t ideal but we may be ok with that. In general [[maybe_unused]] tells the compiler to stop telling us about potential speedups. Usually that speedup is just a value in a register or on the stack, which has a relatively small

Re: [webkit-dev] Use of [[maybe_unused]]

> On Jan 13, 2020, at 4:08 PM, Suzuki, Basuke wrote: > > `sessionID` is used in RELEASE_LOG_IF_ALLOWED() and we have empty > implementation of RELEASE_LOG() so that it's ended up with unused parameter > warning of sessionID. We can add UNUSED_PARAM(sessionID) in this case, but >

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

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,

[webkit-dev] WinCairo EWS

The WinCairo EWS bot has been in pretty sad shape for a while, providing no useful information and lots of false negatives. Could someone please fix it or remove it? See https://ews-build.webkit.org/#/builders/12/builds/5501 for an

Re: [webkit-dev] Introducing WTF::makeUnique and WTF::makeUniqueWithoutFastMallocCheck

This may be a tangent, but I wouldn’t mind replacing our use of std::unique_ptr with a smart pointer with "const T* get() const” and “T* get()” instead of std::unique_ptr’s “T* get() const”. I think that would help us write more const-correct code. > On Aug 23, 2019, at 9:10 AM, Darin Adler

[webkit-dev] John Wilander is a WebKit reviewer

I’m pleased to announce that John Wilander is now a WebKit reviewer. John has been working on WebKit for several years now, and has done a lot of work on Intelligent Tracking Prevention and other security-related features. Please join me in congratulating him! - Alex Christensen

Re: [webkit-dev] Which WTF headers still should be in C++11?

I hope so. Let’s give it a try. > On Jun 19, 2019, at 7:49 PM, Tim Horton wrote: > > This was a hopefully-shortlived internal complication. I think this is > already fixed and we could probably revert this change. Is that right, Alex? > >> On Jun 19, 2019, at 7:38 PM, Fujii Hironori >

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

I think they should be "under consideration" for https://webkit.org/status/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] IPC implementation help in haiku's webkit port

It sounds like your design requires work on the main thread to create a connection to another process which is causing a deadlock when the main thread is waiting for another reply. If I were working on this I would compare with an existing implementation to see what process and thread each

Re: [webkit-dev] C++17 is here. Should we use it?

If you have a minimum-requirements system that you want to keep building, put build infrastructure on build.webkit.org so we can see when things break. We plan to actively push to update requirements again in 2021. > On May 7, 2019, at 11:46 AM, Konstantin Tokarev wrote: > > > > 07.05.2019,

Re: [webkit-dev] C++17 is here. Should we use it?

I’m interpreting the lack of objection to mean there is no reason not to proceed with https://bugs.webkit.org/show_bug.cgi?id=197131 once I get everything working nicely. > On Apr 19, 2019, at 3:16 PM, Alex Christensen wrote: > > It’s always fun to reply to two year old emails. >

Re: [webkit-dev] C++17 is here. Should we use it?

It’s always fun to reply to two year old emails. I would like to have a plan to start using and requiring C++17 in WebKit. Based on my minimal research, I believe that DebianBuster is frozen but not yet released. Is there something we are still waiting for, or could we begin making the

Re: [webkit-dev] Style guideline on initializing non-POD types via member initialization

initializer to every RefCounted class. > On Mar 21, 2019, at 1:37 PM, Alex Christensen wrote: > > I object. I don’t find using { *this } in a header disorienting at all. I > think it’s better than adding many duplicate lines in each constructor and > risking forgetting one. I t

Re: [webkit-dev] Style guideline on initializing non-POD types via member initialization

I object. I don’t find using { *this } in a header disorienting at all. I think it’s better than adding many duplicate lines in each constructor and risking forgetting one. I think if we were to remove all the m_attributeOwnerProxy initializers in WebKit it would add lots of duplication

Re: [webkit-dev] Encoding and decoding ProcessID

WKProcessID is only used in 2 functions that are only used for testing, so it’s probably not too important as long as your tests work. Also, earlier you said "Our uint32_t is a signed integer.” If that’s true, you’re going to have some bigger problems. > On Feb 26, 2019, at 11:47 PM,

Re: [webkit-dev] Code Style: Opinion on returning void

I like it mostly for its brevity, but I also think it would be strange that changing a return type from bool to void or vice versa would require touching all its call sites. > On Feb 20, 2019, at 1:20 PM, Chris Dumez wrote: > >> >> On Feb 20, 2019, at 1:14 PM, Maciej Stachowiak >

Re: [webkit-dev] Code Style: Opinion on returning void

If you search for “return completionHandler” in WebKit you will find over a hundred instances. Most if not all of them return void. It means call the completion handler and return. I probably wrote most of them and obviously think it’s a fabulous idiom. > On Feb 7, 2019, at 2:32 PM,

[webkit-dev] libsoup and libcurl networking implementations

TL; DR could someone get my patch from https://bugs.webkit.org/show_bug.cgi?id=193580 working on Linux and Windows? As part of the quest to reduce process-global state especially in the NetworkProcess, I’m moving NetworkStorageSession ownership from a static map to a member variable of the

Re: [webkit-dev] AppleWin/WinCairo Resources

I don’t think there’s a fundamental reason why the resources and code can’t be moved. Just make sure everything still works > On Jan 7, 2019, at 10:45 AM, stephan.sz...@sony.com wrote: > > Hi, > > While working with (non-legacy) WebKit for WinCairo, we realized that we need > to support

Re: [webkit-dev] Reducing globals

It’s been three weeks. Is anyone maintaining the soup or curl loading code? > On Dec 3, 2018, at 1:03 PM, Alex Christensen wrote: > > > >> On Dec 3, 2018, at 12:55 PM, basuke.suz...@sony.com wrote: >> >> Alex, >> >> Got it. Curl port will catch up

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

onal will be left a bad state. > > I completely disagree with your assessment that this calls for the use of > std::exchange. > > > On Mon, Dec 17, 2018 at 3:55 PM Alex Christensen <mailto:achristen...@apple.com>> wrote: > Let me give a concrete example on why, even

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

oid std::optional and use an > optional class with well-defined behavior instead. > > Because I do not ❤️ security updates, I do ❤️ defined behavior, and so I ❤️ > this proposal. > > Geoff > >> On Dec 17, 2018, at 12:50 PM, Alex Christensen > <mail

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

behavior which works for us in most places. > On Dec 17, 2018, at 11:24 AM, Chris Dumez wrote: > > > >> On Dec 17, 2018, at 11:10 AM, Chris Dumez > <mailto:cdu...@apple.com>> wrote: >> >> >> >>> On Dec 17, 2018, at 10:27 AM, A

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

On Dec 14, 2018, at 1:37 PM, Chris Dumez >>> > wrote: >>> As far as I know, our convention in WebKit so far for our types has been that types getting moved-out are left in a valid “empty” state. This is not necessarily true. When we move out of an

Re: [webkit-dev] WebCorePrefix.h vs. config.h

CMake on Mac should not affect the decision here. I added that as a hack in http://trac.webkit.org/r172346 as part of an experimental project that isn’t being used by anyone. If we decide to resume CMake on Mac development and that has moved, we will find a better way to solve the same build

Re: [webkit-dev] Reducing globals

it? It tries. > > Curl Port uses default NetworkSession at everywhere so that it is almost same > with global NetworkProcess. We need to move forward to support NetworkSession > correctly. > > - > Basuke Suzuki > SONY PlayStation > > >> -

[webkit-dev] Reducing globals

I am embarking on a journey to reduce the number of global variables and singletons we use instead member variables on the proper objects. Feel free to join! Specifically, I’m looking into reducing the number of members in the NetworkProcessCreationParameters structure. Many of them need to

Re: [webkit-dev] unified sources build + forwarding headers that are copies

Our CMakeLists.txt have many instances of checks like “if (WIN32)” that assume that if you are running CMake on Windows then you are building for Windows. If you can make these checks work for you without breaking the existing Windows builds, then we would welcome such improvements.

Re: [webkit-dev] Move to NavigationClient

I’m not sure I understand your concern. Deciding policies is definitely part of navigation. Why would it be important to have the clients be separate objects? > On Oct 22, 2017, at 9:22 AM, Alfonso Guerra <hupernike...@gmail.com> wrote: > > > > On Oct 20, 2017 4:30

Re: [webkit-dev] Move to NavigationClient

on the NSURLAuthenticationChallenge.sender model, and modern WebKit is moving towards a completion handler model. > On Oct 20, 2017, at 1:45 PM, Michael Catanzaro <mcatanz...@igalia.com> wrote: > > On Fri, Oct 20, 2017 at 3:30 PM, Alex Christensen <achristen...@apple.com> > wrote: >> Right now we

Re: [webkit-dev] 'CSSPropertyNames.h': No such file or directory

That is supposed to be generated. Maybe something’s failing to generate that, or maybe the command isn’t getting called somehow. See https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/CMakeLists.txt#L3819 > On Oct 2, 2017, at 7:54 AM, Patrick Wright wrote: > >

Re: [webkit-dev] Running Safari on the simulator

When I want to use the public iOS SDK for WebKit on iOS, I refer to Dan’s blog post at https://webkit.org/blog/3457/building-webkit-for-ios-simulator/ We have bots using this configuration and they’re working successfully at

Re: [webkit-dev] Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)

> On Aug 29, 2017, at 5:54 PM, Sam Weinig wrote: > In a completely other direction, what does this mean for use of Xcode? Can we > still build from Xcode? Debug? CMake can generate Xcode files, so you can still develop and debug in Xcode. > On Aug 29, 2017, at 5:37 PM, Carlos

Re: [webkit-dev] Server Timing API

I think there’s interest. The tricky part would be getting access to the HTTP trailers with NSURLSession, libsoup, and if there’s interest libcurl. I can help out with the NSURLSession implementation if someone else gets it working with libsoup. > On Aug 16, 2017, at 7:51 AM, Vazac, Charles

Re: [webkit-dev] Looking to remove cygwin dependency for javascript tests for Windows ports

I think eventually running all tests on Windows without Cygwin would be a step in the right direction. > On Aug 2, 2017, at 9:53 AM, Szabo, Stephan (San Francisco) > wrote: > > Hi, > > As part of Sony's work on getting the jsconly build for Windows, we're also >

Re: [webkit-dev] Building WebKit for an iOS device

WebKit can be built and run on the iOS simulator by anyone with the public iOS SDK. I use https://webkit.org/blog/3457/building-webkit-for-ios-simulator/ when I forget how to do this. I guess WebKit can be built for device, but

Re: [webkit-dev] update GCC version?

I’ve been using MSVC 2017 on my WinCairo bot for a while now and it builds fine. It would take a bit to update our internal Windows infrastructure, but we should do that soon. ___ webkit-dev mailing list webkit-dev@lists.webkit.org

Re: [webkit-dev] Should we ever use std::function instead of WTF::Function?

13, 2017, at 12:31 PM, Chris Dumez <cdu...@apple.com> wrote: > > We already have BlockPtr for passing a Function as a lambda block. > > Chris Dumez > > On Jun 13, 2017, at 12:29 PM, Alex Christensen <achristen...@apple.com > <mailto:achristen...@apple.com>&

Re: [webkit-dev] Should we ever use std::function instead of WTF::Function?

std::function, c++ lambda, and objc blocks are all interchangeable. WTF::Functions cannot be used as objc blocks because the latter must be copyable. Until that changes or we stop using objc, we cannot completely eliminate std::function from WebKit.

Re: [webkit-dev] Idiom for functions with all return values in a switch case

I like switch statements without defaults when possible because if someone adds another enum value, it causes compiler warnings/errors and forces us to update all necessary code. ___ webkit-dev mailing list webkit-dev@lists.webkit.org

Re: [webkit-dev] !!Tests for equality comparison

I think we should definitely keep !pointerValue instead of pointerValue == nullptr for brevity and it makes sense to think “there’s not a pointer” when there is a pointer to null. I appreciate the reminder that pointers and integers are the same thing at the assembly level when I write

Re: [webkit-dev] Compile time increase over time

Thanks for the data, Carlos! This is a growing problem that is hurting productivity. We’ve discussed it a bit and haven’t done enough about it. Here are some of the ideas I’ve heard: 1) Reduce #includes by doing more forward declaring and less inlining. We would probably need link time

Re: [webkit-dev] Proposal: upstream the WPE port

This is exciting news, Zan! I’m happy to see innovative new uses of WebKit. What kind of groups hope to use this new port? What kind of groups hope to maintain this new port? Will it be beneficial to the WebKit community to have their cooperative work? I see having more groups motivated to

Re: [webkit-dev] EFL port?

> Konstantin Tokarev maintains a Qt port at https://github.com/annulen/webkit > - sounds like you could do something like > that. We have accepted the upstreaming of many patches from this repository into WebKit. That reduces Konstantin’s maintenance burden

Re: [webkit-dev] CSS Parse error in element.

I would start looking at HTMLLinkElement::parseAttribute. LinkHeader.cpp contains parsers for link headers, which are related. Yoav knows more about those. Those parsers ought to be united more. > On Feb 3, 2017, at 1:17 AM, Atul Sowani wrote: > > At present I am focusing

Re: [webkit-dev] WebCore/platform standalone library

Windows must also stay a static library. I can volunteer the currently-completely-experimental-anyways Mac CMake build to have PAL as a shared library. It would be nice if people had more of a reason to keep it working. > On Jan 18, 2017, at 1:23 PM, Michael Catanzaro

Re: [webkit-dev] WebCore/platform standalone library

If PAL were a shared library in a CMake build, then it wouldn’t build successfully if there were layering violations. I think we should do something like that to enforce good design, even if the Mac Xcode projects treat it as a static library or even just a part of WebCore.

Re: [webkit-dev] [webkit-reviewers] usage of auto

>> I’d love to see examples where using auto substantially hurts readability so >> we could debate them. I once saw a RefPtr changed to auto in some generated code where it was unclear what the return type was. For at least one generated instance the return type was Something* that needed a

Re: [webkit-dev] update GCC version?

> On Jan 9, 2017, at 7:39 AM, Carlos Alberto Lopez Perez > wrote: > > On 09/01/17 01:09, Michael Catanzaro wrote: >> On Sun, 2017-01-08 at 18:59 +0100, z...@falconsigh.net wrote: >>> For the record, GCC 5 has complete C++14 support. The current >>> requirement is 4.9, so the

Re: [webkit-dev] update GCC version?

> On Jan 7, 2017, at 11:39 AM, Konstantin Tokarev <annu...@yandex.ru> wrote: > > > > 07.01.2017, 22:30, "Alex Christensen" <achristen...@apple.com>: >> We are looking into using more C++14 features in WebKit, which would require >> i

[webkit-dev] update GCC version?

We are looking into using more C++14 features in WebKit, which would require increasing the minimum supported compiler versions. For example, Yusuke’s patch in https://bugs.webkit.org/show_bug.cgi?id=165093 compiles successfully in clang and I

Re: [webkit-dev] WebKit build failed

> On Dec 12, 2016, at 4:30 AM, Konstantin Tokarev wrote: > > > > 12.12.2016, 12:25, "Plamen Dimitrov" : >> Hi all, I am trying to build webkit wincairo 1) I've done 2, 3, 4, 5, 6, 7, >> 8, 9,10 and 13 from this list: >>

Re: [webkit-dev] WinCairo Maintainers

software that they built completely from source. > On Sep 26, 2016, at 11:54 AM, Konstantin Tokarev <annu...@yandex.ru> wrote: > > > > 26.09.2016, 21:46, "Alex Christensen" <achristen...@apple.com > <mailto:achristen...@apple.com>>: >> Rig

Re: [webkit-dev] WinCairo Maintainers

Right now https://github.com/peavo/WinCairoRequirements is the best maintained repository containing all the requirements, even if Per isn’t maintaining it any more. If you fork it and add fixes, then yours would become the best maintained

Re: [webkit-dev] [CMake] Bumping cmake_minimum_required

Updating to CMake 3.2 would also not cause us a problem. > On Sep 23, 2016, at 1:14 AM, Konstantin Tokarev <annu...@yandex.ru> wrote: > > > > 23.09.2016, 00:59, "Alex Christensen" <achristen...@apple.com > <mailto:achristen...@apple.com>>: >&

Re: [webkit-dev] [CMake] Bumping cmake_minimum_required

Requiring CMake 3.0 would not cause us a problem. > On Sep 21, 2016, at 5:06 AM, Michael Catanzaro wrote: > > On Wed, 2016-09-21 at 18:09 +0900, Fujii Hironori wrote: >> Ubuntu 14.04 has GCC 4.8 and build fails with a following error >> message. > > Hm that's a good

Re: [webkit-dev] Terminology for giving up ownership: take, release, move

I think “take" is a fine word to indicate that you are taking a value from a HashSet, just like “add" indicates you are adding to the set and remove indicates you are “removing" from the set. It’s true that in all these cases the caller is doing the thing, not the object, but it makes sense in

Re: [webkit-dev] Is someone going to fix Windows EWS?

I agree that it would be better to have one approach to copying forwarding headers, but there is a fundamental disagreement between the needs of the ports. Windows needs the entire header to be copied into the forwarding directory because some internal builds are built without the other

Re: [webkit-dev] Building Webkit on Windows

there are currently only 64bit available. That doesn't > matter at the moment, but when I am ready for our next build, I would ask > again if you don't mind. > > Thanks for your help! > > Thomas > > Am 25.02.2016 um 19:17 schrieb Alex Christensen: > That also applies to

Re: [webkit-dev] Building Webkit on Windows

r does this port still require > cygwin? > > Thomas > > Am 24.02.2016 um 20:32 schrieb Alex Christensen: >> Those instructions are out of date. The most up-to-date instructions about >> building on Windows are >> <http://trac.webkit.org/wiki/WindowsWithou

Re: [webkit-dev] Building Webkit on Windows

Those instructions are out of date. The most up-to-date instructions about building on Windows are http://trac.webkit.org/wiki/WindowsWithoutCygwin > On Feb 24, 2016, at 9:57 AM, Myles C. Maxfield wrote: > > What is the error you are seeing? > > On Feb 24, 2016, at 9:26

  1   2   >