Re: [webkit-dev] Deprecate webkit_web_page_get_main_frame?

[Alex Christensen via webkit-dev]

We definitely have a lot of work to do, but the plan is to make UI process 
driven replacements for all uses of the injected bundle.  It’s a large problem 
without a currently completely known solution, but we’re working on it and 
welcome collaboration from people working on webkit-based browsers on other 
platforms.  I’m pushing to deprecate things to discourage further adoption of 
things we are planning to remove, even before we have a complete replacement 
plan.

> On Jul 22, 2024, at 4:31 AM, Carlos Garcia Campos via webkit-dev 
>  wrote:
> 
> Hi Alex, 
> 
> sorry for the delay to reply, I was on vacation last week. 
> 
> So, we mainly use the frame object to get its javascript context, so
> what's the plan for that? I mean, it's only the api to get the main
> frame what's going to be deprecated or the frame object entirely? In
> most of the cases we get the frame from the script world on the window-
> object-cleared event, so we can probably deprecate get_main_frame(). I
> think it's only used in epiphany and evolution, but I would need to
> check how it's used there.
> 
> El vie, 12-07-2024 a las 16:19 -0600, Alex Christensen via webkit-dev
> escribió:
>> In https://github.com/WebKit/WebKit/pull/30763 I’m deprecating
>> injected bundle frame access interfaces as part of the site isolation
>> development.  Would glib API maintainers be willing to deprecate
>> webkit_web_page_get_main_frame to discourage its adoption and
>> indicate plans to remove it at some point in the future?  I’ve kept
>> the functionality for now because we are still moving off it, but at
>> some point that will be complete and it would be nice to remove
>> bundle frame access together.
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> -- 
> Carlos Garcia Campos
> ___
> 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] Deprecate webkit_web_page_get_main_frame?

[Alex Christensen via webkit-dev]

In https://github.com/WebKit/WebKit/pull/30763 I’m deprecating injected bundle 
frame access interfaces as part of the site isolation development.  Would glib 
API maintainers be willing to deprecate webkit_web_page_get_main_frame to 
discourage its adoption and indicate plans to remove it at some point in the 
future?  I’ve kept the functionality for now because we are still moving off 
it, but at some point that will be complete and it would be nice to remove 
bundle frame access together.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Site isolation platform code

[Alex Christensen via webkit-dev]

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 WebKitUIClient.cpp needs some hooking up of the 
API::PageConfiguration in a way I couldn’t figure out in the few minutes I 
looked at it.  This should be pretty straightforward to someone who knows the 
glib code better than I do.
2. We have a growing number of tests in LayoutTests/http/tests/site-isolation 
that exercise drawing code, which will take a significant amount of work to get 
implemented on non-Cocoa platforms.  A lot of changes are happening in this 
area right now with the adoption of Skia, and it would be great if it were done 
in a way that could support site isolation.

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

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

[Alex Christensen via webkit-dev]

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 https://commits.webkit.org/276799@main and 
https://commits.webkit.org/277563@main
The COMPILER(MSVC) addition necessary in https://commits.webkit.org/265366@main 
puzzled me a lot for a while, but I stopped looking into it.

And many more.  I don’t have a strong opinion about WebKit’s use of MSVC, but 
WebKit is certainly a wealth of real-world code that has worked around compiler 
differences over the last few decades that could be analyzed by the MSVC team 
if you’re interested.

> On May 2, 2024, at 3:49 PM, Olmstead, Don via webkit-dev 
>  wrote:
> 
> Hey Herb,
>  
> Not everyone whose embedding WebKit on Windows announces to us that they’re 
> using it so unsure if someone is still compiling using MSVC. All the 
> documentation we have points to clang-cl being the preferred way. The ones we 
> know of Bun, https://bun.sh/ , and Playwright, https://playwright.dev/ , have 
> switched to clang-cl.
>  
> I was personally keeping the dream alive and would compile out WebKit with 
> MSVC. WebKit on Windows doesn’t have the highest tier JITs because we don’t 
> have anyone working on it for Windows and the maintenance costs around MSVC 
> are centered around that. If MSVC had the functionality that helps the JSC 
> folks make the VM run fast we wouldn’t be in this situation. If that 
> functionality is added to the roadmap then we’d definitely reconsider at that 
> time.
>  
> Don
>  
> From: Herb Sutter  
> Sent: Thursday, May 2, 2024 1:28 PM
> To: Olmstead, Don ; 'Jean-Yves Avenard' 
> 
> Cc: 'WebKit-Dev Development' 
> Subject: RE: [webkit-dev] Proposal: Dropping MSVC support and use clang-cl 
> exclusively on Windows
>  
> Thank you, Jean-Yves and Don!
>  
> One followup: I don’t know WebKit well but was surprised that it was being 
> built with MSVC, and Yusuke mentioned Windows projects that build with 
> clang-cl instead. Are there known users/products who are building with WebKit 
> that are important not to break, so that we (Microsoft) should be thinking 
> about doing work so you can keep using MSVC, or is this really an unused 
> configuration that it makes sense to just drop?
>  
> Herb
>  
>  
> From: Olmstead, Don mailto:don.olmst...@sony.com>>
> Sent: Thursday, May 2, 2024 12:06 PM
> To: Jean-Yves Avenard  >; Herb Sutter  >
> Cc: WebKit-Dev Development (webkit-dev@lists.webkit.org 
> )  >
> Subject: RE: [webkit-dev] Proposal: Dropping MSVC support and use clang-cl 
> exclusively on Windows
>  
> Hi Herb
>  
> If you grep around the WebKit codebase for COMPILER(MSVC) there are a number 
> of workarounds hanging out. Some may have been fixed over time but the 
> workaround wasn’t removed.
>  
> Biggest issue was around the JIT and some other low level features the JSC 
> folks utilize that isn’t present in MSVC. The lion’s share of JSC development 
> is done using Clang and those working on it don’t have a Windows box handy so 
> we have seen the JIT break on Windows. Yusuke I’m sure has a list of feature 
> requests that would improve the quality of MSVC for people developing VMs.
>  
> MSVC has definitely caught some issues in the code and compiler mono-culture 
> isn’t great but realistically we don’t have the resources to keep MSVC up and 
> running.
>  
> Regards,
> Don
>  
> From: Jean-Yves Avenard via webkit-dev  >
> Sent: Wednesday, May 1, 2024 5:10 PM
> To: Herb Sutter mailto:herb.sut...@gmail.com>>
> Cc: Webkit Development List  >
> Subject: Re: [webkit-dev] Proposal: Dropping MSVC support and use clang-cl 
> exclusively on Windows
>  
> Hi
>  
> 
> On 2 May 2024, at 10:07 am, Herb Sutter via webkit-dev 
> mailto:webkit-dev@lists.webkit.org>> wrote:
>  
>  
> We’ve had full C++20 including concepts for a couple of years so I wasn’t 
> sure what problem you were running into… are you encountering bugs in those 
> features? or you can’t turn on /std:c++20 for some reason? or are you using 
> an older pre-concepts (pre-VS2022 17.0) compiler?
>  
> Thanks for any feedback you have time to share.
>  
> Herb
>  
>  
> We’ve had issues where some use of concepts made the latest MSVC compiler 
> crash
> See https://searchfox.org/wubkat/source/Source/WTF/wtf/TypeTraits.h#145-172
>  
> See https://bugs.webkit.org/show_bug.cgi?id=261598
>  
> Jean-Yves
> ___
> 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-dev] maybe_unused vs UNUSED_PARAM

[Alex Christensen via webkit-dev]

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 UNUSED_PARAM?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] ENABLE macro placement between includes

[Alex Christensen via webkit-dev]

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 about 350 places where we follow this pattern:

#include "config.h"

#if ENABLE(WEBGL)

#include "WebGLUniformLocation.h"
…
#endif

The less common pattern has the advantage of not needing to search the 
directory where the header is if the feature is not enabled, but I like the 
more common pattern more and I think it matches our style guidelines better.  
Should we specify one or the other, or should we not specify this in our coding 
style?___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Site isolation

[Alex Christensen via webkit-dev]

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 other graphics implementations, like in the 
CoordinatedGraphics directories.  There is one layout test in 
LayoutTests/http/tests/site-isolation/basic-iframe.html that is currently 
skipped on all non-Cocoa platforms.

Is someone willing to collaborate to design and implement the feature in 
non-Cocoa ports?  We are in the early stages of the project and have a long way 
to go, so I imagine things will continue to come up, like deciding how to 
implement event handling and other platform dependent features.

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

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

[Alex Christensen via webkit-dev]

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 as bad as a buffer 
offset of 4294967295.

> On Jan 26, 2023, at 6:44 PM, Simon Fraser via webkit-dev 
>  wrote:
> 
> Late to the party but….
> 
> Avoiding unsigned is usually recommended to avoid inadvertent underflow:
> 
> unsigned big = 200;
> unsigned small = 100;
> auto result = small - big; // underflow
> 
> This is particularly bad when doing math on buffer offsets and sizes, and can 
> result in OOB bugs. I believe Apple’s media frameworks code has a “no 
> unsigned usage” rule because of that. I’m surprised that no-one has raised it 
> in this discussion.
> 
> Simon
> 
>> On Jan 24, 2023, at 2:00 AM, Myles Maxfield via webkit-dev 
>>  wrote:
>> 
>> Hello!
>> 
>> 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 
>> not in an attempt to ensure values are positive. Some talks by people on the 
>> C++ standards committee (e.g., Herb Sutter) recommend against using unsigned 
>> types simply because the value is expected to by positive.
>> 
>> Should we be avoiding unsigneds for these purposes? WebKit uses unsigneds 
>> all over the place, and I’m assuming a fair many of them are there to 
>> indicate that negative values are avoided. The C++ recommendation goes 
>> against my intuition that the type is there for clarity, to indicate 
>> expectations about the meaning and behavior of its value. But if it’s 
>> standard practice to just use int instead, perhaps we should update the 
>> style guide?
>> 
>> What do you think?
>> 
>> —Myles
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Alex Christensen via webkit-dev]

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 doesn’t have to 
handle impossible cases.  It also eliminates the possibility of malicious 
content somehow incrementing a signed 32 bit integer past its maximum value and 
executing code with unexpected negative values used in signed comparison 
operations.

> On Jan 24, 2023, at 11:44 AM, Ryosuke Niwa via webkit-dev 
>  wrote:
> 
> 
>> 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 
>> not in an attempt to ensure values are positive. Some talks by people on the 
>> C++ standards committee (e.g., Herb Sutter) recommend against using unsigned 
>> types simply because the value is expected to by positive.
>> 
>> Should we be avoiding unsigneds for these purposes? WebKit uses unsigneds 
>> all over the place, and I’m assuming a fair many of them are there to 
>> indicate that negative values are avoided. The C++ recommendation goes 
>> against my intuition that the type is there for clarity, to indicate 
>> expectations about the meaning and behavior of its value. But if it’s 
>> standard practice to just use int instead, perhaps we should update the 
>> style guide?
>> 
>> What do you think?
> 
> I don’t think we should change our coding style guidelines just because C++ 
> core guideline says something.
> 
> - R. Niwa
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Alex Christensen via webkit-dev]

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 should have a GPU 
Process?  It is a considerable security improvement, a lot of work is being 
done to support it, and I imagine there will come a point when we don’t want to 
support all the code and abstractions needed to have a configuration with a GPU 
Process and a configuration without, but to get there we would need consensus 
of some sort.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] InjectedBundle deprecation

[Alex Christensen via webkit-dev]

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 I’m glad we’ve begun it together.  There will be many bumps 
> along the way, but I’m confident it’ll be worth it.
> 
>> On Aug 16, 2022, at 6:35 AM, Carlos Garcia Campos via webkit-dev 
>>  wrote:
>> 
>> Here is the list of features in GTK and WPE ports exposed using
>> injected bundle.
>> 
>> JavaScript extensions
>> -
>> 
>> Used by apps to expose current JavaScript APIs using the JSC API. This
>> includes:
>> 
>> - WebKitScriptWorld: The window-object-cleared signal is the initial
>> point for injecting JavaScript. It allows allows to create isolated
>> worlds.
>> - WebKitFrame: To get the JS context. It also allows to get the JS
>> value for a node handle.
>> - WebKitDOMNode: To associate a DOM node to its JSCValue.
>> 
>> We still need a way to run code in the JavaScript process.
>> 
>> 
>> Requests handling
>> -
>> 
>> This is send-request signal to expose willSendRequest. It allows to
>> modify every request before it's sent or even cancel it. This was used
>> by epiphany to implement the adblocker before the content filter api
>> existed. Other apps still use it to modify the uri of requests before
>> being sent.
>> 
>> This is not easy to migrate because going to the UI process for every
>> load would be too much.
>> 
>> 
>> Context Menu
>> 
>> 
>> This is the same API we have in the UI process to provide more
>> information and be able to build the menu based on the DOM node. For
>> example epiphany uses it to determine if the context menu was opened
>> over a node that is editable or a password input field. It's also used
>> to get the currently selected text. All that info is set as user data
>> that is passed to the context menu signal in the UI process.
>> 
>> I think nowadays most of this information is already in
>> WebHitTestResultData and we can add whatever is missing, so this should
>> be easy to migrate.
>> 
>> 
>> Form autofilling
>> 
>> 
>> We expose a signal to notify when form controls are associated to a
>> frame. This is used by epiphany to auto fill password fields.
>> 
>> This could probably be moved to the UI process or implemented entirely
>> using JavaScript.
>> 
>> 
>> Password manager
>> 
>> 
>> Related with previous one we have a signal to notify when a form is
>> going to be submitted. Used by epiphany to remember the passwords.
>> 
>> This could probably be moved to the UI process or implemented entirely
>> using JavaScript.
>> 
>> 
>> Console messages
>> 
>> 
>> API to notify the user when a console message is sent.
>> 
>> This could be easily moved to the UI process, but I think nobody is
>> currently using this API so it can be just removed instead.
>> 
>> 
>> Editor
>> --
>> 
>> Expose the selection changed signal.
>> 
>> This could be implemented with JavaScript. I'm not sure this is
>> currently used by any application.
>> 
>> 
>> Resources load
>> --
>> 
>> This is internal implementation used to implement the UI process API
>> for resources.
>> 
>> There's APIResourceLoadClient now, so we could probably switch to use
>> that or add whatever is missing.
>> 
>> 
>> Page snapshot
>> -
>> 
>> This is also internal implementation for the UI process API for page
>> snapshots.
>> 
>> We 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-2022 a las 09:25 +0200, Carlos Garcia Campos via webkit-
>> dev escribió:
>>> El vie, 12-08-2022 a las 13:40 -0700, Alex Christensen via webkit-dev
>>> escribió:
>>>> Hello WebKit developers! We are ramping up to do some serious work
>>>> on
>>>> Site Isolation which includes putting cross-origin iframes in a
>>>> differe

Re: [webkit-dev] InjectedBundle deprecation

[Alex Christensen via webkit-dev]

Thanks for the analysis, Carlos!  We are only at the beginning of this journey, 
but I’m glad we’ve begun it together.  There will be many bumps along the way, 
but I’m confident it’ll be worth it.

> On Aug 16, 2022, at 6:35 AM, Carlos Garcia Campos via webkit-dev 
>  wrote:
> 
> Here is the list of features in GTK and WPE ports exposed using
> injected bundle.
> 
> JavaScript extensions
> -
> 
> Used by apps to expose current JavaScript APIs using the JSC API. This
> includes:
> 
> - WebKitScriptWorld: The window-object-cleared signal is the initial
> point for injecting JavaScript. It allows allows to create isolated
> worlds.
> - WebKitFrame: To get the JS context. It also allows to get the JS
> value for a node handle.
> - WebKitDOMNode: To associate a DOM node to its JSCValue.
> 
> We still need a way to run code in the JavaScript process.
> 
> 
> Requests handling
> -
> 
> This is send-request signal to expose willSendRequest. It allows to
> modify every request before it's sent or even cancel it. This was used
> by epiphany to implement the adblocker before the content filter api
> existed. Other apps still use it to modify the uri of requests before
> being sent.
> 
> This is not easy to migrate because going to the UI process for every
> load would be too much.
> 
> 
> Context Menu
> 
> 
> This is the same API we have in the UI process to provide more
> information and be able to build the menu based on the DOM node. For
> example epiphany uses it to determine if the context menu was opened
> over a node that is editable or a password input field. It's also used
> to get the currently selected text. All that info is set as user data
> that is passed to the context menu signal in the UI process.
> 
> I think nowadays most of this information is already in
> WebHitTestResultData and we can add whatever is missing, so this should
> be easy to migrate.
> 
> 
> Form autofilling
> 
> 
> We expose a signal to notify when form controls are associated to a
> frame. This is used by epiphany to auto fill password fields.
> 
> This could probably be moved to the UI process or implemented entirely
> using JavaScript.
> 
> 
> Password manager
> 
> 
> Related with previous one we have a signal to notify when a form is
> going to be submitted. Used by epiphany to remember the passwords.
> 
> This could probably be moved to the UI process or implemented entirely
> using JavaScript.
> 
> 
> Console messages
> 
> 
> API to notify the user when a console message is sent.
> 
> This could be easily moved to the UI process, but I think nobody is
> currently using this API so it can be just removed instead.
> 
> 
> Editor
> --
> 
> Expose the selection changed signal.
> 
> This could be implemented with JavaScript. I'm not sure this is
> currently used by any application.
> 
> 
> Resources load
> --
> 
> This is internal implementation used to implement the UI process API
> for resources.
> 
> There's APIResourceLoadClient now, so we could probably switch to use
> that or add whatever is missing.
> 
> 
> Page snapshot
> -
> 
> This is also internal implementation for the UI process API for page
> snapshots.
> 
> We 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-2022 a las 09:25 +0200, Carlos Garcia Campos via webkit-
> dev escribió:
>> El vie, 12-08-2022 a las 13:40 -0700, Alex Christensen via webkit-dev
>> escribió:
>>> 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 enough.
>>> 
>>> This will do strange things to the InjectedBundle APIs, which have
>>> fundamental assumptions that the whole DOM is in one process and
>>> that
>>> communication only happens with one process at a time. We have
>>> never
>>> exposed InjectedBundle APIs as public API, but some other
>>> distributors of WebKit have. As we make progress on this project,
>>> we
>>> anticipate that anything in
>>> Source/WebKit/WebP

Re: [webkit-dev] InjectedBundle deprecation

[Alex Christensen via webkit-dev]

I agree that this will be quite disruptive.  I think it would be advantageous 
to deprecate the InjectedBundle APIs asap.  At least for the next year (and 
likely a little longer) we will need to keep a working configuration without 
site isolation.  In the very long term we probably don’t want to keep them 
working, but I’m not sure exactly what that time frame looks like right now.  
I’m not saying it’ll be a sudden change, but it is going to be a big change 
with big consequences that we need to start preparing for now.

> On Aug 12, 2022, at 2:29 PM, Michael Catanzaro  wrote:
> 
> 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 discuss what to do. Unfortunately, these are public 
> APIs and this will be extremely disruptive. If it's needed for site 
> isolation, I don't see that we have much choice. But if we remove these APIs, 
> Linux distros will get stranded on the last version of WebKit that still 
> supports them and will be unable to take our further updates.
> 
> Deprecation is a lot easier than removal. If we can keep deprecated APIs 
> working and just disable site isolation when they're used, that would be much 
> less disruptive.
> 
> Michael
> 
> 

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

[webkit-dev] InjectedBundle deprecation

[Alex Christensen via webkit-dev]

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 enough.

This will do strange things to the InjectedBundle APIs, which have fundamental 
assumptions that the whole DOM is in one process and that communication only 
happens with one process at a time. We have never exposed InjectedBundle APIs 
as public API, but some other distributors of WebKit have. As we make progress 
on this project, we anticipate that anything in 
Source/WebKit/WebProcess/InjectedBundle/API is subject to deprecation and 
removal.  This will also allow us to tighten the sandbox on the web process, 
resolve security and performance issues, and have cleaner code.

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?

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

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

[Alex Christensen via webkit-dev]

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 quite helpful.  
That may cause tooling problems and it has been quite well communicated that we 
are moving to GitHub, so there are also reasons not to.

> On Jun 23, 2022, at 3:24 PM, Michael Catanzaro via webkit-dev 
>  wrote:
> 
> On Thu, Jun 23 2022 at 03:21:59 PM -0700, Jonathan Bedard  
> wrote:
>> I´m aware of the WebKitGTK branches, please reach out about the WPE ones, 
>> I´m not sure which ones those are.
> 
> The WPE releases actually use the WebKitGTK branches! They are shared 
> branches. I suppose that is pretty confusing, but naming things is hard.
> 
> Sounds like you already have this under control.
> 
> Michael
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Alex Christensen via webkit-dev]

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 details on:
> https://github.com/ArthurSonzogni/coep-reflection 
> 
> Thanks
> Arthur @arthursonzogni
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Alex Christensen via webkit-dev]

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 federated accounts in a privacy preserving manner. 
> 
> We've been calling it FedCM (was WebID) and we would like to hear what you 
> think!
> 
> Here is our explainer, spec and a brief introduction:
> 
> explainer 
> specification 
> TPAC2021  
> presentation (video introduction)
> 
> WDYT?
> 
> One specific area of coordination is its relationship to the Login Status API 
> and the Storage Access API. We'd be happy to learn more from you about both 
> of these APIs and how they relate to FedCM, but just as a starting point, 
> here [1 
> ,
>  2 
> ]
>  is our interpretation of each.
> 
> Looking forward to hearing from you,
> 
> Sam
> Various other past reviews:
> 
> WebID? 
> WICG thread 
> 
> Federation and Browsers Workshop 
> 
> Intent To Prototype 
> 
> FedID CG 
> early TAG review 
> Ready For Trial 
> 
> spec TAG review 
> Mozilla's Standards Position 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Alex Christensen via webkit-dev]

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 Christensen 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:
>> 
>> On 22/01/2022 01:51, Alex Christensen via webkit-dev wrote:
>>> While we’re updating things, is there any objection to updating the
>>> minimum version of CMake required?  Right now it is 3.12, which was
>>> released in 2018.  Does anyone have any limitations we should consider
>>> when picking a new minimum version?
>>> 
>> 
>> Yes.
>> 
>> CMake is one of the core dependencies for GTK and WPE ports, so the
>> policy of dependencies applies [1]
>> 
>> In practical terms that means that we should support the version of
>> CMake shipped by Debian 10, which is CMake 3.13 until at least 2022-08-14.
>> 
>> However, If the purpose of raising the version is to take advantage of
>> the new Visual Studio generator then I don't think raising the minimum
>> version is needed.
>> 
>> As far as I know you can take advantage of newer CMake features (like
>> support for a newer generator) without needing to raise the minimum
>> version required.
>> 
>> So if you have a newer version of CMake you can simply pass the flag
>> -G"Visual Studio 17 2022" (or similar). Raising the minimum version
>> required of CMake is not needed to use a newer CMake generator, using it
>> can be made optional for those that want (and can) use it.
>> 
>> 
>> [1] https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Alex Christensen via webkit-dev]

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 adds more bytes to each request, especially when using 
HTTP 1.1 where headers are not compressed.  The day may also come when we need 
to either omit the metadata or send incorrect metadata for privacy or security 
reasons, but I haven’t thought it through well enough yet and I’m not aware of 
cases where that would be necessary right now.

> On Feb 16, 2022, at 12:43 PM, Patrick Griffis via webkit-dev 
>  wrote:
> 
> On 2022-02-11 16:15, Patrick Griffis via webkit-dev wrote:
>> However Sec-Fetch-User I believe will require more
>> significant changes that will have to be exposed to each port. It
>> requires knowing if a request was initiated by a user, exact details are
>> specified here[2], which I think will require integration at the
>> Safari/WebKitGTK/etc layers.
> 
> Looking more into this Firefox takes a more heuristic approach to
> figuring this out (was there a referrer and what is the request type)
> and if that approach works out for WebKit it wouldn't require any
> port-specific changes. Chromium itself does just ask the `ui` layer what
> type of "transition" caused the request which is more in-line with the
> spec.
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Alex Christensen via webkit-dev]

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:
>> While we’re updating things, is there any objection to updating the
>> minimum version of CMake required?  Right now it is 3.12, which was
>> released in 2018.  Does anyone have any limitations we should consider
>> when picking a new minimum version?
>> 
> 
> Yes.
> 
> CMake is one of the core dependencies for GTK and WPE ports, so the
> policy of dependencies applies [1]
> 
> In practical terms that means that we should support the version of
> CMake shipped by Debian 10, which is CMake 3.13 until at least 2022-08-14.
> 
> However, If the purpose of raising the version is to take advantage of
> the new Visual Studio generator then I don't think raising the minimum
> version is needed.
> 
> As far as I know you can take advantage of newer CMake features (like
> support for a newer generator) without needing to raise the minimum
> version required.
> 
> So if you have a newer version of CMake you can simply pass the flag
> -G"Visual Studio 17 2022" (or similar). Raising the minimum version
> required of CMake is not needed to use a newer CMake generator, using it
> can be made optional for those that want (and can) use it.
> 
> 
> [1] https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Alex Christensen via webkit-dev]

While we’re updating things, is there any objection to updating the minimum 
version of CMake required?  Right now it is 3.12, which was released in 2018.  
Does anyone have any limitations we should consider when picking a new minimum 
version?

> On Jan 21, 2022, at 4:51 PM, Yusuke Suzuki  wrote:
> 
> 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 build 
>> to Visual Studio 2022.  I’ve informed several involved parties directly, but 
>> now I’ve informed everyone.  If anyone has a reason not to move to VS2022, 
>> please let me know.
>> 
>>> On Jan 6, 2022, at 2:11 AM, Yusuke Suzuki >> <mailto:ysuz...@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>> wrote:
>>>> 
>>>> I, with great help from several of you, got 
>>>> https://bugs.webkit.org/show_bug.cgi?id=233963 
>>>> <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 something.  
>>>> Could a JSC bot maintainer look into it?
>>>> 
>>>>> On Dec 7, 2021, at 2:38 PM, Carlos Alberto Lopez Perez via webkit-dev 
>>>>> mailto:webkit-dev@lists.webkit.org>> wrote:
>>>>> 
>>>>> On 06/12/2021 22:36, Yusuke Suzuki via webkit-dev wrote:
>>>>>> I recently upgraded GCC requirement to 8.3.0 based
>>>>>> on https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement 
>>>>>> <https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement>
>>>>>> <https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement 
>>>>>> <https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement>> 
>>>>>> (https://trac.webkit.org/changeset/283348/webkit 
>>>>>> <https://trac.webkit.org/changeset/283348/webkit>
>>>>>> <https://trac.webkit.org/changeset/283348/webkit 
>>>>>> <https://trac.webkit.org/changeset/283348/webkit>>)
>>>>>> As a result, we can use some of C++20 features.
>>>>>> I wonder if we can flip C++20 now. While some of C++20 features cannot
>>>>>> be used since GCC 8.3.0 does not support, but some of features can be
>>>>>> used, and it is super useful.
>>>>> 
>>>>> From the PoV of WebKitGTK I think it is Ok to enable now the building
>>>>> with C++-20 support and to start using the C++-20 features already
>>>>> supported by GCC 8.3.0
>>>>> 
>>>>> Check here: https://gcc.gnu.org/projects/cxx-status.html 
>>>>> <https://gcc.gnu.org/projects/cxx-status.html> which C++-20
>>>>> features are supported by GCC 8
>>>>> 
>>>>> Before using them I think it would be a good idea to double-check if
>>>>> those are also supported by the minimum version of Clang that we want to
>>>>> support.
>>>>> And maybe also to check if those are supported by MS Visual C++ ?
>>>>> I say maybe because I'm not sure if we support this compiler.
>>>>> ___
>>>>> webkit-dev mailing list
>>>>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>>>>> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
>>>> 
>>>> ___
>>>> webkit-dev mailing list
>>>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>>>> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
>>> 
>> 
> 

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

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

[Alex Christensen via webkit-dev]

Related to the C++20 change, I’m working on moving the Visual Studio build to 
Visual Studio 2022.  I’ve informed several involved parties directly, but now 
I’ve informed everyone.  If anyone has a reason not to move to VS2022, please 
let me know.

> On Jan 6, 2022, at 2:11 AM, Yusuke Suzuki  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, got 
>> https://bugs.webkit.org/show_bug.cgi?id=233963 
>> <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 something.  Could a JSC bot 
>> maintainer look into it?
>> 
>>> On Dec 7, 2021, at 2:38 PM, Carlos Alberto Lopez Perez via webkit-dev 
>>> mailto:webkit-dev@lists.webkit.org>> wrote:
>>> 
>>> On 06/12/2021 22:36, Yusuke Suzuki via webkit-dev wrote:
>>>> I recently upgraded GCC requirement to 8.3.0 based
>>>> on https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement 
>>>> <https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement>
>>>> <https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement 
>>>> <https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement>> 
>>>> (https://trac.webkit.org/changeset/283348/webkit 
>>>> <https://trac.webkit.org/changeset/283348/webkit>
>>>> <https://trac.webkit.org/changeset/283348/webkit 
>>>> <https://trac.webkit.org/changeset/283348/webkit>>)
>>>> As a result, we can use some of C++20 features.
>>>> I wonder if we can flip C++20 now. While some of C++20 features cannot
>>>> be used since GCC 8.3.0 does not support, but some of features can be
>>>> used, and it is super useful.
>>> 
>>> From the PoV of WebKitGTK I think it is Ok to enable now the building
>>> with C++-20 support and to start using the C++-20 features already
>>> supported by GCC 8.3.0
>>> 
>>> Check here: https://gcc.gnu.org/projects/cxx-status.html 
>>> <https://gcc.gnu.org/projects/cxx-status.html> which C++-20
>>> features are supported by GCC 8
>>> 
>>> Before using them I think it would be a good idea to double-check if
>>> those are also supported by the minimum version of Clang that we want to
>>> support.
>>> And maybe also to check if those are supported by MS Visual C++ ?
>>> I say maybe because I'm not sure if we support this compiler.
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>>> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 

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

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

[Alex Christensen via webkit-dev]

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 something.  Could a JSC bot maintainer 
look into it?

> On Dec 7, 2021, at 2:38 PM, Carlos Alberto Lopez Perez via webkit-dev 
>  wrote:
> 
> On 06/12/2021 22:36, Yusuke Suzuki via webkit-dev wrote:
>> I recently upgraded GCC requirement to 8.3.0 based
>> on https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement
>>  
>> (https://trac.webkit.org/changeset/283348/webkit
>> )
>> As a result, we can use some of C++20 features.
>> I wonder if we can flip C++20 now. While some of C++20 features cannot
>> be used since GCC 8.3.0 does not support, but some of features can be
>> used, and it is super useful.
> 
> From the PoV of WebKitGTK I think it is Ok to enable now the building
> with C++-20 support and to start using the C++-20 features already
> supported by GCC 8.3.0
> 
> Check here: https://gcc.gnu.org/projects/cxx-status.html which C++-20
> features are supported by GCC 8
> 
> Before using them I think it would be a good idea to double-check if
> those are also supported by the minimum version of Clang that we want to
> support.
> And maybe also to check if those are supported by MS Visual C++ ?
> I say maybe because I'm not sure if we support this compiler.
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Alex Christensen via webkit-dev]

I’m also excited about using coroutines in WebKit.  If there is already a GCC 
requirement for using a compiler that supports C++20, is there a reason not to 
switch from C++17 to C++20 later in 2021?

> On Dec 6, 2021, at 2:36 PM, Yusuke Suzuki  wrote:
> 
> I recently upgraded GCC requirement to 8.3.0 based on 
> https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement 
> <https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement> 
> (https://trac.webkit.org/changeset/283348/webkit 
> <https://trac.webkit.org/changeset/283348/webkit>)
> As a result, we can use some of C++20 features.
> I wonder if we can flip C++20 now. While some of C++20 features cannot be 
> used since GCC 8.3.0 does not support, but some of features can be used, and 
> it is super useful.
> One of the good features is initializer for bit-fields, which can avoid 
> uninitialized 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.webkit.org/show_bug.cgi?id=197131 
>> <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 be a good time to do that?
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto: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] Using C++20 in WebKit

[Alex Christensen via webkit-dev]

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 be a 
good time to do that?___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Request for Position: EditContext

[Alex Keng via webkit-dev]

Hi! I'd like to get WebKit's position on EditContext which allows authors to 
more directly participate in the text input process.

Here is the spec: https://w3c.github.io/editing/docs/EditContext/
And the explainer: editing/explainer.md at gh-pages * w3c/editing 
(github.com)<https://github.com/w3c/editing/blob/gh-pages/docs/EditContext/explainer.md>
Also a 2 min quick intro video: 
https://w3c.github.io/editing/docs/EditContext/EditContext_tpac2021.mp4

Thanks!
Alex
Microsoft Edge


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

[webkit-dev] Raw string literals

[Alex Christensen via webkit-dev]

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 concatenation instead".

https://webkit.org/code-style-guidelines/ 
 says nothing on the subject.  I 
find them quite useful and nice, especially with strings that contain lots of 
quotation marks that would otherwise need escaping.  Would anyone oppose to my 
changing our style checker to allow them if I ever get around to it?

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

[webkit-dev] Review request time limit

[Alex Christensen via webkit-dev]

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 hadn’t been 
updated in one full year to maintain the usefulness of the review queue.  Does 
anyone have any strong opinions that that is too much time or too little time?  
Most reviews are done in a few days or weeks, but occasionally something useful 
sits in the review queue for a few months.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Alex Christensen via webkit-dev]

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

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

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

[Alex Christensen via webkit-dev]

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 advertise them, but on error the second one will. This 
> means that, for compatibility and security purposes, we do support 3DES. But 
> when you look at the ClientHellos, it'll look like we don't.
> https://groups.google.com/a/chromium.org/g/blink-dev/c/yaJcs4p9LNI/m/haZWzX-UBwAJ
>  
> 
Ah, yes.  Now I see that when connecting to https://3des.badssl.com/ Chrome 
will send a retry client hello with TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

> (By the way, it looks like, on my machine, Safari on Big Sur also supports 
> TLS_RSA_WITH_3DES_EDE_CBC_SHA.)
You are correct.  I overlooked that one, which upon closer inspection was right 
next to the other ones the whole time.

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

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

[Alex Christensen via webkit-dev]

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 bot building 
without unification we would be informed at the time we write the problematic 
code.

> On Apr 29, 2021, at 9:55 AM, Darin Adler via webkit-dev 
>  wrote:
> 
> Given the issue is that there are people that are using non-Unified-Source 
> building for their development, the best fix is to add post-commit and EWS 
> builders for one of those platforms. I do not support the idea of adding an 
> additional builder just to “keep non-Unified-Source building” if no 
> actively-supported platform is not choosing that build style.
> 
> Specifically, if Sony people are most affected by this, I suggest we find a 
> way to add Sony PlayStation post-commit and EWS builders.
> 
> I am not convinced that we should add some kind of abstract “correct 
> compilation” that is a separate builder.
> 
> — Darin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Alex Christensen via webkit-dev]

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 we have been discussing the need of deploying a new builder
> which builds WebKit using non-unified sources, and we know that at least
> the folks at Sony are also in favor.
> 
> One side effect of Unified Source building is that it hides compilation
> errors. The kinds of errors that usually get hidden by unified builds
> are missing headers inclusions and missing definitions of functions
> declared inline; the latter being tricky to debug because it results in
> mysterious linker errors. This is caused by unified builds stashing
> several .cpp files together for compilation, so the definitions and
> header inclusions done in one “leak” into the others. As for missing
> header inclusion errors, a source file might include a header definition
> as a co-lateral effect of being stashed together with another file that
> indeed includes the missing header.
> 
> These hidden compilation errors may arise later at some point if unified
> source files are stashed together in a different manner.
> 
> The current situation is requiring periodical maintenance. You can check
> build fixes commits due to unified source compilation with:
> 
>$ git log --pretty=short --grep "Non-unified"
> 
> Here are some examples:
>https://bugs.webkit.org/show_bug.cgi?id=222652
>https://bugs.webkit.org/show_bug.cgi?id=222755
>https://bugs.webkit.org/show_bug.cgi?id=221701
> 
> A new builder which builds WebKit with non-unified Source will highly
> help to improve this situation. Compilation errors will be detected as
> soon as possible and will save a lot of time not only for the developers
> who are currently doing this manual maintenance but for anyone who would
> like to build WebKit, and may stumble on compilation errors accidentally
> introduced due to unified sources.
> 
> While correct compilation of the codebase can only be guaranteed with
> non-unified source builds, we do not propose switching the current EWS
> compilation builders to non-unified because it's slower and the EWS
> LayoutTests and API test bots use the products built by the EWS builders
> — we do not want to delay getting results from those. That's why we are
> proposing a new builder: it will run on parallel, resulting in no
> slowdown for the other EWS builders, which will keep using unified
> builds.
> 
> How this new builder will impact developers? The EWS LayoutTest bots
> take at least 1 hour to complete a build. We think that as long as this
> new EWS Non-Unified builder is within that time budget, this new EWS
> wont' slow down development speed.
> 
> Thoughts?
> 
> Best regards,
> 
> Diego
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Alex Christensen via webkit-dev]

They are aware of this thread now, but I can’t comment on any future plans.  I 
do have a few quick questions, though. 

A quick glance at the client hellos sent by browsers shows this:
Safari on Big Sur sends TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008) and 
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) in its supported cipher suites 
section of the client hello.
Firefox 88 sends TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Chrome 90 sends no cipher suites with 3DES.

This might be why Chrome measures 0.00% use of TLS_RSA_WITH_3DES_EDE_CBC_SHA - 
because it doesn’t advertise that it supports it.  It seems to me that you’ve 
already removed support for 3DES in Chrome.  What was the measured use of 3DES 
cipher suites in the release before you removed support?  We have measured 
slightly above 0.00% use in a browser that does send 3DES cipher suites in its 
client hellos.

If you haven’t 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 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 clearly safe.
>> 
>> I doubt Safari controls its own TLS ciphersuite settings. In WebKitGTK, 
>> they're controlled by the operating system's TLS backend and crypto policy. 
>> 3DES has been disabled for a while now on modern systems, and users have not 
>> reported any compat issues, which is not surprising given your finding of 
>> 0.00%.
>> 
>> Michael
>> 
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Alex Christensen via webkit-dev]

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 clearly safe.
> 
> I doubt Safari controls its own TLS ciphersuite settings. In WebKitGTK, 
> they're controlled by the operating system's TLS backend and crypto policy. 
> 3DES has been disabled for a while now on modern systems, and users have not 
> reported any compat issues, which is not surprising given your finding of 
> 0.00%.
> 
> Michael
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Alex Christensen via webkit-dev]

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 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 
> super cookie on the client, and we want to minimize breakage when a user 
> agent decides to remove state to prevent tracking.
> 
> Well, with regards to cross-site tracking, I'll note that Accept-CH cache is 
> already naturally partitioned because it only applies to top-level loads. 
> Subresources follow a delegation model. But, yeah, one of the nice outcomes 
> of Client Hint Reliability is it makes the Accept-CH cache actually a cache, 
> so the UA can scope or clear it with less worry. I think reducing the 
> performance and functionality gap between new and returning clients is 
> generally valuable for this sort of thing. I hope Client Hint Reliability is 
> useful in this regard.
> 
> I can’t say I’ve followed this development closely or even thought through it 
> all completely, but here are some initial thoughts:
> 
> My first thought is that it seems excessive to have a way to specify support 
> of client hints both in the TLS handshake and in HTTP/{2,3} frames.  I guess 
> that’s why you wrote 
> https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md#why-two-mechanisms
>  
> <https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md#why-two-mechanisms>
> 
> I think you may have misunderstood the reference to two mechanisms. The TLS 
> ALPS extension and h2/h3 frames are part of the same mechanism. It's a 
> layering thing. TLS provides a generic spot to stick protocol-specific 
> settings early enough in the handshake, and then HTTP/{2,3} define how to use 
> it. (We don't want every new feature like this to require an update to the 
> TLS server.)
> 
> Rather, the reference is to (1) Critical-CH HTTP response header and (2) TLS 
> ALPS + h2/h3 frames. I'd love to avoid the redundancy, but I think this is 
> the best option given all the design constraints. And yeah the explainer 
> discusses why.
>  
> I don’t think that requiring a site to be running software that supports 
> client hints is a good prerequisite to using client hints, so I don’t think 
> that’s a good reason to have two mechanisms.
> 
> I'm not sure I'm parsing this sentence right. It sounds like you both don't 
> think server software changes are a good requisite, but also don't think it's 
> good to have a mechanism with lower server software requirements?
Oops!  Remove the first “don’t” in my sentence.
>  
> Sites can change with open connections, but if a site changes its client 
> hints acceptance, wouldn’t that be a good reason to terminate all the open 
> connections and require renegotiation?
> 
> Sites don't really work that way architecturally. You may have, for instance, 
> a CDN frontend handling TLS and H2/H3, but it contacts the origin server that 
> developers actually upload content to. In such deployments, there usually 
> isn't a way to signal an update to all connections like that. Moreover, 
> there's a race condition here. The client may request the resource at the 
> same time as the server signaling the new preferences.
>  
> Wildcard subdomains in the certificate is an interesting problem.
> 
> I'll add that cross-name pooling further complicates any hope of signaling 
> existing connections above.
>  
> If it is decided that multiple mechanisms are necessary, their interaction 
> should be well defined.  What if the server said one thing in ALPS but said 
> something different in an HTTP/{2,3} frame?  What if I have multiple 
> connections open to the same server and get different client hint headers?
> 
> Agreed it should be well-defined. I touched on this briefly in 
> draft-davidben-http-client-hint-reliability-02, but not in full detail. The 
> IETF and W3C/WHATWG split is a bit fun at the boundaries of the web platform 
> and network protocols. :-) I think we'll probably put the full Fetch 
> integration in https://github.com/WICG/client-hints-infrastructure 
> <https://github.com/WICG/client-hints-infrastructure>, alongside the other 
> Client Hints bits.
> 
> The interaction we think works best is that ALPS/frames and 
> Accept-CH/Critical-CH are conceptually two s

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

[Alex Christensen via webkit-dev]

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 this development closely or even thought through it 
all completely, but here are some initial thoughts:

My first thought is that it seems excessive to have a way to specify support of 
client hints both in the TLS handshake and in HTTP/{2,3} frames.  I guess 
that’s why you wrote 
https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md#why-two-mechanisms
I don’t think that requiring a site to be running software that supports client 
hints is a good prerequisite to using client hints, so I don’t think that’s a 
good reason to have two mechanisms.
Sites can change with open connections, but if a site changes its client hints 
acceptance, wouldn’t that be a good reason to terminate all the open 
connections and require renegotiation?
Wildcard subdomains in the certificate is an interesting problem.

If it is decided that multiple mechanisms are necessary, their interaction 
should be well defined.  What if the server said one thing in ALPS but said 
something different in an HTTP/{2,3} frame?  What if I have multiple 
connections open to the same server and get different client hint headers?

In 
https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md#retry-limits
 you specify that a client should not retry more than once per request to avoid 
infinite loops, but in 
https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md#server-triggered-retry
 you use the possibility of infinite loops as a reason that a server-triggered 
retry isn’t a good solution.  I think a server-triggered retry is a good 
solution and we should be able to expect that if someone wants their website to 
work, then they will do what it takes to make their servers work correctly.  
Don’t we have the possibility of infinite redirects today?

> On Apr 5, 2021, at 4:32 PM, Mike Taylor via webkit-dev 
>  wrote:
> 
> Hi there,
> 
> Complimentary to 
> https://lists.webkit.org/pipermail/webkit-dev/2021-January/031673.html, 
> Chromium intends to ship the ALPS + ACCEPT_CH HTTP/2 and HTTP/3 frames 
> portions of the Client Hints reliability proposal, and we would like to 
> solicit WebKit's position.
> 
> As mentioned in the linked thread, the Client Hint Reliability proposal is a 
> set of features aimed at making Client Hints more reliably available and 
> mitigating mis-matches between a site's preferences and the preferences 
> stored in the browser.
> 
> In particular, The ACCEPT_CH HTTP/2 and HTTP/3 frames, combined with the TLS 
> ALPS extension, are a connection-level optimization to deliver the server’s 
> Client Hint preferences in time for the first HTTP request.
> 
> Specifications:
> 
> https://tools.ietf.org/html/draft-davidben-http-client-hint-reliability 
> (section 4)
> https://tools.ietf.org/html/draft-vvv-httpbis-alps
> https://tools.ietf.org/html/draft-vvv-tls-alps
> https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md#connection-level-settings
> 
> thanks,
> Mike
> ___
> 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] 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 tha

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

[Alex Christensen]

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/show_bug.cgi?id=203547 
> <https://bugs.webkit.org/show_bug.cgi?id=203547> and it has required some 
> moving of settings from WebProcessPool to WebsiteDataStoreConfiguration.  
> I’ve done most of those, but WebProcessPool::platformInitializeNetworkProcess 
> in WebProcessPoolSoup.cpp requires some members be moved to a different 
> object.  Could someone who works on GTK/WPE do that in a separate patch and 
> I’ll rebase?  I’m planning to land my big patch in the next week or two, so I 
> thought I’d give you a heads up rather than just breaking libsoup networking.
> 
> Thanks, and happy coding!
> Alex
> ___
> 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] Moving things around a bit in libsoup code

[Alex Christensen]

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.  I’ve 
done most of those, but WebProcessPool::platformInitializeNetworkProcess in 
WebProcessPoolSoup.cpp requires some members be moved to a different object.  
Could someone who works on GTK/WPE do that in a separate patch and I’ll rebase? 
 I’m planning to land my big patch in the next week or two, so I thought I’d 
give you a heads up rather than just breaking libsoup networking.

Thanks, and happy coding!
Alex___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Alex Christensen]

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 take away from what Darin is saying here about correct 
> usage of forward declaration and , I’d like to understand why 
> we have two different compilation models supported in WebKit. Is there a 
> reason both need to be supported? Can we remove one?
> 
> 
> I also want to know that. Does anyone still need non-unified builds?
> 
> I introduced other unnecessary header inclusion, and Darin asked me to fix it.
> https://bugs.webkit.org/show_bug.cgi?id=214204#c25
>  Reducing header 
> inclusion can easily cause build breakages for non-unified builds.
> So, I fixed non-unified build breakage in r264332 and r264333 as the 
> preparation for that.
> Non-unified builds was more broken than I expected. Does anyone still need it?
> Should we maintain non-unified builds until C++20 modules will nullify 
> unified builds?
>  
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Alex Christensen]

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 provide.

> On Jun 17, 2020, at 9:48 PM, Simon Fraser  wrote:
> 
> I also object to losing good stack traces for crashes on Debug bots.
> 
> Also, I don't think Debug bots should build something different from what I 
> build at my desk.
> 
> Simon
> 
>> On Jun 17, 2020, at 1:36 PM, Mark Lam > > wrote:
>> 
>> Hi folks,
>> 
>> We're planning to switch the JSC EWS bot and build.webkit.org 
>>  Debug build and test bots to building with the 
>> following set first:
>> ./Tools/Scripts/set-webkit-configuration --force-opt=O3
>> 
>> This means the Debug builds will be built with optimization level forced to 
>> O3.
>> 
>> Why are we doing this?
>> 1. So that the JSC EWS will start catching ASSERT failures.
>> 2. JSC stress test Debug bots have been timing out and not running tests at 
>> all.  Hopefully, this change will fix this issue.
>> 3. Tests will run to completion faster and we’ll catch regressions sooner.
>> 
>> The downside: crash stack traces will be like Release build stack traces.  
>> But I don’t think we should let this deter us.  It’s not like there’s no 
>> stack information.  And just as we do with debugging Release build test 
>> failures, we can always do a Debug build locally to do our debugging.
>> 
>> We would like to apply this change to all Debug build and test bots, not 
>> just the JSC ones.  Does anyone strongly object to this change?
>> 
>> Thanks.
>> 
>> Cheers,
>> Mark
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org 
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Alex Christensen]

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 queried through 
WebKit any other way, but I don’t think we oppose adding Viewport-Width which 
is trivial to query with 100% accuracy once you have JavaScript on the client.  
I think Downlink and RTT were in a grey area because they can indeed be 
measured other ways, but we don’t want to possibly increase the fingerprinting 
information by providing values that can be used for more effective client 
fingerprinting, such as if we were to send the exact same value to multiple 
servers.

I don’t think this is an official position, just what I recall from TPAC 
discussions in Lyon.

> On May 8, 2020, at 12:14 AM, Maciej Stachowiak  wrote:
> 
> Accidentally removed Yoav from Cc and I’m not sure if he is on this list.
> 
>> On May 8, 2020, at 12:04 AM, Maciej Stachowiak  wrote:
>> 
>> 
>> I would consider myself mildly positive as to the direction, but that’s my 
>> personal view for the moment, absent consultation with my colleagues. I will 
>> solicit more viewpoints.
>> 
>> I particularly appreciate the responsiveness to feedback and that Yoav in 
>> particular has been willing to iterate.
>> 
>> I think there’s a number of things in the spec that should be cleaned up 
>> before an implementation ships enabled by default, specifically around 
>> interop, privacy, and protection against UA lockouts. I know there are PRs 
>> in flight for some of these issues. I think it would be good to get more of 
>> the open issues to resolution before actually shipping this.
>> 
>> Regards,
>> Maciej
>> 
>>> On May 7, 2020, at 4:22 PM, Michael Catanzaro  wrote:
>>> 
>>> My personal $0.02: I'm mildly supportive of this spec. It's certainly an 
>>> improvement on existing HTTP user agent headers. I appreciate that you 
>>> worked to incorporate feedback into the spec and considered the concerns of 
>>> small browsers.
>>> 
>>> Is it going to solve all the problems caused by user agent headers? No. If 
>>> WebKit implements the spec, we're surely going to eventually need a quirks 
>>> list for user agent client hints to decide which websites to lie to, just 
>>> like we already have quirks for the user agent header. And as long as 
>>> Chrome sends a user agent header that includes the string "Chrome", it's 
>>> unlikely we'll be able to get rid of the existing quirks list. But I think 
>>> client hints will probably reduce the amount of websites that 
>>> *accidentally* break WebKit, by replacing wild west UA header parsing with 
>>> well-defined APIs, and adding some GREASE for good measure. The promise of 
>>> freezing Chrome's UA header sounds nice, as it makes quirks easier to 
>>> maintain. And being able to ration entropy by revealing details about the 
>>> platform on an active rather than passive basis is quite appealing.
>>> 
>>> The spec attracted some misplaced concern about negative impact to small 
>>> browsers, which I've rebutted in [1]. I'm not quite so enthusiastic about 
>>> this spec as I was initially, especially after I was convinced that the 
>>> GREASE is never going to be enough to remove our quirks list, but it's 
>>> certainly not going to *hurt* small browsers.
>>> 
>>> This spec has received some pretty harsh criticism from the user tracking 
>>> industry (some call it the "ad industry"). Not historically a friend of 
>>> WebKit, so sounds good to me. ;)
>>> 
>>> One concern I haven't mentioned elsewhere is that frozen UA header might 
>>> encourage deeper levels of fingerprinting than are currently used, e.g. for 
>>> ad fraud prevention. caddy has started blocking WebKitGTK users based on 
>>> TLS handshake fingerprint (yes, really!) [1]. If techniques like that take 
>>> off as a result of this, that could potentially backfire on us quite badly. 
>>> But websites could choose to do such things today anyway, client hints or 
>>> no, and if so, the solution will be for us to just try even harder to look 
>>> more like Chrome.
>>> 
>>> Seems like a net positive overall. I don't work for Apple and can't say 
>>> whether it might be implemented by WebKit.
>>> 
>>> Michael
>>> 
>>> [1] 
>>> https://github.com/w3ctag/design-reviews/issues/467#issuecomment-583104002
>>> [2] https://mitm.watch/
>>> 
>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Alex Christensen]

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 cost, but sometimes it can be a large 
cost if it’s using lots of memory.  We may choose that’s ok.

> On Jan 14, 2020, at 11:55 AM, 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 [[maybe_unused]] is more correct choice to describe the code
>>> because sessionID is actually used.
>> 
>> In this case you could use RELEASE_LOG_DISABLED but I agree
>> [[maybe_unused]] would be better.  I’m ok with it as long as all the ports 
>> are
>> OK with it, including support in their oldest supported compiler.
> 
> Got it. I'll try sending to EWS to see it works for every ports. 
> 
>> I think it would be better to put #if PLATFORM(COCOA) around member
>> variables like this because I don’t think [[maybe_unused]] will remove the
>> additional byte in the structure.  Otherwise we’re just wasting memory.
> 
> Let us think about the cost to maintain platform dependent implementation of 
> this class.
> Because the member variable is assigned in constructor, we have to make 
> platform dependent
> Constructor which is usually hard to maintain and want to away from that if 
> possible.
> 
> How about this?
> 
> template  struct Unused { explicit Empty(T) { } };
> 
> #if PLATFORM(COCOA)
> bool m_isHTTPSCheckEnabled;
> #else
> [[maybe_unused]] Unused m_isHTTPSCheckEnabled;
> #endif
> 
> 
> -
> Basuke Suzuki
> SONY PlayStation

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

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

[Alex Christensen]

> 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 
> [[maybe_unused]] is more correct choice to describe the code because 
> sessionID is actually used.
In this case you could use RELEASE_LOG_DISABLED but I agree [[maybe_unused]] 
would be better.  I’m ok with it as long as all the ports are OK with it, 
including support in their oldest supported compiler.

> This member variable is only used in COCOA port. 
> (https://github.com/WebKit/webkit/blob/master/Source/WebKit/NetworkProcess/NetworkLoadChecker.cpp#L203)
> 
> We can add UNUSED_PARAM(isHTTPSUpgradeEnabled) in our platform code, but 
> adding [[maybe_unused]] in the header file is straight forward.
I think it would be better to put #if PLATFORM(COCOA) around member variables 
like this because I don’t think [[maybe_unused]] will remove the additional 
byte in the structure.  Otherwise we’re just wasting memory.

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

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

[Alex Christensen]

When the lambda is mutable or has a trailing return type, the () is currently 
required by the C++ grammar, so we can’t say to always omit ().  We could say 
to always have it, to only have it when necessary, or have no code style 
guideline.  I think we should always have spaces before and after, though.

> On Nov 3, 2019, at 3:27 AM, Ryosuke Niwa  wrote:
> 
> 
> 
> On Sat, Nov 2, 2019 at 8:25 PM Ryosuke Niwa  > wrote:
> 
> On Sat, Nov 2, 2019 at 7:54 PM Chris Dumez  > wrote:
> 
> 
>> On Nov 2, 2019, at 7:38 PM, Ryosuke Niwa > > wrote:
>> 
>> 
>> 
>> On Sat, Nov 2, 2019 at 1:23 AM Antti Koivisto > > wrote:
>> 
>> On Sat, Nov 2, 2019 at 1:38 AM Ryosuke Niwa > > wrote:
>> On Fri, Nov 1, 2019 at 11:53 AM Michael Catanzaro > > wrote:
>> On Fri, Nov 1, 2019 at 11:19 am, Ryosuke Niwa > > wrote:
>> > Namely, some people write a lambda as:
>> > auto x = [] () { }
>> > 
>> > with a space between [] and () while others would write it as:
>> > 
>> > auto x = []() { }
>> 
>> 🔧: I omit the () when there are no parameters, as in these examples.
>> 
>> I guess that's another thing we should decide. Should we, or should we not 
>> have () when there are no arguments.
>> 
>> I think this is easily settled by voting via exiting practice. We have 1287 
>> instances of [&] { and 107 instances of [&]() { and &] () { across the whole 
>> WebKit.
>> 
>> That’s good to know. Why don’t we go with the status quo then.
>> 
>> In this case, we do put a space between ] or ) and {, right?
> 
> How is this the conclusion from Antti’s comment?
> 
> Based on the discussion so far, it thought no space had a slight lead.
> 
> I think you’re conflating this discussion with the other email thread about a 
> space between [] and ().
> 
> Here, I’m talking about placing a space after [] before { as in:
> [] { }
> 
> As opposed to:
> []{ }
> 
> We never use the latter style whether it’s other control flow statements like 
> if, while, or for, or for function definitions.
> 
> - R. Niwa
> 
> -- 
> - R. Niwa
> -- 
> - R. Niwa
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] WinCairo EWS

[Alex Christensen]

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 example.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Alex Christensen]

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  wrote:
> 
>> On Aug 23, 2019, at 7:26 AM, Antti Koivisto  wrote:
>> 
>> Could WTF::makeUnique simply use FastMalloc by default? We could then remove 
>> most of these messy annotations.
>> 
>> This would require replacing std::unique_ptr with a type that knows how to 
>> free the objects correctly (bring back OwnPtr!) but that doesn't seem like a 
>> big deal. It wouldn't play well with mixed use of OwnPtr and new/delete but 
>> that should be avoided in any case.
> 
> I also suggested this, and you can see Yusuke’s response here 
> .
> 
> — Darin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[webkit-dev] John Wilander is a WebKit reviewer

[Alex Christensen]

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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Alex Christensen]

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 > <mailto:fujii.hiron...@gmail.com>> wrote:
>> 
>> Hi,
>> 
>> wtf/CheckedArithmetic.h has been converted from C++14 to C++11.
>> 
>> Bug 195187 – Change CheckedArithmetic to not use std::enable_if_t.
>> https://bugs.webkit.org/show_bug.cgi?id=195187 
>> <https://bugs.webkit.org/show_bug.cgi?id=195187>
>> Which WTF headers still should be in C++11?
>> 
>> - Fujii
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 

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

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

[Alex Christensen]

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

[Alex Christensen]

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 step is running 
on.

> On May 27, 2019, at 11:49 PM, Rajagopalan Gangadharan  
> wrote:
> 
> Hello Everybody,
> 
> I stumbled upon a problem in an attempt to port webkit to haiku. Before 
> everything I would like to take few moments to explain about state of the 
> port. 
> 
> 1) We have a well maintained WebKitLegacy port on haiku. 
> 2) Now in the process of porting latest webkit to haiku currently at fixing 
> IPC. We didnt want to use BSD sockets and would like to use Native messaging 
> framework [BMessage : https://www.haiku-os.org/docs/api/classBMessage.html 
>  ] because our native 
> application waits for BMessage in its main thread as a result we cant wait 
> for both sockets and BMessage on same thread. Also we would like to maintain 
> the haiku ecosystem :) .
> 
> 3) We need process id of the intended process we would like to connect to 
> send data [BMessenger: https://www.haiku-os.org/docs/api/classBMessenger.html 
>  ] So instead of 
> exchanging socket id's we would just exchange pid's
> 
> 4) We were able to successfully deliver and process the messages. Currently 
> we were able to proceed until creating a connection between network process 
> and webprocess(NetworkConnectionToWebProcess).
> 
> Now where we are stuck is that After creating a connection between network 
> process and webprocess we would have to reply back to webprocess about the 
> connection info( pid of network process in our case ). I see the reply is an 
> alias of DelayedReply(CompletionHandler) according to the 
> derived sources.
> Unfortunately the webprocess is indefinitely waiting for reply from 
> webprocessproxy for which we are unable to "reply" .
> 
> Could anyone point me where I would have went wrong or what could be done to 
> fix this and any better ways for implementing this.
> 
> Please check the source references for more info:
> NetworkProcessProxy: [ 
> https://github.com/RAJAGOPALAN-GANGADHARAN/webkit/blob/6bf81d79669be06b4efd9d8ced4139cbe07216b2/Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp#L150
>  
> ]
> 
> NetworkProcess [ 
> https://github.com/RAJAGOPALAN-GANGADHARAN/webkit/blob/6bf81d79669be06b4efd9d8ced4139cbe07216b2/Source/WebKit/NetworkProcess/haiku/NetworkProcessHaiku.cpp#L98
>  
> 
>  ]
> 
> ConnectionHaiku : 
> [https://github.com/RAJAGOPALAN-GANGADHARAN/webkit/blob/ipc-iteration2/Source/WebKit/Platform/IPC/haiku/ConnectionHaiku.cpp
>  
> 
>  ]
> 
> Attachment : [ 
> https://github.com/RAJAGOPALAN-GANGADHARAN/webkit/blob/ipc-iteration2/Source/WebKit/Platform/IPC/haiku/AttachmentHaiku.cpp
>  
> 
>  ]
> I believe these places are currently in focus 
> For further reference please check 
> [https://github.com/RAJAGOPALAN-GANGADHARAN/webkit/tree/ipc-iteration2 
> ]
> 
> Thank you
> Regards
> G.Rajagopalan
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Question about Apple's versioning policy

[Alex Christensen]

We increment that version whenever we need to based on internal processes that 
should be opaque.  If that works for you then use it, otherwise use your own 
versioning.

> On May 8, 2019, at 12:43 PM, basuke.suz...@sony.com wrote:
> 
> Hi
> 
> When taking a look into commits, there're many versioning commits. Sometime 
> it's so frequent but other time, it very quiet for a week. 
> 
> What is the versioning policy Apple operates? Major version is almost 
> obvious, but minor version is never used for last 5 years. Only tiny version 
> keep updating until major version bumps up.
> 
> The question is what situation do you decide to bump up tiny version?
> 
> We want to follow the versioning too if that is appropriate for us.
> 
> Cheers
> -
> Basuke Suzuki
> SONY PlayStation
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Alex Christensen]

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, 16:53, "Michael Catanzaro" :
>> Since there were no objections, I've updated the policy on the wiki:
>> 
>> https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy
>> https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement
> 
> Note that since we have to support libstdc++ 6.x, most of C++17 standard
> library features () should be disallowed. Those include std::filesystem, 
> std::string_view, etc. Core language features should be fine.
> -- 
> Regards,
> Konstantin
> 

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

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

[Alex Christensen]

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.
> 
> 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 switch?
> 
>> On Aug 4, 2017, at 4:00 PM, Michael Catanzaro  wrote:
>> 
>> On Fri, Aug 4, 2017 at 3:48 PM, Yusuke SUZUKI  wrote:
>>> Possibly, mcatanzaro and clopez know much about WebKitGTK+ compiler 
>>> dependencies.
>> 
>> As a result of the C++14 discussion on this list a few months ago, we 
>> relaxed our dependencies policy [1] to allow upgrading to GCC 5 one year 
>> earlier than planned, to the displeasure of some of our distributors who now 
>> have to build a custom compiler as part of their WebKit builds. We would 
>> prefer not to relax the policy further.
>> 
>> Our current schedule looks like:
>> 
>> * GCC 6 could be required in April 2018 (next Ubuntu LTS release)
>> * GCC 7 (required for C++17) could be required likely late in 2019 (next 
>> Debian stable release)
>> 
>> Is that acceptable for Apple?
>> 
>> Michael
>> 
>> [1] https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Alex Christensen]

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 switch?

> On Aug 4, 2017, at 4:00 PM, Michael Catanzaro  wrote:
> 
> On Fri, Aug 4, 2017 at 3:48 PM, Yusuke SUZUKI  wrote:
>> Possibly, mcatanzaro and clopez know much about WebKitGTK+ compiler 
>> dependencies.
> 
> As a result of the C++14 discussion on this list a few months ago, we relaxed 
> our dependencies policy [1] to allow upgrading to GCC 5 one year earlier than 
> planned, to the displeasure of some of our distributors who now have to build 
> a custom compiler as part of their WebKit builds. We would prefer not to 
> relax the policy further.
> 
> Our current schedule looks like:
> 
> * GCC 6 could be required in April 2018 (next Ubuntu LTS release)
> * GCC 7 (required for C++17) could be required likely late in 2019 (next 
> Debian stable release)
> 
> Is that acceptable for Apple?
> 
> Michael
> 
> [1] https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Alex Christensen]

A more specific example of why I object is that I want to do things like add a 
pointer to the thread an object was created on if ASSERT_DISABLED is false so I 
can assert if things are done on invalid threads.  If I do this in a class like 
RefCounted, this rule would make me add a guarded 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 think if we were to remove all the 
> m_attributeOwnerProxy initializers in WebKit it would add lots of duplication 
> with little benefit. If it were a class with a default constructor we would 
> have a high risk of forgetting a constructor somewhere.
> 
>> On Mar 20, 2019, at 9:22 AM, Simon Fraser  wrote:
>> 
>>> On Mar 14, 2019, at 1:06 PM, Filip Pizlo  wrote:
>>> 
>>> I like to draw this distinction: is the initializer a constant?
>>> 
>>> It’s not a constant if it relies on arguments to the constructor. “This” is 
>>> an argument to the constructor. 
>>> 
>>> It’s also not a constant if it involves reading the heap. 
>>> 
>>> So, like you, I would want to see this code done in the constructor. But 
>>> I’m not sure that my general rule is the same as everyone’s. 
>> 
>> This seems like a reasonable proposal to me: only use initializers when 
>> their input is constant data.
>> 
>> Any objections?
>> 
>> Simon
>> 
>>> 
>>> -Filip
>>> 
>>>> On Mar 14, 2019, at 12:59 PM, Simon Fraser  wrote:
>>>> 
>>>> I've seen some code recently that initializes non-POD members via 
>>>> initializers. For example, SVGAElement has:
>>>> 
>>>> AttributeOwnerProxy m_attributeOwnerProxy { *this };
>>>> 
>>>> I find this a little disorientating, and would normally expect to see this 
>>>> in the constructor as m_attributeOwnerProxy(*this), as it makes it easier 
>>>> to find places to set breakpoints, and the ordering of initialization is 
>>>> easier to see.
>>>> 
>>>> Are people OK with this pattern, or should we discourage it via the style 
>>>> guidelines (and style checker)?
>>>> 
>>>> Simon
>>>> 
>>>> ___
>>>> webkit-dev mailing list
>>>> webkit-dev@lists.webkit.org
>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Alex Christensen]

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 
with little benefit. If it were a class with a default constructor we would 
have a high risk of forgetting a constructor somewhere.

> On Mar 20, 2019, at 9:22 AM, Simon Fraser  wrote:
> 
>> On Mar 14, 2019, at 1:06 PM, Filip Pizlo  wrote:
>> 
>> I like to draw this distinction: is the initializer a constant?
>> 
>> It’s not a constant if it relies on arguments to the constructor. “This” is 
>> an argument to the constructor. 
>> 
>> It’s also not a constant if it involves reading the heap. 
>> 
>> So, like you, I would want to see this code done in the constructor. But I’m 
>> not sure that my general rule is the same as everyone’s. 
> 
> This seems like a reasonable proposal to me: only use initializers when their 
> input is constant data.
> 
> Any objections?
> 
> Simon
> 
>> 
>> -Filip
>> 
>>> On Mar 14, 2019, at 12:59 PM, Simon Fraser  wrote:
>>> 
>>> I've seen some code recently that initializes non-POD members via 
>>> initializers. For example, SVGAElement has:
>>> 
>>>  AttributeOwnerProxy m_attributeOwnerProxy { *this };
>>> 
>>> I find this a little disorientating, and would normally expect to see this 
>>> in the constructor as m_attributeOwnerProxy(*this), as it makes it easier 
>>> to find places to set breakpoints, and the ordering of initialization is 
>>> easier to see.
>>> 
>>> Are people OK with this pattern, or should we discourage it via the style 
>>> guidelines (and style checker)?
>>> 
>>> Simon
>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Encoding and decoding ProcessID

[Alex Christensen]

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, Rajagopalan Gangadharan  
> wrote:
> 
> WTF::ProcessID and WKProcessID are supposed to be of same type right? As 
> different types create ambiguity . As sam Weining suggested we made 
> WTF::ProcessID to be int32_t but WKProcessID is pid_t so can we also 
> explicitly make WKProcessID to be int32_t (will it conform to the current 
> webkit model? )or is there any way I could fix this( any implicit casting )
>  
> Regards,
> G.Rajagopalan
>  
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Alex Christensen]

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 > <mailto:m...@apple.com>> wrote:
>> 
>> 
>> It seems like `return foo();` where foo() is a void function can always be 
>> replaced with `foo(); return;` for greater clarity at the cost of one extra 
>> line break. For people who prefer the one-line style, can you say why you 
>> don’t like the other way?
> 
> We do not allow more than one statement per line so it would be:
> foo();
> return;
> 
> Also, since we favor early returns in WebKit, things like:
> If (!nok)
> return completionHandler(Failed);
> 
> Would become:
> If (!nok) {
> completionHandler(Failed);
> return;
> }
> 
> It is not a big deal but I personally prefer the most concise version. 
> Especially, it is not uncommon to have multiple early returns.
> I think more concise is better and I personally do not see a readability 
> issue here. It does not really matter what the completion handler is 
> returning.
> 
>> 
>>  - Maciej
>> 
>>> On Feb 20, 2019, at 10:33 AM, Simon Fraser >> <mailto:simon.fra...@apple.com>> wrote:
>>> 
>>> I find it mind bending. It makes me wonder if the author made a coding 
>>> error.
>>> 
>>> Simon
>>> 
>>>> On Feb 20, 2019, at 7:48 AM, Daniel Bates >>> <mailto:dba...@webkit.org>> wrote:
>>>> 
>>>> Thanks for the opinion!
>>>> 
>>>> Dan
>>>> 
>>>> On Feb 20, 2019, at 7:26 AM, Saam Barati >>> <mailto:sbar...@apple.com>> wrote:
>>>> 
>>>>> I prefer it as well.
>>>>> 
>>>>> - Saam
>>>>> 
>>>>> On Feb 20, 2019, at 6:58 AM, Chris Dumez >>>> <mailto:cdu...@apple.com>> wrote:
>>>>> 
>>>>>> I also prefer allowed returning void. 
>>>>>> 
>>>>>> Chris Dumez
>>>>>> 
>>>>>> On Feb 19, 2019, at 10:35 PM, Daniel Bates >>>>> <mailto:dba...@webkit.org>> wrote:
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Feb 19, 2019, at 9:42 PM, Ryosuke Niwa >>>>>> <mailto:rn...@webkit.org>> wrote:
>>>>>>> 
>>>>>>>> On Tue, Feb 19, 2019 at 8:59 PM Daniel Bates >>>>>>> <mailto:dba...@webkit.org>> wrote:
>>>>>>>> > On Feb 7, 2019, at 12:47 PM, Daniel Bates >>>>>>> > <mailto:dba...@webkit.org>> wrote:
>>>>>>>> >
>>>>>>>> > Hi all,
>>>>>>>> >
>>>>>>>> > Something bothers me about code like:
>>>>>>>> >
>>>>>>>> > void f();
>>>>>>>> > void g()
>>>>>>>> > {
>>>>>>>> > if (...)
>>>>>>>> > return f();
>>>>>>>> > return f();
>>>>>>>> > }
>>>>>>>> >
>>>>>>>> > I prefer:
>>>>>>>> >
>>>>>>>> > void g()
>>>>>>>> > {
>>>>>>>> > if (...) {
>>>>>>>> > f();
>>>>>>>> > return
>>>>>>>> > }
>>>>>>>> > f();
>>>>>>>> > }
>>>>>>>> >
>>>>>>>> Based on the responses it seems there is sufficient leaning to codify
>>>>>>>> the latter style.
>>>>>>>> 
>>>>>>>> I don't think there is a sufficient consensus as far as I can tell. 
>>>>>>>> Geoff 
>>>>>>> 
>>>>>>> I didn't get this from Geoff's remark. Geoff wrote:
>>>>>>> 
>>>>>>> ***“return f()” when f returns void is a bit mind bending.***
>>>>>>> Don't want to put words in Geoff's mouth. So, Geoff can you please 
>>>>>>> confirm: for the former style, for the latter style, no str

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

[Alex Christensen]

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, Geoffrey Garen  wrote:
> 
> FWIW, I’ve always felt conflicted about this case.
> 
> I very much prefer early return to if/else chains.
> 
> However, “return f()” when f returns void is a bit mind bending.
> 
> So, I can’t use my preferred style in functions that return void. Boo. 
> 
> Geoff
> 
>> On Feb 7, 2019, at 12:47 PM, Daniel Bates  wrote:
>> 
>> Hi all,
>> 
>> Something bothers me about code like:
>> 
>> void f();
>> void g()
>> {
>>if (...)
>>return f();
>>return f();
>> }
>> 
>> I prefer:
>> 
>> void g()
>> {
>>if (...) {
>>f();
>>return
>>}
>>f();
>> }
>> 
>> Does it bother you? For the former? For the latter? Update our style guide?
>> 
>> Opinions, please.
>> 
>> Dan
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[webkit-dev] libsoup and libcurl networking implementations

[Alex Christensen]

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 NetworkProcess object.  To accomplish this I 
eliminated all calls to NetworkStorageSession::storageSession and 
NetworkStorageSession::defaultStorageSession in WebCore, replacing them by a 
client call to get a NetworkStorageSession from the WebKit/WebKitLegacy layer 
in https://trac.webkit.org/r240117 but I did not remove all such calls from the 
libsoup and libcurl networking implementations.  The call to 
NetworkStorageSession::defaultStorageSession CurlResourceHandleDelegate.cpp and 
ResourceHandleCurl.cpp shouldn't be too hard to remove by asking the 
NetworkingContext for the storage instead of calling the static functions, but 
the calls in DNSResolveQueueSoup.cpp are a little bit trickier.  On Cocoa 
platforms, DNS lookup relies on state that is more global than a 
NetworkSession.  On Linux right now, it seems to use state on the default 
NetworkStorageSession, which is effectively global right now.  I think the best 
solution that maintains the status quo right now would be to keep the default 
NetworkStorageSession global in WebKit2 right now, but that requires a little 
bit more work than I can do blindly and iteratively with EWS.  I’d appreciate 
someone with a Linux development machine getting it working.

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

Re: [webkit-dev] AppleWin/WinCairo Resources

[Alex Christensen]

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 loading the missingImage and similar resources.
>  
> On https://bugs.webkit.org/show_bug.cgi?id=188175#c6 
> , Fujii-san mentioned that 
> it’d probably be the time to fix the fixme at
> https://github.com/WebKit/webkit/blob/c4b88ee56e4f77201ffdcaf6a5988cbc43e199f3/Source/WebKitLegacy/win/WebKitDLL.cpp#L171
>  
> 
> for loadResourceIntoBuffer.  Is there any reason that sharing the loading 
> code, the actual resource files, rc file or resource.h would be a problem 
> (especially for AppleWin)? And, if we want to share them, are there 
> suggestions about where to move those files? Could we move it down to WebCore 
> to be shared?
>  
> Thanks,
> Stephan
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Reducing globals

[Alex Christensen]

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 this move soon.
> Great!  Thanks!
>> 
>> I just want to confirm my understanding about Network Session. It is pretty 
>> similar concept with Cocoa's URLSession, isn't 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
>> 
>> 
>>> -Original Message-
>>> From: webkit-dev  On Behalf Of Alex
>>> Christensen
>>> Sent: Thursday, November 29, 2018 6:15 PM
>>> To: Webkit Development List 
>>> Subject: [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 go to
>>> NetworkSessionCreationParameters instead.  Could those maintaining the
>>> libsoup and libcurl networking implementations please lend a hand and move 
>>> the
>>> members enclosed in USE(SOUP) or USE(CURL)?  I have done similar moves in
>>> https://trac.webkit.org/changeset/238654/webkit and
>>> https://trac.webkit.org/changeset/238630/webkit if you would like a pattern 
>>> to
>>> follow.
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Alex Christensen]

We can definitely make our own WTF::Optional instead of using std::optional and 
change its move constructor/operator= and I personally think that would not be 
worth it but if I’m in the minority I’ll deal with it.  We cannot diverge from 
the C++ standards that say that moving from an object leaves the object in an 
undefined state, and right now in WebKit we are relying quite a lot on that 
undefined state.  I think that is the bigger problem that Chris was trying to 
solve.

> On Dec 17, 2018, at 4:32 PM, Ryosuke Niwa  wrote:
> 
> Let me add this.
> 
> The situation we have here is analogous to having a member function "move()" 
> which leave std::optional in undefined state as in:
> 
> std::optional a;
> std::optional b = a.move();
> 
> would leave a in some undefined state. I don't care what C++ standards say or 
> what STL does. That's insane.
> Every object should remain in a well defined state after performing an 
> operation.
> 
> - R. Niwa
> 
> 
> On Mon, Dec 17, 2018 at 4:22 PM Ryosuke Niwa  <mailto:rn...@webkit.org>> wrote:
> It's true that WTFMove or std::move doesn't do anything if the moved variable 
> is not used because WTFMove / std::move is just a type cast.
> 
> However, that behavior is orthogonal from the issue that calling WTFMove / 
> std::move on std::optional, and the returned value is assigned to another 
> std::optional, the original std::optional 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 with our nice-to-use WTF types, 
> the state of a C++ object is undefined after being moved from:
> 
> #include 
> #include 
> #include 
> 
> class Test : public RefCounted { };
> 
> void useParameter(RefPtr&& param)
> {
>   RefPtr usedParam = WTFMove(param);
> }
> 
> void dontUseParameter(RefPtr&&) { }
> 
> int main() {
>   RefPtr a = adoptRef(new Test);
>   RefPtr b = adoptRef(new Test);
>   std::cout << "a null? " << !a << std::endl;
>   std::cout << "b null? " << !b << std::endl;
>   useParameter(WTFMove(a));
>   dontUseParameter(WTFMove(b));
>   std::cout << "a null? " << !a << std::endl;
>   std::cout << "b null? " << !b << std::endl;
>   return 0;
> }
> 
> // clang++ test.cpp -I Source/WTF -L WebKitBuild/Debug -l WTF -framework 
> Foundation -L /usr/lib -l icucore --std=c++17 && ./a.out  
>  
> // a null? 0  
>   
> // b null? 0  
>   
> // a null? 1  
>   
> // b null? 0  
>  
> 
> 
> As you can see, the internals of callee dontUseParameter (which could be in a 
> different translation unit) affects the state of the local variable b in this 
> function.  This is one of the reasons why the state of a moved-from variable 
> is intentionally undefined, and we can’t fix that by using our own 
> std::optional replacement.  If we care about the state of a moved-from 
> object, that is what std::exchange is for.  I think we should do something to 
> track and prevent the use of moved-from values instead of introducing our own 
> std::optional replacement.
> 
>> On Dec 17, 2018, at 2:47 PM, Ryosuke Niwa > <mailto:rn...@webkit.org>> wrote:
>> 
>> Yeah, it seems like making std::optional more in line with our own 
>> convention provides more merits than downsides here. People are using 
>> WTFMove as if it's some sort of a swap operation in our codebase, and as 
>> Maciej pointed out, having rules where people have to think carefully as to 
>> when & when not to use WTFMove seems more troublesome than the proposed fix, 
>> which would mean this work for optional.
>> 
>> - R. Niwa
>> 
>> On Mon, Dec 17, 2018 at 2:24 PM Geoffrey Garen > <mailto:gga...@apple.com>> wrote:
>> I don’t understand the claim about “undefined behavior” here. As Maciej 
>> pointed out, these 

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

[Alex Christensen]

Let me give a concrete example on why, even with our nice-to-use WTF types, the 
state of a C++ object is undefined after being moved from:

#include 
#include 
#include 

class Test : public RefCounted { };

void useParameter(RefPtr&& param)
{
  RefPtr usedParam = WTFMove(param);
}

void dontUseParameter(RefPtr&&) { }

int main() {
  RefPtr a = adoptRef(new Test);
  RefPtr b = adoptRef(new Test);
  std::cout << "a null? " << !a << std::endl;
  std::cout << "b null? " << !b << std::endl;
  useParameter(WTFMove(a));
  dontUseParameter(WTFMove(b));
  std::cout << "a null? " << !a << std::endl;
  std::cout << "b null? " << !b << std::endl;
  return 0;
}

// clang++ test.cpp -I Source/WTF -L WebKitBuild/Debug -l WTF -framework 
Foundation -L /usr/lib -l icucore --std=c++17 && ./a.out
   
// a null? 0

// b null? 0

// a null? 1

// b null? 0
   


As you can see, the internals of callee dontUseParameter (which could be in a 
different translation unit) affects the state of the local variable b in this 
function.  This is one of the reasons why the state of a moved-from variable is 
intentionally undefined, and we can’t fix that by using our own std::optional 
replacement.  If we care about the state of a moved-from object, that is what 
std::exchange is for.  I think we should do something to track and prevent the 
use of moved-from values instead of introducing our own std::optional 
replacement.

> On Dec 17, 2018, at 2:47 PM, Ryosuke Niwa  wrote:
> 
> Yeah, it seems like making std::optional more in line with our own convention 
> provides more merits than downsides here. People are using WTFMove as if it's 
> some sort of a swap operation in our codebase, and as Maciej pointed out, 
> having rules where people have to think carefully as to when & when not to 
> use WTFMove seems more troublesome than the proposed fix, which would mean 
> this work for optional.
> 
> - R. Niwa
> 
> On Mon, Dec 17, 2018 at 2:24 PM Geoffrey Garen  <mailto:gga...@apple.com>> wrote:
> I don’t understand the claim about “undefined behavior” here. As Maciej 
> pointed out, these are our libraries. We are free to define their behaviors.
> 
> In general, “undefined behavior” is an unwanted feature of programming 
> languages and libraries, which we accept begrudgingly simply because there 
> are practical limits to what we can define. This acceptance is not a mandate 
> to carry forward undefined-ness as a badge of honor. In any case where it 
> would be practical to define a behavior, that defined behavior would be 
> preferable to undefined behavior.
> 
> I agree that the behavior of move constructors in the standard library is 
> undefined. The proposal here, as I understand it, is to (a) define the 
> behaviors move constructors in WebKit and (b) avoid 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 > <mailto:achristen...@apple.com>> wrote:
>> 
>> This one and the many others like it are fragile, relying on undefined 
>> behavior, and should be replaced by std::exchange.  Such a change was made 
>> in https://trac.webkit.org/changeset/198755/webkit 
>> <https://trac.webkit.org/changeset/198755/webkit> and we probably need many 
>> more like that, but we are getting away with relying on undefined behavior 
>> which works for us in most places.
>> 
>>> On Dec 17, 2018, at 11:24 AM, Chris Dumez >> <mailto:cdu...@apple.com>> wrote:
>>> 
>>> 
>>> 
>>>> On Dec 17, 2018, at 11:10 AM, Chris Dumez >>> <mailto:cdu...@apple.com>> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Dec 17, 2018, at 10:27 AM, Alex Christensen >>>> <mailto:achristen...@apple.com>> wrote:
>>>>> 
>>>>>>>>> On Dec 14, 2018, at 1:37 PM, Chris Dumez >>>>>>>> <mailto:cdu..

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

[Alex Christensen]

This one and the many others like it are fragile, relying on undefined 
behavior, and should be replaced by std::exchange.  Such a change was made in 
https://trac.webkit.org/changeset/198755/webkit and we probably need many more 
like that, but we are getting away with relying on undefined 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, Alex Christensen >> <mailto:achristen...@apple.com>> wrote:
>>> 
>>>>>>> On Dec 14, 2018, at 1:37 PM, Chris Dumez >>>>>> <mailto:cdu...@apple.com>> 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 object to pass into a 
>>> function parameter, for example, the state of the moved-from object depends 
>>> on the behavior of the callee.  If the callee function uses the object, we 
>>> often have behavior that leaves the object in an “empty” state of some 
>>> kind, but we are definitely relying on fragile undefined behavior when we 
>>> do so because changing the callee to not use the parameter changes the 
>>> state of the caller.  We should never assume that WTFMove or std::move 
>>> leaves the object in an empty state.  That is always a bug that needs to be 
>>> replaced by std::exchange.
>> 
>> Feel like we’re taking about different things. I am talking about move 
>> constructors (and assignment operators), which have a well defined behavior 
>> in WebKit. And it seems you are talking about WTFMove(), which despite the 
>> name does not “move” anything, it is merely a cast.
>> In the case you’re talking about the caller does NOT call the move 
>> constructor, it merely does a cast so I do not think your comment 
>> invalidates my statement. Note that in my patch, I was nearly WTFMove()ing 
>> the data member and assigning it to a local variable right away, calling the 
>> move constructor.
> 
> Also note that may of us already rely on our move constructors’ behavior, 
> just search for WTFMove(m_responseCompletionHandler) in:
> https://trac.webkit.org/changeset/236463/webkit 
> <https://trac.webkit.org/changeset/236463/webkit>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Alex Christensen]

 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 object to pass into a 
function parameter, for example, the state of the moved-from object depends on 
the behavior of the callee.  If the callee function uses the object, we often 
have behavior that leaves the object in an “empty” state of some kind, but we 
are definitely relying on fragile undefined behavior when we do so because 
changing the callee to not use the parameter changes the state of the caller.  
We should never assume that WTFMove or std::move leaves the object in an empty 
state.  That is always a bug that needs to be replaced by std::exchange.

> On Dec 14, 2018, at 3:20 PM, youenn fablet  wrote:
> 
> Is it too late to ask for a std::optional change?
Yes

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

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

[Alex Christensen]

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 problem.

> On Dec 8, 2018, at 3:22 PM, Darin Adler  wrote:
> 
> OK, here’s my answer after thinking on it a bit:
> 
> Best would be to eliminate “config.h”: Change “config.h” into an empty file 
> first, then remove all “config.h” includes, and then remove the file. But to 
> do that, we need to make sure every build system for WebKit supports prefix 
> headers. I don’t know how close to that we are. Maybe close? How can we 
> quickly find out?
> 
> Lacking that, I think we can and should change “config.h” so it’s just an 
> include of “WebCorePrefix.h”, or the other way around. I think it would be 
> valuable to keep the feature where we try to catch cases where we forget to 
> include “config.h”, on the platforms that use a prefix header, for the 
> benefit of the platforms that do not. That might mean small complexity 
> remains and one file won’t literally just be a trivial include of the other.
> 
> I suppose it’s also important to verify that there is no benefit to 
> precompiling less than all of what “config.h” includes.
> 
> — Darin
> 
> PS: I don’t think we know that there is only one configuration that needs 
> “config.h”. That second code snippet from your original message, Alexey, was 
> only relevant for platforms that are trying to support macOS without prefix 
> headers, and there could be any number of non-macOS cases. (And that include 
> seems like a relatively recent change done by someone who didn’t fully 
> understand the original scheme.)
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Reducing globals

[Alex Christensen]

> On Dec 3, 2018, at 12:55 PM, basuke.suz...@sony.com wrote:
> 
> Alex,
> 
> Got it. Curl port will catch up this move soon.
Great!  Thanks!
> 
> I just want to confirm my understanding about Network Session. It is pretty 
> similar concept with Cocoa's URLSession, isn't 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
> 
> 
>> -Original Message-
>> From: webkit-dev  On Behalf Of Alex
>> Christensen
>> Sent: Thursday, November 29, 2018 6:15 PM
>> To: Webkit Development List 
>> Subject: [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 go to
>> NetworkSessionCreationParameters instead.  Could those maintaining the
>> libsoup and libcurl networking implementations please lend a hand and move 
>> the
>> members enclosed in USE(SOUP) or USE(CURL)?  I have done similar moves in
>> https://trac.webkit.org/changeset/238654/webkit and
>> https://trac.webkit.org/changeset/238630/webkit if you would like a pattern 
>> to
>> follow.
>> ___
>> 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] Reducing globals

[Alex Christensen]

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 go to 
NetworkSessionCreationParameters instead.  Could those maintaining the libsoup 
and libcurl networking implementations please lend a hand and move the members 
enclosed in USE(SOUP) or USE(CURL)?  I have done similar moves in 
https://trac.webkit.org/changeset/238654/webkit and 
https://trac.webkit.org/changeset/238630/webkit if you would like a pattern to 
follow.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Alex Christensen]

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.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Move to NavigationClient

[Alex Christensen]

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  wrote:
> 
> 
> 
> On Oct 20, 2017 4:30 PM, "Alex Christensen"  <mailto:achristen...@apple.com>> wrote:
> Right now we have an API::LoaderClient, API::PolicyClient and an 
> API::NavigationClient.  We intend to remove the first two in the future in 
> favor of the API::NavigationClient.  
> 
> Is there a semantic model this design decision is based on?
> 
> From the current semantic and architectural perspectives, it sounds like it 
> would be a mistake. Particularly merging navigation duties with policy. Not 
> helpful to all clients.
> 
> 
> Warmest regards,
> Alfonso Guerra
> Founder/CEO
> Apokalypse Software Corp
> @Huperniketes
> (626) 667-4285

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

Re: [webkit-dev] Move to NavigationClient

[Alex Christensen]

Also, the authentication challenge API also needs redesigning.  Right now you 
get an AuthenticationChallenge from which you get an 
AuthenticationDecisionListener to respond to.  Could these become one object in 
the GTK API?  The current design is based somewhat 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  wrote:
> 
> On Fri, Oct 20, 2017 at 3:30 PM, Alex Christensen  
> wrote:
>> Right now we have an API::LoaderClient, API::PolicyClient and an 
>> API::NavigationClient. We intend to remove the first two in the future in 
>> favor of the API::NavigationClient. I have been working to add calls to the 
>> NavigationClient to make it a replacement for the LoaderClient and 
>> PolicyClient. The linux ports, however, have WebKitPolicyClient and 
>> WebKitLoaderClient. Could someone working on Linux replace these with an 
>> implementation of API::NavigationClient?
> 
> Thanks for the heads-up. We'll discuss who will do this work.
> 
> Michael
> 

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

[webkit-dev] Move to NavigationClient

[Alex Christensen]

Right now we have an API::LoaderClient, API::PolicyClient and an 
API::NavigationClient.  We intend to remove the first two in the future in 
favor of the API::NavigationClient.  I have been working to add calls to the 
NavigationClient to make it a replacement for the LoaderClient and 
PolicyClient.  The linux ports, however, have WebKitPolicyClient and 
WebKitLoaderClient.  Could someone working on Linux replace these with an 
implementation of API::NavigationClient?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Alex Christensen]

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:
> 
> Trying to build webkit for android on Windows. Does anyone know where i can 
> start to diagnose these errors?
> 
> CSSPropertyNames.h
> HTTPHeaderNames.h
> WebCoreJSBuiltinInternals.h
> 
> the above header files were never generated. I assume there is javascript 
> file that I can look at for this.
> 
> I found "WebCoreJSBuiltinInternals.cpp" but it was generated by cmake. which 
> was basically zero help. 
>  
> 
> 
> 26>C:\Users\wrigh\Videos\webkit-master\Source\WebCore/platform/animation/Animation.h(27):
>  fatal error C1083: Cannot open include file: 'CSSPropertyNames.h': No such 
> file or directory (compiling source file 
> C:\Users\wrigh\Videos\webkit-master\Source\WebKit\WebProcess\WebPage\android\WebPageAndroid.cpp)
> 
> Cannot open include file: 'HTTPHeaderNames.h': No such file or directory 
> (compiling source file 
> C:\Users\wrigh\Videos\webkit-master\Source\WebKit\UIProcess\cairo\BackingStoreCairo.cpp)
> 26>AcceleratedDrawingArea.cpp
> 
> 'WebCoreJSBuiltinInternals.h': No such file or directory (compiling source 
> file 
> C:\Users\wrigh\Videos\webkit-master\Source\WebCore\bindings\js\JSDOMIterator.cpp)
> 17>ReadableStream.cpp
> 
> Much obliged
> 
> Patrick
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Alex Christensen]

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 
https://build.webkit.org/waterfall?category=iOS 

Maybe you forgot to run configure-xcode-for-ios-development

> On Sep 27, 2017, at 7:10 AM, Frédéric WANG  wrote:
> 
> Hello,
> 
> I've recently upgraded XCode and rebuilt Safari but when I try running
> Safari on the simulator, I get the following errors:
> 
> Tools/Scripts/build-safari --ios-simulator --debug
> Tools/Scripts/run-safari --ios-simulator
> Quitting and launching iOS Simulator...
> Installing
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator11.0.sdk/Applications/MobileSafari.app.
> An error was encountered processing the command
> (domain=NSPOSIXErrorDomain, code=2):
> Failed to install the requested application
> An application bundle was not found at the provided path.
> Provide a valid path to the desired application bundle.
> Died at /Users/fred/WebKit/Tools/Scripts/webkitdirs.pm line 2546.
> 
> I can not find any MobileSafari.app in my WebKitBuild directory nor in
> the /Applications/ directory calculated by webkitdirs.pm ; trying to
> hardcode a different path in webkitdirs.pm I instead obtain:
> 
> Quitting and launching iOS Simulator...
> Installing
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/Applications/MobileSafari.app.
> An error was encountered processing the command
> (domain=IXUserPresentableErrorDomain, code=2):
> This app was unable to be installed.
> Died at /Users/fred/WebKit/Tools/Scripts/webkitdirs.pm line 2546.
> 
> Did anyone experience the same issue?
> 
> -- 
> Frédéric Wang
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] 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)

[Alex Christensen]

> 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 Alberto Lopez Perez  
> wrote:
> Does this means that Apple ports are going to switch to CMake?
We have not decided anything officially yet, and if we were to decide to do 
this then it would take quite a while to make the official switch.

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

Re: [webkit-dev] Webkit Nightly build is broken

[Alex Skachkov]

Hi,

It seems that problem with build appeared again.
I can’t found builds for 29/08/2017 and diff between the latest build on 
28/08/2017 more that 100 commits

Could you please check if WebKit nightly build is still working?

Best regards,
Oleksandr Skachkov


> On Aug 24, 2017, at 9:00 PM, Ling Ho  wrote:
> 
> Hi Oleksandr,
> 
> We have nightly builds uploading again. Let us know if you see any further 
> issue.
> 
> Thanks,
> ...
> ling
> 
> 
> 
> On 8/23/17 12:24 PM, Alex Skachkov wrote:
>> Hi all,
>> 
>> I can’t found any new Webkit Nightly build in 
>> https://webkit.org/nightly/archives/ <https://webkit.org/nightly/archives/> 
>> later then r220267 August 4, 2017.
>> It seems that Webkit Nightly build is broken, is it possible to fix it?
>> 
>> Best regards,
>> Oleksandr Skachkov 
>> 
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>> <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] Webkit Nightly build is broken

[Alex Skachkov]

Hi all,

I can’t found any new Webkit Nightly build in 
https://webkit.org/nightly/archives/  
later then r220267 August 4, 2017.
It seems that Webkit Nightly build is broken, is it possible to fix it?

Best regards,
Oleksandr Skachkov ___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Server Timing API

[Alex Christensen]

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  wrote:
> 
> ​Hi,
> 
> I’d like to add support for Server Timing and wanted to gauge interest for 
> supporting the feature.
> 
> The Server Timing API reads response headers and appends metrics to the 
> timing entry associated with the request/response cycle (either the 
> PerformanceNavigationTiming or PerformanceResourceTiming entry). This allows 
> applications and analytics vendors to collect and report the timing 
> associated with any segment of the request/response cycle, in order to 
> optimize application delivery.
> 
> Spec: 
> http://w3c.github.io/server-timing/ 
> 
> WebKit Bugzilla:
> https://bugs.webkit.org/show_bug.cgi?id=175569 
> 
> 
> Thanks!
> Charlie
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 

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

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

[Alex Christensen]

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 
> looking at the possibility of trying to remove/reduce the dependency on 
> Cygwin for the javascript tests from run-javascript-tests since the build 
> itself runs from a normal windows shell. Internally we did a very preliminary 
> POC of a version of run-jsc-stress-tests for windows which built perl scripts 
> for the test scripts rather than shell scripts and were able to get a bunch 
> of the tests running. We attached that to 
> https://bugs.webkit.org/show_bug.cgi?id=174985 . Obviously, that's not a 
> reasonable version for inclusion, but we wanted to discuss whether there was 
> support for removing the dependency before doing too much more down this path.
> 
> Our current thinking is that if we go forward with this, we'd probably step 
> it as:
> 1. Move the test script and test runner code from run-jsc-stress-tests into a 
> ruby file that is included from the main script
> 2. Make an option to allow using an alternate version of the above
> 3. Make an alternate version that didn't rely on shell
> 
> Thanks,
> Stephan
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Alex Christensen]

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 I’m pretty sure WebKit cannot be 
put as the system framework on an iOS device without Apple-internal tools.  
With a lot of work you might be able to statically link everything into a 
custom app for local debugging, but I’m pretty sure such an app would be 
rejected by the App Store based on section 2.5.6 of 
https://developer.apple.com/app-store/review/guidelines/ 


> On Jul 12, 2017, at 8:31 AM, Frédéric WANG  wrote:
> 
> Hello,
> 
> For development and testing purpose, I was wondering if there is a way
> to produce a build of WebKit/Safari-mobile and to install it on a device
> (instead of using the iOS simulator)? And is there any specific
> requirement like having an Apple developer license and a registered device?
> 
> I know that we have a builder [1] and I just noticed the "--ios-device"
> parameter for the build-webkit script but I can't find any information
> on the official documentation [2] or on the WebKit wiki. I also tried
> searching this mailing list about the topic but could not find any
> relevant thread.
> 
> Thanks,
> 
> Frédéric
> 
> [1] https://build.webkit.org/builders/Apple%20iOS%2010%20Release%20(Build)
> [2] https://webkit.org/building-webkit/
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] update GCC version?

[Alex Christensen]

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
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Alex Christensen]

Ok, maybe we can get rid of std::function, then!  I hadn’t used BlockPtr as 
much as Chris.  I’d be opposed to adding a copy constructor to WTF::Function 
because the non-copyability of WTF::Function is why we made it, and it has 
prevented many bugs.

I’ve also seen many cases where I have a WTF::Function that I want to make sure 
is called once and only once before destruction.  I wouldn’t mind adding a 
WTF::Callback subclass that just asserts that it has been called once.  That 
would’ve prevented some bugs, too, but not every use of WTF::Function has such 
a requirement.

> On Jun 13, 2017, at 12:31 PM, Chris Dumez  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  <mailto:achristen...@apple.com>> wrote:
> 
>> 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.
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>> <https://lists.webkit.org/mailman/listinfo/webkit-dev>

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

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

[Alex Christensen]

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.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Alex Christensen]

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
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] ccache on mac

[Alex Christensen]

It would be nice if we could just get the CMake built WebKit working with 
run-safari and run-webkit-tests.  That’s something I’ve been meaning to do for 
a while but haven’t gotten around to it.  Something is wrong with the xpc 
service locations and plists, but I think everything else should be ok since 
run-minibrowser works fine with WebKit1.  Let me know if you want to help out 
with this approach and I’ll give you more details

> On May 8, 2017, at 6:39 AM, Ben Kelly  wrote:
> 
> On Mon, May 8, 2017 at 12:32 AM, youenn fablet  > wrote:
> I had this setup working a year or so ago. I was using the regular Mac "make" 
> build.
> 
> Le dim. 7 mai 2017 à 19:28, Ben Kelly  > a écrit :
> Hi all,
> 
> Does anyone have ccache (or an equivalent) working with local webkit builds 
> on mac?  I've spent the last couple of days trying to figure out, but have 
> not had much luck.
> 
> I've installed ccache via homebrew and its in my path.
> 
> Did the same. I had to ensure clang used by Xcode was the ccache proxy.
> Don't remember whether just setting CC/CXX in the command line works.
> When running make, you can see which clang is used.
> Maybe setting CC/CXX in Source/WebCore/Configurations/Base.xcconfig would do 
> the trick (for WebCore).
> 
> I guess I'm hesitant to fiddle with Base.xcconfig because I don't want to 
> accidentally include those changes in patches, etc.
> 
> What is the syntax for overriding CC/CXX on the command line with 
> build-webkit?  (Or for the make build, although its unclear how to configure 
> that.)
> 
> I guess I was also hoping there was some way to specify a 
> 'user-override.xcconfig' that the webkit build would try to pull-in 
> automatically where this stuff could be set.
> 
> Thanks.
> 
> Ben
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Alex Christensen]

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 !integerValue 
but I don’t have strong feelings about it.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Alex Christensen]

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 optimization to not lose performance benefits of 
inlining functions in headers.
2) Use distributed build tools and caches to cover up the problem.  WebKit 
would still be prohibitively hard to compile for people without lots of 
expensive computers, but we could greatly improve the productivity of large 
teams.
3) Use C++ modules
4) Put more commonly included headers into precompiled headers
5) I remember somebody claiming a few years ago that replacing #include 
“Something.h” with #include “path/to/Something.h” reduced compile times because 
it required fewer include paths, but I don’t think anybody has measured the 
improvement recently.
6) Optimize the compilers we use

We should look into all of these and more.  Compiling WebKit also uses a lot of 
memory, and our binary size continues to increase.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Alex Christensen]

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 organize things 
in a supportable way as positive.

I don’t think we should just use the C API as it is.  We want to eventually 
remove it completely.  If we do upstream WPE, I propose doing something like 
one of the following:
1. We could make a new C API that more closely mirrors the Cocoa API, to which 
we only add things we have committed to support.  This should be done in 
collaboration with the existing API owners.
2. We could mark parts of the existing C API as part of the API we have 
committed to maintaining.  There is a lot of messy stuff in the existing C API 
we eventually want to remove even before we remove the whole thing (old client 
versions, testing-only functions, private functions that access things we want 
to eventually organize differently, etc.).  For example, a lot of the things in 
WKContextPrivate.h should be moved from a multi-process-global approach to a 
WKWebView/WKPage-based organization.  The basic concepts are here to stay, 
though.
3. Have third parties who use the API just deal with whatever changes we throw 
at them.  This could be viable if there were only a few small groups using the 
API, but it would hinder innovative use of the API.  We might want to reserve 
the right to make API breaking changes anyway, though.

> On Apr 21, 2017, at 4:48 AM, z...@falconsigh.net wrote:
> 
> Hi,
> 
> the WebKit team at Igalia would like to propose upstreaming the WPE port
> of WebKit, taking on the duty to maintain it alongside the GTK+ port.
> 
> The WPE port started in 2014 as the 'WebKit for Wayland' project inside
> Igalia [1].  The port was derived from the GTK+ port, but avoided
> dependency on any GUI toolkit.  It relied on the Wayland display
> protocol for on-screen presentation.  That dependency was later dropped
> in favor of using generic interfaces to adapt to different
> platform-specific presentation systems.  This allows any vendor to
> simply provide the necessary backend implementations that are tailored
> to their platform.
> 
> The port is intended to be the Web platform engine of choice for
> embedded Linux systems.  Since late 2014 Igalia has been sponsored by
> Metrological to further develop the WPE port, targeting primarily
> various set-top box platforms.  Miguel Gomez blogged about this effort
> back in December [2].  The port can also address other embedded use
> cases, for instance in-vehicle infotainment or digital signage.
> 
> The GTK+ and WPE ports mostly have the same dependencies except for the
> GTK+ toolkit library.  That enables the two ports to already share a lot
> of code.  The biggest difference between the two is that the WPE port
> exposes the WebKit2 C API, while the GTK+ port exposes a GObject-based
> API.  Apart from that, the maintainers' plan is to further align the two
> ports as much as possible, ideally simply stacking the GTK+ port on top
> of WPE, with only a few additional tweaks for GTK+ integration.  This
> would lessen the maintenance burden for both ports and the project as a
> whole.
> 
> The WebKit team at Igalia thinks this port is on stable footing and has
> solid prospects for the future.  That's why we'd like to join the
> upstream community and continue our work there.
> 
> The patch with the port changes is in bug #171110 [3].  We have existing
> x86_64 buildbot configurations [4] that we would have to port over to
> the webkit.org build master.  We're planning further builder and tester
> configurations for ARM architectures in the future.  Layout test
> baselines would be landed separately.  (Those too would be subject to
> alignment with the GTK+ port.)
> 
> We're happy to address any questions or considerations.
> 
> Regards,
> Zan
> 
> [1]
> https://lists.webkit.org/pipermail/webkit-dev/2014-December/027087.html
> [2]
> https://blogs.igalia.com/magomez/2016/12/19/wpe-web-platform-for-embedded/
> [3] https://bugs.webkit.org/show_bug.cgi?id=171110
> [4] https://build-webkit.igalia.com/waterfall?category=WPE
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] EFL port?

[Alex Christensen]

> 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 and makes WebKit better 
organized without holding back our development.

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

Re: [webkit-dev] EFL port?

[Alex Christensen]

Are there enough people working on EFL that we could ping someone with a 
desired architecture improvement and have them do significant code redesign in 
a reasonable amount of time?  We can add stubs and do minor things blindly, but 
sometimes bigger tasks require cooperation.  For example, 
https://bugs.webkit.org/show_bug.cgi?id=167096 
 should also be done on the EFL 
WebGL implementation.
> On Feb 13, 2017, at 3:08 AM, Gustavo Sverzut Barbieri 
>  wrote:
> 
> Hi guys,
> 
> I have a small team working with WebKit-EFL as well, we're working on
> a different platform supported by EFL but not WebKit-EFL, so it's a
> series of minor patches to allow WebKit-EFL to run on Fbdev and
> without GL stack.
> 
> Patches will reach bugs.webkit.org soon.
> 
> 
> On Sat, Feb 11, 2017 at 2:10 AM, Joonghun Park  wrote:
>> Hi, Anders.
>> 
>> 
>> You could count me as a member of EFL port too.
>> 
>> I couldn't get in touch with EFL port because of some internal works,
>> 
>> but I'm planning to work in it.
>> 
>> 
>> Some other people of EFL port is in the same situation, but I think they'll
>> get back sooner or later.
>> 
>> 
>> 
>> - Joonghun (jh718.p...@samsung.com)
>> 
>> 
>> 
>> 
>> 
>> From: webkit-dev-boun...@lists.webkit.org
>>  on behalf of Anders Carlsson
>> 
>> Sent: Friday, February 10, 2017 6:21 PM
>> To: Gyuyoung Kim
>> Cc: WebKit-Dev Development
>> Subject: Re: [webkit-dev] EFL port?
>> 
>> Hi,
>> 
>> Are you the only one working on the EFL port?
>> 
>> - Anders
>> 
>> On Feb 10, 2017, at 1:40 AM, Gyuyoung Kim  wrote:
>> 
>> Hello,
>> 
>> To be honest, very few people have worked for EFL port recently. In my case
>> it was hard to maintain EFL port because of internal work.
>> However I have a plan to improve EFL port after I finish the work. Even I
>> opened a website for EWebKit. http://www.ewebkit.org.
>> Besides I released EWebKit 1.18 version[1] for EFL 1.18 official release.
>> Could you give me more time for EFL port ?
>> 
>> Gyuyoung.
>> 
>> 
>> [1] EWebKit 1.18 release announcement.
>> 
>> https://phab.enlightenment.org/w/efl_and_elementary_1_18_release_announcement/
>> 
>> EWebkit
>> 
>> Together with this release we are happy to announce that the EWebkit team is
>> doing a
>> release with their work matching the efl 1.18.
>> It contains various webkit core as well as EWebkit specific enhancements.
>> See the
>> NEWS file for details and the http://www.ewebkit.org page for further
>> instructions on
>> building. We hope to keep future releases of EWebkit aligned with the EFL
>> release schedule.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Fri, Feb 10, 2017 at 9:42 AM, Anders Carlsson  wrote:
>>> 
>>> Hello,
>>> 
>>> Looks like the EFL port isn’t really being worked on anymore. Is this
>>> true? Can we rip it out?
>>> 
>>> - Anders
>>> ___
>>> 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
>> 
> 
> 
> 
> -- 
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --
> MSN, GTalk, FaceTime: barbi...@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (16) 99354-9890
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Alex Christensen]

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 on CSSParser::findURI() particularly and 
> CSSParser::realLex() other related functionality in CSSParser.cpp - hope I am 
> on right track. ;-)
> 
> Please let me know if I should be looking at some other functionality as well 
> to resolve this issue.
> 
> Thanks!
> Atul.
> 
> On Fri, Feb 3, 2017 at 2:33 PM, Atul Sowani  > wrote:
> Hi,
> 
> I came across an issue in qtwebkit CSS parser while working on a PhantomJS 
> crash. The issue seems to be with parsing of  type 
> elements in an HTML page. What I observed is that the parser is trying to 
> interpret the value for href given inside double-quotes. The value contains a 
> "-" (e.g. "http://some.domain.com/some-page-etc-etc 
> "). The "-" sign is being 
> interpreted as minus and then things go wrong. In another case I found that 
> "\g" embedded in the value (e.g. 
> "http://some.domain.com/some-page/global/something 
> ") is also creating 
> issues. In essence, the parser is trying to interpret the value, which I 
> believe, it should not.
> 
> I am willing to dive further into it to debug and fix the issue, but looking 
> at the complexity and size of WebCore, I think I would benefit a lot to 
> expedite a fix, if I could get some tips about which code area/functionality 
> I should specifically focus in the WebCore. Looking forward to some help in 
> this regard.
> 
> Thanks,
> Atul.
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Alex Christensen]

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  wrote:
> 
> On Wed, 2017-01-18 at 12:17 -0800, Myles C. Maxfield wrote:
>> Static (At least for the Xcode projects. I imagine the cmake-based
>> projects could do whatever they want here).
> 
> For GTK+ we really want static as well, we do not want a new shared
> library. So no difference here.
> 
> Michael
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Alex Christensen]

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.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Alex Christensen]

>> 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 reference kept alive by the caller, so 
this change caused a subtle use-after-free bug.  See 
https://trac.webkit.org/changeset/201345 


Also when we change what a return type is but there are call sites that use 
auto, we may miss checking to see if everything is ok at a call site that 
compiles successfully even though it has different meaning.

I’ll admit auto has grown on me quite a bit since I wrote 
https://lists.webkit.org/pipermail/webkit-dev/2014-January/026000.html 


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

Re: [webkit-dev] update GCC version?

[Alex Christensen]

> 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 bump would be minimal.
>>> https://gcc.gnu.org/projects/cxx-status.html#cxx14
>> We would need to redefine our dependencies policy:
>> 
>> https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy
>> 
>> We just recently crafted that policy. I kinda like it because it
>> provides a clear formula for deciding whether a compiler is too new to
>> be required or not. It means we would support GCC 4.9 until roughly
>> next spring/summer, one year from the next Debian release. We could
>> either (a) drop Debian from the policy, which I support doing anyway
>> because it does not take our security updates, or we could (b) define
>> the policy in terms of runtime dependencies, rather than build
>> dependencies (which I think Carlos Garcia wanted to do anyway). Either
>> way makes it more likely that distributions will get cut off and choose
>> to not provide WebKit security updates. I would prefer not to do (b),
>> because in practice distributions will just not take our updates if
>> they can't use their default compiler.
>> 
> 
> I strongly oppose to do (a). Also, it is false that Debian doesn't take
> our updates. They take our updates in the backports repository for stable.
> 
> I also don't like (b).
> 
> Another idea is: (c) Drop the "one year after the release" requirement.
> Which means that we could update to minimum GCC version to 5.3 (the one
> in last Ubuntu LTS) when Debian 9 is released (which hopefully is
> expected to happen around the middle of 2017).
> 
> A date that I guess will be near enough to when VS2017 is released.
A mid-2017 upgrade would be quite reasonable.
> 
> This will mean that instead of supporting up to 3-year old dependencies
> we will only support up to 2-year old ones.
> I'm not particular enthusiast about this, but I'm ready to understand
> that supporting 3-year old dependencies is not realistic on a project
> like WebKit.
> 
>> Keep in mind that for a distro to upgrade from GCC 4.9 -> 5.0 is weeks
>> of effort unless you build GCC with the flag that turns on the old C++
>> ABI, but you have to switch to the new ABI eventually, so might as well
>> do it at the same time. I have to support WebKit for a distribution
>> that has been delaying the upgrade for this reason. GCC upgrades are
>> expensive and not fun. Even turning off the ABI switch, upgrading GCC
>> means lots of obscure C++ build failures in packages you're not
>> familiar with.
>> 
>> Michael
> 
> Another (maybe easier) way forward for building it on distros that have
> libstdc++ < 5.0 is to use clang.
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] update GCC version?

[Alex Christensen]

> On Jan 7, 2017, at 11:39 AM, Konstantin Tokarev  wrote:
> 
> 
> 
> 07.01.2017, 22:30, "Alex Christensen" :
>> 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 verified it compiles successfully in VS2017RC, 
>> but it does not compile successfully in the minimum supported GCC version on 
>> linux because of lack of support for C++14 extended constexpr (see 
>> https://isocpp.org/wiki/faq/cpp14-language#extended-constexpr )
>> 
>> We are not ready to require VS2017 just yet.  It hasn’t even been fully 
>> released.  But there are many C++14 features that are not supported in 
>> VS2015 (see https://msdn.microsoft.com/en-us/library/hh567368.aspx and 
>> https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes ) and 
>> we would like to use these features in WebKit.
> 
> But how are you going to use these features before requiring VS2017?
We would not be able to.  This is a question about updating the GCC version 
after we require VS2017 which will probably be in the coming months.
> 
>> 
>> Would the linux community be able to increase the minimum supported GCC 
>> version?
>> ,
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> 
> -- 
> Regards,
> Konstantin

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

[webkit-dev] update GCC version?

[Alex Christensen]

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 verified it compiles successfully in VS2017RC, but it does not compile 
successfully in the minimum supported GCC version on linux because of lack of 
support for C++14 extended constexpr (see 
https://isocpp.org/wiki/faq/cpp14-language#extended-constexpr 
 )

We are not ready to require VS2017 just yet.  It hasn’t even been fully 
released.  But there are many C++14 features that are not supported in VS2015 
(see https://msdn.microsoft.com/en-us/library/hh567368.aspx 
 and 
https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes 
 ) and we 
would like to use these features in WebKit.

Would the linux community be able to increase the minimum supported GCC version?___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev