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

2022-11-10 Thread 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

2022-08-16 Thread 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
>>>> different process than the 

Re: [webkit-dev] InjectedBundle deprecation

2022-08-16 Thread 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/WebProcess/InjectedBundl

Re: [webkit-dev] InjectedBundle deprecation

2022-08-12 Thread 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

2022-08-12 Thread 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

2022-06-27 Thread 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

2022-06-01 Thread 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)

2022-03-23 Thread 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

2022-03-09 Thread 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

2022-02-21 Thread 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

2022-01-24 Thread 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

2022-01-21 Thread 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

2022-01-21 Thread 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

2022-01-05 Thread 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

2021-12-06 Thread 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

2021-12-06 Thread 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] Raw string literals

2021-11-17 Thread 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

2021-11-01 Thread 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

2021-05-05 Thread 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

2021-04-29 Thread 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

2021-04-29 Thread 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

2021-04-29 Thread 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

2021-04-28 Thread 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

2021-04-28 Thread 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

2021-04-06 Thread 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 separate sources of hint requests, 
> with the expectation that the 

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

2021-04-05 Thread 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


Re: [webkit-dev] User Agent Client Hints

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

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

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

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

2020-08-12 Thread 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

2020-08-12 Thread 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

2020-07-15 Thread 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

2020-06-18 Thread 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

2020-05-08 Thread 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]]

2020-01-14 Thread 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]]

2020-01-13 Thread 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)

2019-11-04 Thread 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

2019-09-27 Thread 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

2019-08-23 Thread 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

2019-08-16 Thread 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?

2019-06-20 Thread 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 > > 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 
>> 
>> Which WTF headers still should be in C++11?
>> 
>> - Fujii
>> ___
>> 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] What is the status of Network Error Logging and Reporting API?

2019-06-03 Thread 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

2019-05-28 Thread 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] C++17 is here. Should we use it?

2019-05-07 Thread 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?

2019-04-23 Thread 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?

2019-04-19 Thread 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

2019-03-21 Thread 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

2019-03-21 Thread 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

2019-02-27 Thread 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

2019-02-20 Thread 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 > > 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 >> > 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 >>> > wrote:
 
 Thanks for the opinion!
 
 Dan
 
 On Feb 20, 2019, at 7:26 AM, Saam Barati >>> > wrote:
 
> I prefer it as well.
> 
> - Saam
> 
> On Feb 20, 2019, at 6:58 AM, Chris Dumez  > wrote:
> 
>> I also prefer allowed returning void. 
>> 
>> Chris Dumez
>> 
>> On Feb 19, 2019, at 10:35 PM, Daniel Bates > > wrote:
>> 
>>> 
>>> 
>>> On Feb 19, 2019, at 9:42 PM, Ryosuke Niwa >> > wrote:
>>> 
 On Tue, Feb 19, 2019 at 8:59 PM Daniel Bates >>> > wrote:
 > 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();
 > }
 >
 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 strong opinion.
>>> 
 and Alex both expressed preferences for being able to return void,
>>> 
>>> I got this from Alex's message
>>> 
 and Saam pointed out that there is a lot of existing code which does 
 this. 
>>> 
>>> I did not get this. He wrote emphasis mine:
>>> 
>>> I've definitely done this in JSC. ***I don't think it's super 
>>> common***, but I've also seen code in JSC not written by me that also 
>>> does this.
>>> 
 Zalan also said he does this in his layout code.
>>> 
>>> I did not get this, quoting, emphasis mine:
>>> 
>>> I use this idiom too in the layout code. I guess I just prefer a more
>>> compact code.
>>> ***(I don't feel too strongly about it though)***
>>> 
>>> By the way, you even acknowledged that "WebKit ... tend[s] to have a 
>>> separate return.". So, I inferred you were okay with it. But from this 
>>> email I am no longer sure what your position is. Please state it 
>>> clearly.
>>> 
 - 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 mailing list
 

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

2019-02-07 Thread 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

2019-01-18 Thread 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

2019-01-15 Thread 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

2018-12-20 Thread 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

2018-12-17 Thread 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 are our libraries. We 

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

2018-12-17 Thread 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...@app

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

2018-12-17 Thread 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

2018-12-17 Thread 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

2018-12-08 Thread 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

2018-12-03 Thread 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

2018-11-29 Thread 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

2017-11-14 Thread 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

2017-10-23 Thread 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 <hupernike...@gmail.com> wrote:
> 
> 
> 
> On Oct 20, 2017 4:30 PM, "Alex Christensen" <achristen...@apple.com 
> <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

2017-10-20 Thread 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 <mcatanz...@igalia.com> wrote:
> 
> On Fri, Oct 20, 2017 at 3:30 PM, Alex Christensen <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. 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


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

2017-10-02 Thread 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

2017-09-27 Thread 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)

2017-08-30 Thread 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] Server Timing API

2017-08-17 Thread 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

2017-08-02 Thread 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

2017-07-12 Thread 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?

2017-06-23 Thread 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?

2017-06-13 Thread 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 <cdu...@apple.com> wrote:
> 
> We already have BlockPtr for passing a Function as a lambda block.
> 
> Chris Dumez
> 
> On Jun 13, 2017, at 12:29 PM, Alex Christensen <achristen...@apple.com 
> <mailto:achristen...@apple.com>> 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?

2017-06-13 Thread 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

2017-05-09 Thread 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] !!Tests for equality comparison

2017-04-28 Thread 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

2017-04-24 Thread 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

2017-04-21 Thread 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?

2017-02-14 Thread 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] CSS Parse error in element.

2017-02-03 Thread 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

2017-01-18 Thread 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

2017-01-12 Thread 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

2017-01-10 Thread 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?

2017-01-09 Thread 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?

2017-01-07 Thread Alex Christensen

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

2017-01-07 Thread 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


Re: [webkit-dev] WebKit build failed

2016-12-12 Thread Alex Christensen

> On Dec 12, 2016, at 4:30 AM, Konstantin Tokarev  wrote:
> 
> 
> 
> 12.12.2016, 12:25, "Plamen Dimitrov" :
>> Hi all, I am trying to build webkit wincairo 1) I've done 2, 3, 4, 5, 6, 7, 
>> 8, 9,10 and 13 from this list: 
>> https://webkit.org/webkit-on-windows/#installing-developer-tools 2) I've 
>> installed Ruby 2.0.0-p648 and DevKit-mingw64 from here: 
>> http://rubyinstaller.org/downloads/ 3) I've run "update-webkit"; 
>> "update-webkit --wincairo"; "update-webkit-wincairo-libs" from VS2015 native 
>> tool command prompt. And when I've run "build-webkit --wincairo --release" 
>> the build has failed with "C:\Program Files (x86)\Microsoft Visual Studio 
>> 14.0\VC\INCLUDE\type_traits(1469): error C2672: 'std::invoke': no matching 
>> overloaded function found" and "C:\Program Files (x86)\Microsoft Visual 
>> Studio 14.0\VC\INCLUDE\type_traits(1469): error C2893: Failed to specialize 
>> function template 'unknown-type std::invoke(_Callable &&,_Types &&...)'" 
>> Have you ever seen it before? Thank you in advance, Plamen.
I’ve never seen that build error before.  It’s possible there’s something wrong 
with your build configuration.  I would need more context than just this error 
message.  What file was being compiled when this error message was generated?  
Exactly what version of Visual Studio are you using?  Does your computer have 
other compilers installed that it might be using accidentally?  It is possible 
that the build was broken at the revision you tried, but I don’t think that is 
likely in this case.
>> ,
> 
> 
> Hi,
> 
> Unfortunately, it's quite possible that WinCairo does not build on some 
> arbitrary trunk revision. If you watch waterfall [1], you can often see 
> WinCairo bot failing to compile, and right now it's apparently having more 
> serious troubles and was put offline, so nobody working on other ports can 
> check if they introduce new build breaks for WinCairo.
I take the bot down occasionally and use it to verify fixes.  There were no 
serious troubles over the weekend, I just forgot to start it up again.  It 
should be working fine now.
> 
> The best option for you to proceed is to fix compilation error your self and 
> submit patches to bugzilla following usual procedure.
> 
> [1] https://build.webkit.org/waterfall
> 
> 
> -- 
> Regards,
> Konstantin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev



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


Re: [webkit-dev] WinCairo Maintainers

2016-09-26 Thread Alex Christensen
It is quite nice to be able to build everything completely from source in one 
place.  This allows Windows software distributors to have more control over 
PlatformToolsets to reduce the need for distributing multiple merge modules.  
Some companies also have policies that they can only distribute software that 
they built completely from source.
> On Sep 26, 2016, at 11:54 AM, Konstantin Tokarev <annu...@yandex.ru> wrote:
> 
> 
> 
> 26.09.2016, 21:46, "Alex Christensen" <achristen...@apple.com 
> <mailto:achristen...@apple.com>>:
>> Right now https://github.com/peavo/WinCairoRequirements 
>> <https://github.com/peavo/WinCairoRequirements> is the best maintained 
>> repository containing all the requirements, even if Per isn’t maintaining it 
>> any more.  If you fork it and add fixes, then yours would become the best 
>> maintained repository of those requirements.  I think it would be great if 
>> you did this.
> 
> It may make sense to use conan.io <http://conan.io/> to fetch dependencies. 
> There are ready to use packages for ICU, libpng, libjpeg-turbo, openssl, 
> libcurl, sqlite. At least this approach allow to decentralize maintenance and 
> compilation of binaries for each individual library.
> 
>>> On Sep 26, 2016, at 11:38 AM, Olmstead, Don <don.olmst...@sony.com> wrote:
>>> 
>>> I was wondering who was in charge of WinCairo now. We at Sony have been 
>>> using WinCairo to land anything that isn’t specific to our own internal 
>>> port but we don’t have any intention to ship anything using it.
>>> 
>>> We have some outstanding patches for the GitHub requirements 
>>> repository,https://github.com/peavo/WinCairoRequirements, that perarne was 
>>> running but he informed me that he will not be maintaining it going 
>>> forward. I was thinking about making a WinCairo org on GitHub and then 
>>> pushing the contents of that repo to it but I wanted to ask beforehand.
>>> 
>>> ___
>>> 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
> 
> 
> -- 
> Regards,
> Konstantin

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


Re: [webkit-dev] WinCairo Maintainers

2016-09-26 Thread Alex Christensen
Right now https://github.com/peavo/WinCairoRequirements 
 is the best maintained 
repository containing all the requirements, even if Per isn’t maintaining it 
any more.  If you fork it and add fixes, then yours would become the best 
maintained repository of those requirements.  I think it would be great if you 
did this.
> On Sep 26, 2016, at 11:38 AM, Olmstead, Don  wrote:
> 
> I was wondering who was in charge of WinCairo now. We at Sony have been using 
> WinCairo to land anything that isn’t specific to our own internal port but we 
> don’t have any intention to ship anything using it.
>  
> We have some outstanding patches for the GitHub requirements 
> repository,https://github.com/peavo/WinCairoRequirements 
> , that perarne was running but 
> he informed me that he will not be maintaining it going forward. I was 
> thinking about making a WinCairo org on GitHub and then pushing the contents 
> of that repo to it but I wanted to ask beforehand.
>  
> ___
> 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] [CMake] Bumping cmake_minimum_required

2016-09-23 Thread Alex Christensen
Updating to CMake 3.2 would also not cause us a problem.
> On Sep 23, 2016, at 1:14 AM, Konstantin Tokarev <annu...@yandex.ru> wrote:
> 
> 
> 
> 23.09.2016, 00:59, "Alex Christensen" <achristen...@apple.com 
> <mailto:achristen...@apple.com>>:
>> Requiring CMake 3.0 would not cause us a problem.
> 
> Looks like anyone is fine with updating CMake to 3.0, however Fujii Hironori 
> is asking about CMake 3.2, and AFAIU updating to 3.0 won't help for his patch.
> .
> 
>>>  On Sep 21, 2016, at 5:06 AM, Michael Catanzaro <mcatanz...@igalia.com> 
>>> wrote:
>>> 
>>>  On Wed, 2016-09-21 at 18:09 +0900, Fujii Hironori wrote:
>>>>  Ubuntu 14.04 has GCC 4.8 and build fails with a following error
>>>>  message.
>>> 
>>>  Hm that's a good point. Looks like that ship has already sailed. No, we
>>>  don't want to support GCC 4.8. Our dependency policy is only a month
>>>  old, and we just didn't notice this yet. :)
>>> 
>>>  In that case, we're fine with requiring CMake 3.0 (the version in
>>>  Debian Jessie), but I think Apple is using a lower versions than that
>>>  so we need to hear from them. Alex?
>>> 
>>>  Michael
>> 
>> ___
>> 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


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

2016-09-22 Thread Alex Christensen
Requiring CMake 3.0 would not cause us a problem.
> On Sep 21, 2016, at 5:06 AM, Michael Catanzaro  wrote:
> 
> On Wed, 2016-09-21 at 18:09 +0900, Fujii Hironori wrote:
>> Ubuntu 14.04 has GCC 4.8 and build fails with a following error
>> message.
> 
> Hm that's a good point. Looks like that ship has already sailed. No, we
> don't want to support GCC 4.8. Our dependency policy is only a month
> old, and we just didn't notice this yet. :)
> 
> In that case, we're fine with requiring CMake 3.0 (the version in
> Debian Jessie), but I think Apple is using a lower versions than that
> so we need to hear from them. Alex?
> 
> Michael

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


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

2016-09-06 Thread Alex Christensen
I think “take" is a fine word to indicate that you are taking a value from a 
HashSet, just like “add" indicates you are adding to the set and remove 
indicates you are “removing" from the set.  It’s true that in all these cases 
the caller is doing the thing, not the object, but it makes sense in my mind.  
An alternative would be to change set.add(value) to a static function 
HashSet::add(set, value), set.remove(value) to HashSet::remove(set, value), and 
set.take(value) to HashSet::take(set, value), etc.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


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

2016-03-30 Thread Alex Christensen
I agree that it would be better to have one approach to copying forwarding 
headers, but there is a fundamental disagreement between the needs of the 
ports.  Windows needs the entire header to be copied into the forwarding 
directory because some internal builds are built without the other directories 
existing, such as JavaScriptCore being built without WTF being right next to 
it.  This will not change.  Linux ports want everything to be fast and 
automatic, so their forwarding headers are just a small file that #includes the 
relative path to the file being included.

Yesterday was a rough day for the CMake ports because I made WebCore more than 
one static library.  I think I know what’s wrong with the headers in clean 
builds and I’ll fix it soon.
> On Mar 30, 2016, at 10:06 AM, Konstantin Tokarev  wrote:
> 
> 
> 
> 30.03.2016, 19:47, "Brent Fulgham"  >:
>> This is happening because “Font.h” is referring to 
>> “”, which doesn’t always exist on Windows at the 
>> time the file is compiled. The CoreGraphicsSPI.h file lives in 
>> “WebCore/platform/spi/cg/CoreGraphicsSPI.h”, and can be found with a normal 
>> ‘#include “CoreGraphicsSPI.h”. It’s only after a post-build step copies the 
>> file to “DerivedSources/ForwardingHeaders/WebCore/CoreGraphicsSPI.h” that 
>> the ‘#include ” form works.
>> 
>> When a non-clean build is performed, this is fine, so EWS probably works 
>> properly most of the time. But if something prompts it to clean the build 
>> output, the file doesn’t exist and the build fails, improperly blaming the 
>> current patch.
>> 
>> I’ll talk to Alex about the copy phase of these headers and see if we can 
>> get this into proper position earlier.
> 
> Actually, for now we have 3 independent mechanisms of header copying with 
> CMake build:
> 
> 1. WEBKIT_CREATE_FORWARDING_HEADERS() CMake macro
> 2. Custom pre- and post-build commands which invoke xcopy (obviously 
> Windows-only)
> 3. Script Source/WebKit2/Scripts/generate-forwarding-headers.pl which AFAIU 
> looks into source files and determines which headers do actually need to be 
> copied, than copies them.
> 
> IMO it would be better to use one approach, and it looks like that 
> generate-forwarding-headers.pl is the most powerful option.
> 
>> 
>> Thanks,
>> 
>> -Brent
>> 
>>>  On Mar 30, 2016, at 9:28 AM, Alexey Proskuryakov  
>>> wrote:
>>> 
>>>  They fail like this: 
>>> https://webkit-queues.webkit.org/queue-status/win-ews/bots/ews202https://webkit-queues.webkit.org/results/1069527
>>> 
>>>  
>>> c:\cygwin\home\buildbot\webkit\source\webcore\platform\graphics\Font.h(57): 
>>> fatal error C1083: Cannot open include file: 'WebCore/CoreGraphicsSPI.h': 
>>> No such file or directory (compiling source file 
>>> C:\cygwin\home\buildbot\WebKit\Source\WebCore\DerivedSources.cpp) 
>>> [C:\cygwin\home\buildbot\WebKit\WebKitBuild\Release\Source\WebCore\WebCoreDerivedSources.vcxproj]
>>> 
>>>  It's quite surprising that the build passes after rolling out a patch, 
>>> thus making EWS think that the patch is to blame.
>>> 
>>>  - Alexey
>>> 
  30 марта 2016 г., в 9:20, Brent Fulgham  написал(а):
 
  Aside from ews206 being offline for some reason, all bot seem to be 
 running without any errors.
 
  Can you point me at a couple of the patches you were looking at? I 
 spot-checked a couple in the Review Queue and they seemed to be failing 
 for legitimate problems with the patches.
 
  Thanks,
 
  -Brent
 
>  On Mar 30, 2016, at 9:04 AM, Brent Fulgham  wrote:
> 
>  Looking now.
> 
>  -Brent
> 
>>  On Mar 30, 2016, at 9:02 AM, Darin Adler  wrote:
>> 
>>  Every patch I look at has a red bubble for Windows on EWS. Is someone 
>> planning on fixing this?
>> 
>>  — 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 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
> 
> -- 
> Regards,
> Konstantin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 

Re: [webkit-dev] Building Webkit on Windows

2016-02-29 Thread Alex Christensen
Rakesh, you are building the AppleWin port of WebKit, which only has 32-bit 
binaries available, but you probably want to use the WinCairo port because the 
license of WebKitSupportLibrary.zip says you’re not allowed to redistribute it. 
 To build the WinCairo port, you will need to run update-webkit --wincairo and 
build-webkit --wincairo --64-bit.

This is not the source of your build failure, though.  It looks like you have 
your gperf executable inside of C:\Program Files… somewhere, and I believe we 
have never had anyone build WebKit with a configuration like this.  I think the 
solution is to put quotes around the %s at the very end of 
Source/WebCore/platform/network/create-http-header-name-table.  There might be 
a few more places where this is needed.  Could you please file a bug a 
bugs.webkit.org with a patch if you get it working?

> On Feb 27, 2016, at 2:01 AM, Rakesh Sadhu <rakeshsa...@hotmail.com> wrote:
> 
> 
> Hi Thomas, 
> Thank for your  answer .
> However my build suddenly fails and I notice , its creating 32 bit binaries .
> I am attaching a build log file here .
> 
> regards
> RSadhu
> 
> 
> To: achristen...@apple.com
> From: thomas.brodt.li...@porabo.ch
> Date: Fri, 26 Feb 2016 09:15:06 +0100
> CC: webkit-dev@lists.webkit.org
> Subject: Re: [webkit-dev] Building Webkit on Windows
> 
> Hi Alex
> 
> thank you for your prompt answer. That is good news because in the past I had 
> different difficulties in setting up a functional environment with several 
> trial and error steps inbetween, although I tried to exactly follow the 
> installation guide. I tend to create a virtual machine for a reliable 
> building environment, so with my next one I will try without the cygwin 
> installation. 
> 
> We use Webkit via COM interface on Windows in our application here, so I 
> build rather infrequently, and with a working build, we then can live for 
> some time. But for our use we would need 32bit dependencies, and if I 
> understood correctly, there are currently only 64bit available. That doesn't 
> matter at the moment, but when I am ready for our next build, I would ask 
> again if you don't mind.
> 
> Thanks for your help!
> 
> Thomas
> 
> Am 25.02.2016 um 19:17 schrieb Alex Christensen:
> That also applies to the WinCairo port.  I don’t think you’ll need GNU Make 
> any more now that we use CMake for Windows.  You also shouldn’t need to 
> install iTunes to build and run WinCairo.  With WinCairo, you will also need 
> the WinCairoDependencies.zip which you can get by running 
> Tools/Scripts/update-webkit-wincairo-libs.  Right now, only the 64-bit 
> dependencies are included in that zip, but let me know if you need 32-bit 
> dependencies.  They are from  
> <https://github.com/peavo/WinCairoRequirements>https://github.com/peavo/WinCairoRequirements
>  <https://github.com/peavo/WinCairoRequirements>  Then you should be able to 
> build with Tools/Scripts/build-webkit --wincairo --64-bit
> 
> We really should update the instructions on webkit.org <http://webkit.org/> 
> On Feb 25, 2016, at 12:17 AM, Thomas Brodt <thomas.brodt.li...@porabo.ch 
> <mailto:thomas.brodt.li...@porabo.ch>> wrote:
> 
> Does this also apply for the WinCairo port? Or does this port still require 
> cygwin?
> 
> Thomas
> 
> Am 24.02.2016 um 20:32 schrieb Alex Christensen:
> Those instructions are out of date.  The most up-to-date instructions about 
> building on Windows are  
> <http://trac.webkit.org/wiki/WindowsWithoutCygwin>http://trac.webkit.org/wiki/WindowsWithoutCygwin
>  <http://trac.webkit.org/wiki/WindowsWithoutCygwin>
> 
> On Feb 24, 2016, at 9:57 AM, Myles C. Maxfield <mmaxfi...@apple.com 
> <mailto:mmaxfi...@apple.com>> wrote:
> 
> What is the error you are seeing?
> 
> On Feb 24, 2016, at 9:26 AM, Rakesh Sadhu <rakeshsa...@hotmail.com 
> <mailto:rakeshsa...@hotmail.com>> wrote:
> 
> Hello ,
> I am trying to build webkit on Windows .
> I am following  steps from  
> <https://webkit.org/building-webkit-on-windows/>https://webkit.org/building-webkit-on-windows/
>  <https://webkit.org/building-webkit-on-windows/>
> However I am unable to find a way to build webkit using MSVS2015 or  Cygwin .
> Can anyone guide here please?
> regards
> RSadhu
> ___
> 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>
&

Re: [webkit-dev] Building Webkit on Windows

2016-02-25 Thread Alex Christensen
That also applies to the WinCairo port.  I don’t think you’ll need GNU Make any 
more now that we use CMake for Windows.  You also shouldn’t need to install 
iTunes to build and run WinCairo.  With WinCairo, you will also need the 
WinCairoDependencies.zip which you can get by running 
Tools/Scripts/update-webkit-wincairo-libs.  Right now, only the 64-bit 
dependencies are included in that zip, but let me know if you need 32-bit 
dependencies.  They are from https://github.com/peavo/WinCairoRequirements 
<https://github.com/peavo/WinCairoRequirements>  Then you should be able to 
build with Tools/Scripts/build-webkit --wincairo --64-bit

We really should update the instructions on webkit.org <http://webkit.org/> 
> On Feb 25, 2016, at 12:17 AM, Thomas Brodt <thomas.brodt.li...@porabo.ch> 
> wrote:
> 
> Does this also apply for the WinCairo port? Or does this port still require 
> cygwin?
> 
> Thomas
> 
> Am 24.02.2016 um 20:32 schrieb Alex Christensen:
>> Those instructions are out of date.  The most up-to-date instructions about 
>> building on Windows are  
>> <http://trac.webkit.org/wiki/WindowsWithoutCygwin>http://trac.webkit.org/wiki/WindowsWithoutCygwin
>>  <http://trac.webkit.org/wiki/WindowsWithoutCygwin>
>> 
>>> On Feb 24, 2016, at 9:57 AM, Myles C. Maxfield <mmaxfi...@apple.com 
>>> <mailto:mmaxfi...@apple.com>> wrote:
>>> 
>>> What is the error you are seeing?
>>> 
>>> On Feb 24, 2016, at 9:26 AM, Rakesh Sadhu < 
>>> <mailto:rakeshsa...@hotmail.com>rakeshsa...@hotmail.com 
>>> <mailto:rakeshsa...@hotmail.com>> wrote:
>>> 
>>>> Hello ,
>>>> I am trying to build webkit on Windows .
>>>> I am following  steps from  
>>>> <https://webkit.org/building-webkit-on-windows/>https://webkit.org/building-webkit-on-windows/
>>>>  <https://webkit.org/building-webkit-on-windows/>
>>>> However I am unable to find a way to build webkit using MSVS2015 or  
>>>> Cygwin .
>>>> Can anyone guide here please?
>>>> regards
>>>> RSadhu
>>>> ___
>>>> 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 <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 mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Building Webkit on Windows

2016-02-24 Thread Alex Christensen
Those instructions are out of date.  The most up-to-date instructions about 
building on Windows are http://trac.webkit.org/wiki/WindowsWithoutCygwin

> On Feb 24, 2016, at 9:57 AM, Myles C. Maxfield  wrote:
> 
> What is the error you are seeing?
> 
> On Feb 24, 2016, at 9:26 AM, Rakesh Sadhu  > wrote:
> 
>> Hello ,
>> I am trying to build webkit on Windows .
>> I am following  steps from https://webkit.org/building-webkit-on-windows/ 
>> 
>> However I am unable to find a way to build webkit using MSVS2015 or  Cygwin .
>> Can anyone guide here please?
>> regards
>> RSadhu
>> ___
>> 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] [cmake] Proposal: Move commonly used platform-dependent files in WebCore to .cmake include files.

2016-02-09 Thread Alex Christensen
Let’s go for it.  Less duplication is a good thing.  The only downside is the 
occasional “Which CMake file do I add this to?” but that should be just as 
straightforward as adding the file to multiple platform cmake files, if not 
more.
> On Feb 9, 2016, at 10:44 AM, Michael Catanzaro  wrote:
> 
> I'm curious what Martin and Alex think about this. It seems fine to me;
> the downside is there are more CMake files to maintain, the upside is
> the big ones should be slightly smaller, and we can reduce duplication
> between PlatformEFL.cmake and PlatformGTK.cmake.
> 
> 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] Wincairo support for wss:// urls with websockets

2016-01-04 Thread Alex Christensen
Sorry for the late reply.

That repository *should* have no significant WebKit-specific changes, but it 
has some build fixes and probably some other minor changes.  I’m aware of one 
fix to pixman to support Windows XP, which is no longer supported by WebKit.  
The repository should be just copies of the upstream source with some 
modifications to the build system or a new build system to build in the same 
place as the other projects and the solution manages inter-project 
dependencies.  Things such as config.h’s and generated assembly of OpenSSL are 
checked in to the repository so it can be built with just Visual Studio 2015 
and nasm without using MinGW (although I think it could be made to use masm to 
just require Visual Studio).  Brent did most of the work in that repository and 
knows more about it.

WinCairo.sln should build everything and package it.

> On Dec 28, 2015, at 5:04 PM, Isaac Devine <is...@devinesystems.co.nz> wrote:
> 
> Hi Alex,
> 
> I'm wanting to upgrade the following:
> - curl to 7.46.0
> - openssl to  1.0.2d
> 
> The latest curl package comes with Visual studio 2015 projects, though their 
> configurations are different from the ones available in the WinCairo.sln 
> project (it has seperate configurations for openssl, wolfssl, winsppi, dll, 
> lib etc)
> Is the intention that WinCario.sln builds everything and packages it or would 
> it be acceptable to build the different projects individually? 
> 
> Thanks,
> Isaac
> 
> 
> On 29 December 2015 at 09:50, Isaac Devine <is...@devinesystems.co.nz 
> <mailto:is...@devinesystems.co.nz>> wrote:
> How are the webkit specific changes seperated from the upstream source in 
> that repository?
> 
> Is there a directory of patches somewhere?
> 
> On 29 December 2015 at 09:27, Alex Christensen <achristen...@apple.com 
> <mailto:achristen...@apple.com>> wrote:
> If you want to send a pull request for that, too, I would gladly accept it.  
> Also, the output needs to be called libicuuc and libicuin instead of icuuc 
> and icuin to match the AppleWin port, and it would be nice if it built it 
> into the same bin64, bin32, lib64, lib32, and include directories as 
> everything else.
> 
>> On Dec 28, 2015, at 12:13 PM, Isaac Devine <is...@devinesystems.co.nz 
>> <mailto:is...@devinesystems.co.nz>> wrote:
>> 
>> Thanks,
>> 
>> If you are updating to ICU 56.1, it doesn't build in visual studio 2015.
>> 
>> A patch that fixes this can be found at:
>> http://bugs.icu-project.org/trac/ticket/11822 
>> <http://bugs.icu-project.org/trac/ticket/11822>
>> 
>> 
>> On 29 December 2015 at 08:37, Alex Christensen <achristen...@apple.com 
>> <mailto:achristen...@apple.com>> wrote:
>> Send a pull request to 
>> https://github.com/achristensen07/WinCairoRequirements 
>> <https://github.com/achristensen07/WinCairoRequirements> or just send me an 
>> email with the changes you want to include.  I’m right in the middle of 
>> updating icu in that repository, so you might want to go back to 
>> a9b631e1146a696dc81b584c837ccfb7db5524b9
>> 
>> Alex
>> 
>>> On Dec 21, 2015, at 4:44 PM, Isaac Devine <is...@devinesystems.co.nz 
>>> <mailto:is...@devinesystems.co.nz>> wrote:
>>> 
>>> Hi all,
>>> 
>>> I have a patch that enables support for wss:// urls for websockets with the 
>>> wincairo port.
>>> 
>>> I haven't created a bug and attachment yet because it requires curl 7.45, 
>>> which is newer than the curl that the current wincairo build depends on. 
>>> 
>>> How do I go about proposing updates of the curl dependency?
>>> 
>>> Thanks,
>>> Isaac
>>> 
>>> ___
>>> 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>
>> 
>> 
>> 
> 
> 
> 
> 
> -- 
> Isaac Devine
> Director
> Devine Systems Limited
> 
> +64 21 1700 929
> 

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


Re: [webkit-dev] DRT Test case video-canvas-drawing-output.html failed on Win Enviornment

2016-01-04 Thread Alex Christensen
Are you using the WinCairo port, which uses MediaFoundation for video, or the 
AppleWin port, which uses AVFoundation for video?  Linux uses GStreamer for 
video.  These are all completely different implementations of video players.  
It is quite possible there is a bug in one of them that needs to be fixed.

Is there one pixel whose value that is different, or many pixels that are 1 
unit different?  That particular test seems to have a tolerance of 2.
I think the colorspace management should be the same on all ports, but I’m not 
sure.

> On Jan 2, 2016, at 9:20 PM, ankit srivastav  wrote:
> 
> Hi All,
> 
> Working on a webkit DRT test case media/video-canvas-drawing-output.html .
> Test is getting failed on Win environment with only 1 pixel value difference.
> But is working fine on linux.
> Is this test should be added in the skipped list for windows ?
> Is their is some difference in clourspace management on win and Linux 
> environment ?
> 
> TIA.
> Ankit
> ___
> 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] Wincairo support for wss:// urls with websockets

2015-12-28 Thread Alex Christensen
Send a pull request to https://github.com/achristensen07/WinCairoRequirements 
 or just send me an 
email with the changes you want to include.  I’m right in the middle of 
updating icu in that repository, so you might want to go back to 
a9b631e1146a696dc81b584c837ccfb7db5524b9

Alex

> On Dec 21, 2015, at 4:44 PM, Isaac Devine  wrote:
> 
> Hi all,
> 
> I have a patch that enables support for wss:// urls for websockets with the 
> wincairo port.
> 
> I haven't created a bug and attachment yet because it requires curl 7.45, 
> which is newer than the curl that the current wincairo build depends on. 
> 
> How do I go about proposing updates of the curl dependency?
> 
> Thanks,
> Isaac
> 
> ___
> 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] Wincairo support for wss:// urls with websockets

2015-12-28 Thread Alex Christensen
If you want to send a pull request for that, too, I would gladly accept it.  
Also, the output needs to be called libicuuc and libicuin instead of icuuc and 
icuin to match the AppleWin port, and it would be nice if it built it into the 
same bin64, bin32, lib64, lib32, and include directories as everything else.

> On Dec 28, 2015, at 12:13 PM, Isaac Devine <is...@devinesystems.co.nz> wrote:
> 
> Thanks,
> 
> If you are updating to ICU 56.1, it doesn't build in visual studio 2015.
> 
> A patch that fixes this can be found at:
> http://bugs.icu-project.org/trac/ticket/11822 
> <http://bugs.icu-project.org/trac/ticket/11822>
> 
> 
> On 29 December 2015 at 08:37, Alex Christensen <achristen...@apple.com 
> <mailto:achristen...@apple.com>> wrote:
> Send a pull request to https://github.com/achristensen07/WinCairoRequirements 
> <https://github.com/achristensen07/WinCairoRequirements> or just send me an 
> email with the changes you want to include.  I’m right in the middle of 
> updating icu in that repository, so you might want to go back to 
> a9b631e1146a696dc81b584c837ccfb7db5524b9
> 
> Alex
> 
>> On Dec 21, 2015, at 4:44 PM, Isaac Devine <is...@devinesystems.co.nz 
>> <mailto:is...@devinesystems.co.nz>> wrote:
>> 
>> Hi all,
>> 
>> I have a patch that enables support for wss:// urls for websockets with the 
>> wincairo port.
>> 
>> I haven't created a bug and attachment yet because it requires curl 7.45, 
>> which is newer than the curl that the current wincairo build depends on. 
>> 
>> How do I go about proposing updates of the curl dependency?
>> 
>> Thanks,
>> Isaac
>> 
>> ___
>> 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] Fetch API

2015-12-07 Thread Alex Christensen
Exciting!  Refactoring the network code is something that has been needed for a 
while.  Code can be modernized because much of it hasn’t been touched since we 
were using VS2005 and other old compilers.  Some things can maybe be removed, 
some things can be refactored, and many tests need to be added.  Sorry I don’t 
have any concrete examples, but I’m interested in assisting this work.

Alex

> On Dec 7, 2015, at 2:35 AM, youenn fablet  wrote:
> 
> Hi all,
> 
> I am interested in adding support for the fetch API 
> (https://fetch.spec.whatwg.org/#fetch-api 
> ).
> It is a more convenient way of doing programmatic network calls than XHR. It 
> also covers some more ground.
> The fetch API is currently implemented in Chromium and Firefox.
> I filed https://bugs.webkit.org/show_bug.cgi?id=151937 
>  for that purpose.
> 
> On a separate topic, I wonder whether it would be valuable to do some 
> refactoring on the loading code so as to better align it with the fetch 
> algorithm.
> 
> Thoughts, advices... most welcome.
> Thanks,
>y
> 
> ___
> 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] NetworkSession

2015-11-19 Thread Alex Christensen
Yes, Carlos, that is correct.  I’m making it so ENABLE(NETWORK_PROCESS) is 
effectively always 1, usesNetworkProcess is effectively always true, and 
ProcessModel is always ProcessModelMultipleSecondaryProcesses.  I did this by 
removing the checks for NETWORK_PROCESS, usesNetworkProcess, and ProcessModel.  
We will still have a max process limit, and it can be set to 1, and that’s what 
I’ve used to get ready for this change, too.

Alex

> On Nov 19, 2015, at 12:04 AM, Carlos Garcia Campos <carlo...@webkit.org> 
> wrote:
> 
> El mié, 18-11-2015 a las 15:58 -0800, Alex Christensen escribió:
>> As part of this work, I’m also planning to remove the non-
>> NetworkProcess code, both run time and compile time. Based on
>> discussion at the WebKit contributors’ meeting I assume there is no
>> objection to this.  See https://bugs.webkit.org/show_bug.cgi?id=15141 
>> <https://bugs.webkit.org/show_bug.cgi?id=15141>
>> 8
> 
> No objections for GTK port. I guess then the single process model will
> become multiple model with max process limit = 1 internally, right?
> That's what we did in epiphany in preparation for this change. Or do
> you plan to remove/deprecate the single process model?
> 
>> Alex
>> 
>>> On Nov 9, 2015, at 11:32 AM, Alex Christensen <achristensen@apple.c
>>> om> wrote:
>>> 
>>> I made new abstractions for loading in WebKit2: NetworkSession and
>>> NetworkDataTask.  It is disabled by default right now, but if you
>>> switch USE_NETWORK_SESSION to 1, it mostly works on Mac with
>>> features like authentication challenges not implemented yet.  I
>>> believe these new abstractions fit better with libsoup, but I’d
>>> like feedback on what an actual libsoup implementation would need.
>>>  I’m planning on removing the ResourceHandle use in WebKit2 and the
>>> async/continue callbacks in ResourceHandleClient and ResourceHandle
>>> once this work is done.
>>> 
>>> 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 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


  1   2   >