Re: [webkit-dev] Raw string literals

2021-11-29 Thread Maciej Stachowiak via webkit-dev


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

Seems like the style checker complains in part because it doesn’t know how to 
properly parse such strings. With that fixed it seems ok to me to use that type 
of string.

 - Maciej

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


Re: [webkit-dev] Request for position: New Canvas 2D API

2021-05-05 Thread Maciej Stachowiak via webkit-dev


> On May 3, 2021, at 9:58 AM, Simon Fraser via webkit-dev 
>  wrote:
> 
> 
>> On May 1, 2021, at 10:07 AM, Aaron Krajeski via webkit-dev 
>> mailto:webkit-dev@lists.webkit.org>> wrote:
>> 
>> Hi webkit-dev,
>> 
>> This is a request for WebKit's position on New Canvas 2D API 
>>  features. 
>> 
>> Explainer/Chrome Dev Summit Video
>> https://github.com/fserb/canvas2d 
>> https://youtu.be/dfOKFSDG7IM 
>> 
>> Summary
>> Updated functionality for the Canvas2D API. Adds nine new features/functions 
>> to CanvasRenderingContext2D:
>>   - "ContextLost" and "ContextRestored" events
> 
> Seems reasonable.
> 
>>   - "willReadFrequently" option for canvases where lots of readback is 
>> expected
> 
> Seems reasonable.
> 
>>   - CSSColorValues as style inputs
> 
> Seems reasonable (gated on Typed OM support).
> 
>>   - More CSS text modifier support
> 
> WebKit has already expressed support for the proposal.
> 
>>   - A reset function
> 
> We'e already expressed some concerns in the issue.
> 
>>   - A roundRect draw primitive
> 
> Seems reasonable.
> 
>>   - Full 4x4 transformation matrices
> 
> WebKit's architecture on macOS/iOS currently has no way to render these, so 
> we don't support this proposal at this time.
> 
>>   - Conic gradients
> 
> Seems reasonable.
> 
>>   - Better support for SVG filters
> 
> Seems reasonable, although this would have performance implications in our 
> current architecture.

^ On this one I’ll add, it would be better if this could reuse the existing CSS 
or SVG ways of describing a filter instead of adding a novel way. In addition, 
the filter syntax here is strictly less expressive than SVG filters; it appears 
to only support a linear filter chain, rather than a filter graph like SVG does.

> 
> Simon
> 
>> 
>> Contact emails
>> aaro...@chromium.org , fs...@chromium.org 
>> 
>> 
>> Spec and tests
>>   - WHATWG spec in progress:
>>  Text Modifiers 
>>  Filters 
>>  Perspective Transforms 
>>  reset() 
>>  CSSColorValue 
>>  willReadFrequently 
>>  RoundRect 
>>  ConicGradient 
>>  Context Loss 
>>   - MDN spec 
>>  Conic gradient 
>> 
>>  Text Modifiers 
>>  (via 
>> ChromeLabs/puppy-content)
>>   - Web platform tests
>>  RoundRect
>> 
>>  reset() 
>> 
>>  Perspective Transforms 
>> 
>>  Context Loss 
>> 
>>  (this is not testable on WPT)
>>  Filters 
>> 
>>  CSSColorValue Input 
>> 
>>  WillReadFrequently 
>> 
>>  (testable in WPT, work in progress to add tests there)
>>  Conic Gradient 
>> 
>>  Text Modifiers 
>> 
>>   - Chrome Status 
>> 
>> Look forward to hearing your feedback!
>> 
>> Cheers!
>>   Aaron
>> ___
>> 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

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

2021-02-05 Thread Maciej Stachowiak via webkit-dev

We are not opposed to the concept of efficient access to files, but we are 
strongly opposed to minting a brand new Web API for file access instead of 
enhancing one of the existing ones.

This issue outlines the problem: 
https://github.com/fivedots/storage-foundation-api-explainer/issues/4 

A similar issue was filed by Domenic Denicola from the Chrome team: 
https://github.com/fivedots/storage-foundation-api-explainer/issues/8 


We strongly urge Chrome not to move forward with this API until the above 
issues are addressed in a satisfactory manner.

Regards,
Maciej

> On Feb 5, 2021, at 9:15 AM, Emanuel Krivoy via webkit-dev 
>  wrote:
> 
> (Resending with correct subject for findability and to add further context. 
> Sorry for the spam.)
> 
> Hello webkit-dev,
> 
> We would like to get an official position from WebKit on the Storage 
> Foundation API (https://github.com/fivedots/storage-foundation-api-explainer 
> ), a storage 
> API that resembles a very basic filesystem, with direct access to stored data 
> through buffers and offsets. Our goal is to give developers flexibility by 
> providing generic, simple, and performant primitives upon which they can 
> build higher-level components. It's particularly well suited for Wasm-based 
> libraries and applications that want to use custom storage algorithms to 
> fine-tune execution speed and memory usage.
> 
> The API is currently available behind a flag in Google Chrome. We've received 
> feedback before in #4 
> (https://github.com/fivedots/storage-foundation-api-explainer/issues/4 
> ), 
> asking to clarify our relationship to other storage APIs. We are still 
> working on gathering all the required data to resolve the issues raised 
> there, we intend to update it as soon as we can.
> 
> Thank you,
> Emanuel Krivoy
> ___
> 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] Starting January 4, 2021, Google will block all sign-ins to Google accounts from embedded browser frameworks

2020-11-17 Thread Maciej Stachowiak via webkit-dev

This sounds obnoxious and potentially anti-competitive. But I think it’s 
restricted to OAuth flows, which would indeed only affect other sites that 
allow the user to sign in with their Google account. So that would be the thing 
to test.

> On Nov 17, 2020, at 12:20 PM, Michael Catanzaro via webkit-dev 
>  wrote:
> 
> On Tue, Nov 17, 2020 at 12:50 pm, Michael Catanzaro  
> wrote:
>> Oh, I missed a very important point. There is a header we can use to test: 
>> Google-Accounts-Check-OAuth-Login:true. I will try to figure out how to hack 
>> up the libsoup backend to send that header with all requests and see what 
>> happens
> 
> I tested this hack:
> 
> diff --git a/Source/WebCore/platform/network/HTTPHeaderNames.in 
> b/Source/WebCore/platform/network/HTTPHeaderNames.in
> index cbc470412f9f..eb19ab00a054 100644
> --- a/Source/WebCore/platform/network/HTTPHeaderNames.in
> +++ b/Source/WebCore/platform/network/HTTPHeaderNames.in
> @@ -109,3 +109,5 @@ X-Temp-Tablet
> // These headers are specific to GStreamer.
> Icy-MetaInt
> Icy-Metadata
> +
> +Google-Accounts-Check-OAuth-Login
> diff --git a/Source/WebCore/platform/network/ResourceRequestBase.h 
> b/Source/WebCore/platform/network/ResourceRequestBase.h
> index 6c9ce5cccefe..db234c37271f 100644
> --- a/Source/WebCore/platform/network/ResourceRequestBase.h
> +++ b/Source/WebCore/platform/network/ResourceRequestBase.h
> @@ -206,6 +206,7 @@ protected:
>, m_hiddenFromInspector(false)
>, m_isTopSite(false)
>{
> + addHTTPHeaderField(HTTPHeaderName::GoogleAccountsCheckOAuthLogin, "true");
>}
> 
>ResourceRequestBase(const URL& url, ResourceRequestCachePolicy policy)
> @@ -221,6 +222,7 @@ protected:
>, m_hiddenFromInspector(false)
>, m_isTopSite(false)
>{
> + addHTTPHeaderField(HTTPHeaderName::GoogleAccountsCheckOAuthLogin, "true");
>}
> 
>void updatePlatformRequest(HTTPBodyUpdatePolicy = 
> HTTPBodyUpdatePolicy::DoNotUpdateHTTPBody) const;
> 
> 
> And confirmed in the web inspector to ensure the header is really sent. Login 
> still works. So... maybe we will be OK? I'm not sure. I tested direct login 
> via google.com. I'm confused as to how this change is in any way related to 
> OAuth. Maybe it will only break for third-party websites that allow logging 
> in with a Google account? I guess we'll find out
> 
> 
> ___
> 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 / removing use of Makefile based DerivedSources.make

2020-11-12 Thread Maciej Stachowiak via webkit-dev


> On Oct 17, 2020, at 10:00 AM, Sam Weinig  wrote:
> 
> Hi webkit-dev,
> 
> I’d like to propose, and gauge feedback on, reducing (with the goal of 
> ultimately removing) the use of Makefile based DerivedSources.make.
> 
> My understanding is that currently only the Xcode based ports still use 
> DerivedSources.make, as all the CMake based ones have moved derived source 
> generation to within CMake, so that should limit the scope of who this might 
> affect.
> 
> 
> Why do we use Makefiles today?
> 
> While I can’t recall the initial reasons for using Makefiles for derived 
> sources, over the years there have been a number of advantages to it that I 
> do know of. One clear advantage, that is no longer applicable, was code 
> sharing, as earlier in the project, at least the Apple Windows port did 
> utilize these Makefiles. Another was to work around some limitations in what 
> dependencies Xcode was able to track with build rules. It seems at least some 
> of the problems with build rules are no longer an issue, as we can now 
> specify inputs to build rules, but I don’t if other problems will still be 
> there, but for some prototyping I did, nothing yet has come up.

I think I might be responsible for this, and I think the reason was that at the 
time, Xcode could not properly handle derived source dependencies, and ended up 
either gratuitously rebuilding, or miscomputing by failing to regenerate a 
source, or failing to rebuild it when needed. It’s possible, maybe even likely 
Xcode handling of derived sources has improved since then. But the last attempt 
to do this via Xcode caused subtle broken build issues and/ir gratuitous 
rebuilding, so we’d have to validate that it doesn’t have these problems any 
more.

DerivedSources.make is also more human-editable without having to do so via the 
Xcode GUI.


> 
> 
> What would we move to?
> 
> As this only affects the Xcode based ports, we would move to distinct script 
> phases and build rules in the Xcode project.  
> 
> 
> Why make this change? What’s the benefit?
> 
> There are few reasons to consider this. One advantage is simplifying the 
> build system. Rather than two dependency systems (one for Xcode, one for the 
> Makefile) we reduce it down to one. And with additional knowledge of the 
> stages and dependencies, Xcode could potentially parallelize more phases. We 
> would would also save some time by avoiding invoking make in the first place. 
> 
> We also have a bit of an issue with make itself, as due to system 
> requirements, we are forever stuck with Make 3.81, which is coming up on 
> being 15 years old. More than once in the last year I have tried to 
> troubleshoot makefile issues, looking for resources on the web, only to be 
> stymied because the solutions I found required newer make.

One question in my mind is whether this would potentially lead to faster 
builds. If so, and the reliability problems from older Xcode’s are gone, then 
this would probably be a worthwhile change. But see below...

> 
> 
> What are the downsides?
> 
> One potential downside will be that it will be a bit harder for those without 
> Xcode to add new types of derived sources. I am not sure how much a real 
> problem in practice this will be, as editing project.pbxproj files is already 
> required for just adding new files, but I want to call it out anyway.
> 
> 
> What are your thoughts on this? Are there additional reasons we might want to 
> stick with or move away from Makefile based derived sources?

One additional though, I think we hope to move the Apple-maintained ports to 
CMake, so the value of changes to the Xcode-based build system may be limited. 
We think this could speed up both incremental and full builds significantly.

 - Maciej


> 
> Thanks,
> -Sam
> 
> ___
> 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