[webkit-dev] Removing webkit-tools-completion.sh

[Jonathan Bedard via webkit-dev]

I’m working on unwinding Subversion support in WebKit. There is an old script, 
webkit-tools-completion.sh, which references various old scripts (namely, 
webkit-patch). Is anyone using this script or should we remove it?

Pull-request in question is https://github.com/WebKit/WebKit/pull/28536.

Thanks for your thoughts,
Jonathan Bedard
WebKit Continuous Integration

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

[webkit-dev] WebXR support timeline?

[Wladislav Artsimovich via webkit-dev]

Dear WebKit Devs,
 
I'm deep in a WebXR project and am super excited about the potential this 
standard brings. I was a bit sad to see, that Webkit and by extension Apple's 
iOS & iPadOS Safari does not support it.
 
Recently Safari on VisionOS launched support for WebXR, whereas Webkit and thus 
Safari on iOS does not.
 
With https://bugs.webkit.org/show_bug.cgi?id=208988 being stalled, are there 
news? Is there a potential timeline? Is there lack of manpower and could I help 
out in remaining tasks?
 
Best regards,
 
Vlad
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Site isolation platform code

[Michael Catanzaro via webkit-dev]

On Wed, May 8 2024 at 02:32:46 PM -07:00:00, Alex Christensen via 
webkit-dev  wrote:
1. createNewPage in WebKitUIClient.cpp needs some hooking up of the 
API::PageConfiguration in a way I couldn’t figure out in the few 
minutes I looked at it.  This should be pretty straightforward to 
someone who knows the glib code better than I do.


Created https://bugs.webkit.org/show_bug.cgi?id=273975


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

[webkit-dev] Site isolation platform code

[Alex Christensen via webkit-dev]

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

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

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

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

[Alex Christensen via webkit-dev]

Herb, if you run “git log --grep MSVC” in a git checkout of WebKit, you’ll find 
many quirks we’ve done in our code to get it to compile with MSVC.  Here are 
some of the most recent ones:

https://commits.webkit.org/272595@main
https://commits.webkit.org/271031@main
Some warning differences in https://commits.webkit.org/276799@main and 
https://commits.webkit.org/277563@main
The COMPILER(MSVC) addition necessary in https://commits.webkit.org/265366@main 
puzzled me a lot for a while, but I stopped looking into it.

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

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

[webkit-dev] RFC: Improving “RefPtr inside destructor” checking

[Geoff Garen via webkit-dev]

It’s a use-after-free error to create a RefPtr during ~T(), and have that 
RefPtr live past the end of ~T().

In debug builds, we try to catch this error by eagerly assertion 
!T::m_deletionHasBegun in the RefPtr constructor.

At the same time, our smart pointer rules sometimes require us to use RefPtr 
inside functions that are reachable from destructors. To suppress the assertion 
in these cases, we use RefPtrAllowingPartiallyDestroyed.

Problems I see with the current approach:
* We don’t do any checking in release builds
* RefPtrAllowingPartiallyDestroyed complicates our smart pointer rules, when 
we want them to be simple

I’d like to improve this situation.

Enable checking in release builds 

There are two ways we can check in release builds without adding overhead.

Option 1: deref() checks for outstanding pointers after running ~T(), and if 
there are some, crashes eagerly.

We did not like this behavior in CheckedPtr. It produced crash backtraces 
where we simply didn’t know what pointer had lived to long, or which code had 
made a mistake. But RefPtr is different. If Option 1 crashes, we know that 
the error of escaping a pointer after destruction happened inside the 
destructor that is crashing (or one of its callees). So maybe we have enough 
information to go on.

Option 2: Scribble and leak the object, and crash later, just like CheckedPtr.

Option 2 has the upside that the crashing backtrace will usually point directly 
to the errant pointer.

Option 2 seems fine too, but it has the downside that, if you escape a pointer 
in the destructor, and then make more pointers after the destructor, the 
pointer that ultimately crashes may be far removed from the pointer the 
originally escaped.

Any strong preferences, or should I just try something?

Remove RefPtrAllowingPartiallyDestroyed and the debug-only 
!T::m_deletionHasBegun check.

Once we have a form of checking that works in release builds, the existing 
debug-only assertion is arguably redundant. Getting rid of it and getting rid 
of RefPtrAllowingPartiallyDestroyed can simplify our smart pointer rules.

One downside to removing RefPtrAllowingPartiallyDestroyed it that it can be 
nice during code review to enforce a discipline that 
RefPtrAllowingPartiallyDestroyed should only be used on the stack. (This 
discipline is pretty obvious in a lot of cases, but not all — see 
WebCore::HTMLMediaElement::speakCueText and WebCore:: 
MediaSource::ensureWeakOnHTMLMediaElementContext.)

Any strong preferences, or should I just try something?

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

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

[Olmstead, Don via webkit-dev]

Hey Herb,

Not everyone whose embedding WebKit on Windows announces to us that they’re 
using it so unsure if someone is still compiling using MSVC. All the 
documentation we have points to clang-cl being the preferred way. The ones we 
know of Bun, https://bun.sh/ , and Playwright, https://playwright.dev/ , have 
switched to clang-cl.

I was personally keeping the dream alive and would compile out WebKit with 
MSVC. WebKit on Windows doesn’t have the highest tier JITs because we don’t 
have anyone working on it for Windows and the maintenance costs around MSVC are 
centered around that. If MSVC had the functionality that helps the JSC folks 
make the VM run fast we wouldn’t be in this situation. If that functionality is 
added to the roadmap then we’d definitely reconsider at that time.

Don

From: Herb Sutter 
Sent: Thursday, May 2, 2024 1:28 PM
To: Olmstead, Don ; 'Jean-Yves Avenard' 

Cc: 'WebKit-Dev Development' 
Subject: RE: [webkit-dev] Proposal: Dropping MSVC support and use clang-cl 
exclusively on Windows

Thank you, Jean-Yves and Don!

One followup: I don’t know WebKit well but was surprised that it was being 
built with MSVC, and Yusuke mentioned Windows projects that build with clang-cl 
instead. Are there known users/products who are building with WebKit that are 
important not to break, so that we (Microsoft) should be thinking about doing 
work so you can keep using MSVC, or is this really an unused configuration that 
it makes sense to just drop?

Herb


From: Olmstead, Don mailto:don.olmst...@sony.com>>
Sent: Thursday, May 2, 2024 12:06 PM
To: Jean-Yves Avenard 
mailto:jean-yves.aven...@apple.com>>; Herb Sutter 
mailto:herb.sut...@gmail.com>>
Cc: WebKit-Dev Development 
(webkit-dev@lists.webkit.org<mailto:webkit-dev@lists.webkit.org>) 
mailto:webkit-dev@lists.webkit.org>>
Subject: RE: [webkit-dev] Proposal: Dropping MSVC support and use clang-cl 
exclusively on Windows

Hi Herb

If you grep around the WebKit codebase for COMPILER(MSVC) there are a number of 
workarounds hanging out. Some may have been fixed over time but the workaround 
wasn’t removed.

Biggest issue was around the JIT and some other low level features the JSC 
folks utilize that isn’t present in MSVC. The lion’s share of JSC development 
is done using Clang and those working on it don’t have a Windows box handy so 
we have seen the JIT break on Windows. Yusuke I’m sure has a list of feature 
requests that would improve the quality of MSVC for people developing VMs.

MSVC has definitely caught some issues in the code and compiler mono-culture 
isn’t great but realistically we don’t have the resources to keep MSVC up and 
running.

Regards,
Don

From: Jean-Yves Avenard via webkit-dev 
mailto:webkit-dev@lists.webkit.org>>
Sent: Wednesday, May 1, 2024 5:10 PM
To: Herb Sutter mailto:herb.sut...@gmail.com>>
Cc: Webkit Development List 
mailto:webkit-dev@lists.webkit.org>>
Subject: Re: [webkit-dev] Proposal: Dropping MSVC support and use clang-cl 
exclusively on Windows

Hi

On 2 May 2024, at 10:07 am, Herb Sutter via webkit-dev 
mailto:webkit-dev@lists.webkit.org>> wrote:


We’ve had full C++20 including concepts for a couple of years so I wasn’t sure 
what problem you were running into… are you encountering bugs in those 
features? or you can’t turn on /std:c++20 for some reason? or are you using an 
older pre-concepts (pre-VS2022 17.0) compiler?

Thanks for any feedback you have time to share.

Herb


We’ve had issues where some use of concepts made the latest MSVC compiler crash
See 
https://searchfox.org/wubkat/source/Source/WTF/wtf/TypeTraits.h#145-172<https://searchfox.org/wubkat/source/Source/WTF/wtf/TypeTraits.h#145-172>

See 
https://bugs.webkit.org/show_bug.cgi?id=261598<https://bugs.webkit.org/show_bug.cgi?id=261598>

Jean-Yves
___________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Fujii Hironori via webkit-dev]

On Fri, May 3, 2024 at 5:28 AM Herb Sutter via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> One followup: I don’t know WebKit well but was surprised that it was being
> built with MSVC, and Yusuke mentioned Windows projects that build with
> clang-cl instead. Are there known users/products who are building with
> WebKit that are important not to break, so that we (Microsoft) should be
> thinking about doing work so you can keep using MSVC, or is this really an
> unused configuration that it makes sense to just drop?
>

As far as I know, projects publicly distributing Windows WebKit and
JavaScriptCore are only Microsoft Playwright and Bun.
As Yusuke mentioned, they already switched to clang-cl.

> 4. Major third-parties using Windows WebKit (e.g. Bun.js, praywright
etc.) are using clang-cl, not MSVC.

Other browser engines, Chrome and Firefox, already switched to Clang. You
might be interested in their blogs.

Clang is now used to build Chrome for Windows - The LLVM Project Blog
https://blog.llvm.org/2018/03/clang-is-now-used-to-build-chrome-for.html

Building Firefox on Windows with clang-cl | Home Page
https://ehsanakhgari.org/blog/2014-06-26/building-firefox-on-windows-with-clang-cl/

an unexpected benefit of standardizing on clang-cl | Nathan's Blog
https://blog.mozilla.org/nfroyd/2019/04/25/an-unexpected-benefit-of-standardizing-on-clang-cl/

For someone worrying about compiler monoculture, it seems that some
QtWebKit users are using GCC (MinGW) on Windows.
https://github.com/qtwebkit/qtwebkit/issues/1102
___________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Herb Sutter via webkit-dev]

Thank you, Jean-Yves and Don!

 

One followup: I don’t know WebKit well but was surprised that it was being 
built with MSVC, and Yusuke mentioned Windows projects that build with clang-cl 
instead. Are there known users/products who are building with WebKit that are 
important not to break, so that we (Microsoft) should be thinking about doing 
work so you can keep using MSVC, or is this really an unused configuration that 
it makes sense to just drop?

 

Herb

 

 

From: Olmstead, Don  
Sent: Thursday, May 2, 2024 12:06 PM
To: Jean-Yves Avenard ; Herb Sutter 

Cc: WebKit-Dev Development (webkit-dev@lists.webkit.org) 

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

 

Hi Herb

 

If you grep around the WebKit codebase for COMPILER(MSVC) there are a number of 
workarounds hanging out. Some may have been fixed over time but the workaround 
wasn’t removed.

 

Biggest issue was around the JIT and some other low level features the JSC 
folks utilize that isn’t present in MSVC. The lion’s share of JSC development 
is done using Clang and those working on it don’t have a Windows box handy so 
we have seen the JIT break on Windows. Yusuke I’m sure has a list of feature 
requests that would improve the quality of MSVC for people developing VMs.

 

MSVC has definitely caught some issues in the code and compiler mono-culture 
isn’t great but realistically we don’t have the resources to keep MSVC up and 
running.

 

Regards,

Don

 

From: Jean-Yves Avenard via webkit-dev mailto:webkit-dev@lists.webkit.org> > 
Sent: Wednesday, May 1, 2024 5:10 PM
To: Herb Sutter mailto:herb.sut...@gmail.com> >
Cc: Webkit Development List 
Subject: Re: [webkit-dev] Proposal: Dropping MSVC support and use clang-cl 
exclusively on Windows

 

Hi

 

On 2 May 2024, at 10:07 am, Herb Sutter via webkit-dev 
mailto:webkit-dev@lists.webkit.org> > wrote:

 

 

We’ve had full C++20 including concepts for a couple of years so I wasn’t sure 
what problem you were running into… are you encountering bugs in those 
features? or you can’t turn on /std:c++20 for some reason? or are you using an 
older pre-concepts (pre-VS2022 17.0) compiler?

 

Thanks for any feedback you have time to share.

 

Herb

 

 

We’ve had issues where some use of concepts made the latest MSVC compiler crash

See https://searchfox.org/wubkat/source/Source/WTF/wtf/TypeTraits.h#145-172

 

See https://bugs.webkit.org/show_bug.cgi?id=261598

 

Jean-Yves

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

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

[Olmstead, Don via webkit-dev]

Hi Herb

If you grep around the WebKit codebase for COMPILER(MSVC) there are a number of 
workarounds hanging out. Some may have been fixed over time but the workaround 
wasn’t removed.

Biggest issue was around the JIT and some other low level features the JSC 
folks utilize that isn’t present in MSVC. The lion’s share of JSC development 
is done using Clang and those working on it don’t have a Windows box handy so 
we have seen the JIT break on Windows. Yusuke I’m sure has a list of feature 
requests that would improve the quality of MSVC for people developing VMs.

MSVC has definitely caught some issues in the code and compiler mono-culture 
isn’t great but realistically we don’t have the resources to keep MSVC up and 
running.

Regards,
Don

From: Jean-Yves Avenard via webkit-dev 
Sent: Wednesday, May 1, 2024 5:10 PM
To: Herb Sutter 
Cc: Webkit Development List 
Subject: Re: [webkit-dev] Proposal: Dropping MSVC support and use clang-cl 
exclusively on Windows

Hi


On 2 May 2024, at 10:07 am, Herb Sutter via webkit-dev 
mailto:webkit-dev@lists.webkit.org>> wrote:


We’ve had full C++20 including concepts for a couple of years so I wasn’t sure 
what problem you were running into… are you encountering bugs in those 
features? or you can’t turn on /std:c++20 for some reason? or are you using an 
older pre-concepts (pre-VS2022 17.0) compiler?

Thanks for any feedback you have time to share.

Herb


We’ve had issues where some use of concepts made the latest MSVC compiler crash
See 
https://searchfox.org/wubkat/source/Source/WTF/wtf/TypeTraits.h#145-172<https://searchfox.org/wubkat/source/Source/WTF/wtf/TypeTraits.h#145-172>

See 
https://bugs.webkit.org/show_bug.cgi?id=261598<https://bugs.webkit.org/show_bug.cgi?id=261598>

Jean-Yves
___________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Jean-Yves Avenard via webkit-dev]

Hi

> On 2 May 2024, at 10:07 am, Herb Sutter via webkit-dev 
>  wrote:
> 
>  
> We’ve had full C++20 including concepts for a couple of years so I wasn’t 
> sure what problem you were running into… are you encountering bugs in those 
> features? or you can’t turn on /std:c++20 for some reason? or are you using 
> an older pre-concepts (pre-VS2022 17.0) compiler?
>  
> Thanks for any feedback you have time to share.
>  
> Herb
> 

We’ve had issues where some use of concepts made the latest MSVC compiler crash
See https://searchfox.org/wubkat/source/Source/WTF/wtf/TypeTraits.h#145-172

See https://bugs.webkit.org/show_bug.cgi?id=261598

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

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

[Herb Sutter via webkit-dev]

Hi! Herb here from the MSVC team. It makes total sense to use the right 
compiler for the job and prune unused configs (and it sounds like no one is 
relying on building with MSVC, correct?).

 

I just wanted to ask about this part, in case there were things we could do 
better:

 

> 1. MSVC does not support various C++20 features, so it is putting our C++20 
> adoption much behind (For example, we cannot use  concept). By using 
> clang-cl, we can start much newer set of C++20 features, improving code 
> quality, static checks etc.

 

We’ve had full C++20 including concepts for a couple of years so I wasn’t sure 
what problem you were running into… are you encountering bugs in those 
features? or you can’t turn on /std:c++20 for some reason? or are you using an 
older pre-concepts (pre-VS2022 17.0) compiler?

 

Thanks for any feedback you have time to share.

 

Herb

 

 

 

 

  _  

+1 

 

Cheers,

Keith

 

> On Apr 30, 2024, at 10:06 AM, Yusuke Suzuki via webkit-dev  lists.webkit.org <https://lists.webkit.org/mailman/listinfo/webkit-dev> > 
> wrote:

> 

> Hello WebKittens!

> 

> Right now, MSVC support is putting significant burden on JavaScriptCore. It 
> lacks many features for JSC development,

> as a result, we have so many workarounds for MSVC in JavaScriptCore (For 
> example, LLInt CLoop 16-bit opcode is disabled only for MSVC since MSVC 
> cannot compile it reasonably).

> 

> I talked with JSC team and Don at Sony, and now I would like to propose 
> dropping MSVC support on Windows port and using clang-cl exclusively on 
> Windows.

> 

> There are many motivating factors for this change.

> 

> 1. Post-commit testing bots (WinCairo) are using clang-cl. So literally, 
> there is zero test coverage on MSVC build right now.

> 2. On the other hand, EWS is using MSVC for build test. This discrepancy is 
> making maintenance of Windows ports harder and harder.

> 3. MSVC has various compilation issues which makes JSC lesser quality. Lack 
> of `__builtin_frame_address` support makes JSC bloating JIT code much. 
> CheckedArith has bunch of special code due to lack of overflow-detecting 
> `__builtin_add_overflow` like operations, and so on.  (but TBH, given there 
> is zero coverage, we even don't know whether it is working right now!)

> 4. Major third-parties using Windows WebKit (e.g. Bun.js, praywright etc.) 
> are using clang-cl, not MSVC.

> 

> Not only solving existing issues, using clang-cl opens significant code / 
> implementation quality improvements opportunities for Windows.

> 

> 1. MSVC does not support various C++20 features, so it is putting our C++20 
> adoption much behind (For example, we cannot use  concept). By using 
> clang-cl, we can start much newer set of C++20 features, improving code 
> quality, static checks etc.

> 2. This paves a way to make Windows JSC implementation super solid. clang-cl 
> offers sysv-abi feature for function attributes. This allows using Linux / 
> macOS amd64 ABI on certain annotated functions. This basically means that we 
> potentially unify our interpreter and JIT implementations completely in Linux 
> / macOS / Windows for x64, (which makes our LLInt / Wasm LLInt on Windows 
> super solid, plus, it paves a way to fully enable all JIT tiers on Windows 
> including FTL).

> 

> We already discussed with Don and we agreed on this.

> And now I would like to formally propose MSVC deprecation towards more 
> cleaner and solid Windows port.

> 

> Best regards,

> -Yusuke Suzuki

> _______

> webkit-dev mailing list

> webkit-dev at 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] Proposal: Dropping MSVC support and use clang-cl exclusively on Windows

[Keith Miller via webkit-dev]

+1 

Cheers,
Keith

> On Apr 30, 2024, at 10:06 AM, Yusuke Suzuki via webkit-dev 
>  wrote:
> 
> Hello WebKittens!
> 
> Right now, MSVC support is putting significant burden on JavaScriptCore. It 
> lacks many features for JSC development,
> as a result, we have so many workarounds for MSVC in JavaScriptCore (For 
> example, LLInt CLoop 16-bit opcode is disabled only for MSVC since MSVC 
> cannot compile it reasonably).
> 
> I talked with JSC team and Don at Sony, and now I would like to propose 
> dropping MSVC support on Windows port and using clang-cl exclusively on 
> Windows.
> 
> There are many motivating factors for this change.
> 
> 1. Post-commit testing bots (WinCairo) are using clang-cl. So literally, 
> there is zero test coverage on MSVC build right now.
> 2. On the other hand, EWS is using MSVC for build test. This discrepancy is 
> making maintenance of Windows ports harder and harder.
> 3. MSVC has various compilation issues which makes JSC lesser quality. Lack 
> of `__builtin_frame_address` support makes JSC bloating JIT code much. 
> CheckedArith has bunch of special code due to lack of overflow-detecting 
> `__builtin_add_overflow` like operations, and so on.  (but TBH, given there 
> is zero coverage, we even don't know whether it is working right now!)
> 4. Major third-parties using Windows WebKit (e.g. Bun.js, praywright etc.) 
> are using clang-cl, not MSVC.
> 
> Not only solving existing issues, using clang-cl opens significant code / 
> implementation quality improvements opportunities for Windows.
> 
> 1. MSVC does not support various C++20 features, so it is putting our C++20 
> adoption much behind (For example, we cannot use  concept). By using 
> clang-cl, we can start much newer set of C++20 features, improving code 
> quality, static checks etc.
> 2. This paves a way to make Windows JSC implementation super solid. clang-cl 
> offers sysv-abi feature for function attributes. This allows using Linux / 
> macOS amd64 ABI on certain annotated functions. This basically means that we 
> potentially unify our interpreter and JIT implementations completely in Linux 
> / macOS / Windows for x64, (which makes our LLInt / Wasm LLInt on Windows 
> super solid, plus, it paves a way to fully enable all JIT tiers on Windows 
> including FTL).
> 
> We already discussed with Don and we agreed on this.
> And now I would like to formally propose MSVC deprecation towards more 
> cleaner and solid Windows port.
> 
> Best regards,
> -Yusuke Suzuki
> _______
> 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] Proposal: Dropping MSVC support and use clang-cl exclusively on Windows

[Yusuke Suzuki via webkit-dev]

Hello WebKittens!

Right now, MSVC support is putting significant burden on JavaScriptCore. It 
lacks many features for JSC development,
as a result, we have so many workarounds for MSVC in JavaScriptCore (For 
example, LLInt CLoop 16-bit opcode is disabled only for MSVC since MSVC cannot 
compile it reasonably).

I talked with JSC team and Don at Sony, and now I would like to propose 
dropping MSVC support on Windows port and using clang-cl exclusively on Windows.

There are many motivating factors for this change.

1. Post-commit testing bots (WinCairo) are using clang-cl. So literally, there 
is zero test coverage on MSVC build right now.
2. On the other hand, EWS is using MSVC for build test. This discrepancy is 
making maintenance of Windows ports harder and harder.
3. MSVC has various compilation issues which makes JSC lesser quality. Lack of 
`__builtin_frame_address` support makes JSC bloating JIT code much. 
CheckedArith has bunch of special code due to lack of overflow-detecting 
`__builtin_add_overflow` like operations, and so on.  (but TBH, given there is 
zero coverage, we even don't know whether it is working right now!)
4. Major third-parties using Windows WebKit (e.g. Bun.js, praywright etc.) are 
using clang-cl, not MSVC.

Not only solving existing issues, using clang-cl opens significant code / 
implementation quality improvements opportunities for Windows.

1. MSVC does not support various C++20 features, so it is putting our C++20 
adoption much behind (For example, we cannot use  concept). By using clang-cl, 
we can start much newer set of C++20 features, improving code quality, static 
checks etc.
2. This paves a way to make Windows JSC implementation super solid. clang-cl 
offers sysv-abi feature for function attributes. This allows using Linux / 
macOS amd64 ABI on certain annotated functions. This basically means that we 
potentially unify our interpreter and JIT implementations completely in Linux / 
macOS / Windows for x64, (which makes our LLInt / Wasm LLInt on Windows super 
solid, plus, it paves a way to fully enable all JIT tiers on Windows including 
FTL).

We already discussed with Don and we agreed on this.
And now I would like to formally propose MSVC deprecation towards more cleaner 
and solid Windows port.

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

Re: [webkit-dev] jsc bus error EXC_BAD_ACCESS with jsc-only build on Mac

[Steve Glass via webkit-dev]

Hi Keith

I can confirm this fixed this problem.

All the best

Steve

On Tue, 23 Apr 2024 at 04:35, Keith Miller  wrote:

> Hi folks,
>
> Looks like this happened during our adoption of the BrowserEngine API. I
> have a PR to fix it https://github.com/WebKit/WebKit/pull/27587
>
> There was also an unrelated build breakage for the JSCOnly port, which I
> also fixed in that PR.
>
> Cheers,
> Keith
>
> On Apr 22, 2024, at 11:53 AM, Alexey Proskuryakov  wrote:
>
> + Keith for visibility
>
> 16 апр. 2024 г., в 3:01 PM, Steve Glass via webkit-dev <
> webkit-dev@lists.webkit.org> написал(а):
>
> Hi,
>
> Hi, I’m trying to build jsc on my M1 Mac following the instructions at
>> https://trac.webkit.org/wiki/JSCOnly and https://webkit
>> .org/getting-started/ .
>> However when I run the built binary it exits immediately with a bus error
>> which lldb shows to be EXC_BAD_ACCESS.
>
>
> I'm also trying to build JSC on my M1 Mac and my experience is the *exact* 
> same
> error as Laurence has reported above.
>
> When I run I get a bus error at the same location in the code:
>
> [27467]>DYLD_FRAMEWORK_PATH=/users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug
>> lldb WebKitBuild/JSCOnly/Debug/bin/jsc
>> (lldb) target create "WebKitBuild/JSCOnly/Debug/bin/jsc"
>> Current executable set to 
>> '/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc'
>> (arm64).
>> (lldb) target create Web
>> Available completions:
>> WebKitBuild/
>> WebDriverTests/
>> WebKit.xcworkspace/
>> WebKitLibraries/
>> Websites/
>> (lldb) target create WebKitBuild/JSCOnly/Debug/b
>> Available completions:
>> WebKitBuild/JSCOnly/Debug/bmalloc/
>> WebKitBuild/JSCOnly/Debug/bin/
>> WebKitBuild/JSCOnly/Debug/build-webkit-options.txt
>> (lldb) target create WebKitBuild/JSCOnly/Debug/bin/jsc
>> Current executable set to 
>> '/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc'
>> (arm64).
>> (lldb) run
>> Process 86562 launched: 
>> '/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc'
>> (arm64)
>> Process 86562 stopped
>> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
>> (code=2, address=0x133804000)
>> frame #0: 0x00018696f248 libsystem_platform.dylib`_platform_memmove
>> + 168
>> libsystem_platform.dylib`:
>> ->  0x18696f248 <+168>: stpq2, q3, [x0]
>> 0x18696f24c <+172>: subs   x2, x2, #0x40
>> 0x18696f250 <+176>: b.ls   0x18696f26c   ; <+204>
>> 0x18696f254 <+180>: stpq0, q1, [x3]
>> Target 1: (jsc) stopped.
>>
>
> This is what 'image list' reports at this point:
>
>
>> (lldb) image list
>> [  0] 7A464963-87D0-342F-BF0D-B030FC8488D4 0x0001
>> /Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc
>> [  1] F6DD3EC2-85A4-3AB1-8486-B189CD980EBE 0x0001865b
>> /usr/lib/dyld
>> [  2] BDD21D2C-3C16-3379-9501-D64F8AFA3C0E 0x00010781c000
>> /Users/stevie/git/WebKit
>> /WebKitBuild/JSCOnly/Debug/lib/JavaScriptCore.framework/Versions/1.0.0/JavaScriptCore
>> [  3] A356C2AE-08AC-30C6-B3D2-89535B87B958 0x0001d1096000
>> /usr/lib/libedit.3.dylib
>> [  4] 27A49F84-CD29-3448-BE8C-ED4240A78C9C 0x0001b06d7000
>> /usr/lib/libncurses.5.4.dylib
>> [  5] BE250157-7A2B-39DA-B404-983D7989DFC6 0x0001935ae000
>> /usr/lib/libSystem.B.dylib
>> [  6] C0BCBAE5-4913-3D80-8E3A-9D4DEC1EA827 0x0001935a8000
>> /usr/lib/system/libcache.dylib
>> [  7] 0BA453ED-E5A2-3C2F-86F4-CFCFFA6C1879 0x000193563000
>> /usr/lib/system/libcommonCrypto.dylib
>> [  8] DE476BC5-36E2-3F7A-87C8-1EF2BE6ADFDA 0x00019358f000
>> /usr/lib/system/libcompiler_rt.dylib
>> [  9] 3DF60503-459B-3DA5-BD91-E72518FA9370 0x000193585000
>> /usr/lib/system/libcopyfile.dylib
>> [ 10] 95C1D199-1B36-32B2-9BE7-5723A58D0D96 0x0001866a4000
>> /usr/lib/system/libcorecrypto.dylib
>> [ 11] 7F973554-8168-35BF-AE86-2E9123E81BF7 0x00018678a000
>> /usr/lib/system/libdispatch.dylib
>> [ 12] 72199A80-9C55-376D-8ECF-EE68AFA57B7A 0x000186945000
>> /usr/lib/system/libdyld.dylib
>> [ 13] 291CFCDE-CF87-3F39-A3E3-36C4303BEC16 0x00019359e000
>> /usr/lib/system/libkeymgr.dylib
>> [ 14] DD2A9F47-7F80-344C-B6FE-82682F8AAB4A 0x00019353b000
>> /usr/lib/system/libmacho.dylib
>> [ 15] 158A39C2-F9C6-32CA-845B-F1DFB711718A 0x000192a1c000
>> /usr/lib/system/libquarantine.dylib
>> [ 16] 92A7E10F-1F6C-30D5-9C44-D42352D3A674 0x00019359b000
>> /usr/lib/system/libremovefile.dylib
>&g

[webkit-dev] Sam Sneddon is now a WebKit Reviewer

[Jonathan Bedard via webkit-dev]

Hello folks,

I am happy to announce that Sam Sneddon is now a WebKit Reviewer!

Sam is an expert in Web Platform Tests and our tooling to run layout tests, 
along with Python in general.

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

Re: [webkit-dev] jsc bus error EXC_BAD_ACCESS with jsc-only build on Mac

[Keith Miller via webkit-dev]

Hi folks, 

Looks like this happened during our adoption of the BrowserEngine API. I have a 
PR to fix it https://github.com/WebKit/WebKit/pull/27587

There was also an unrelated build breakage for the JSCOnly port, which I also 
fixed in that PR.

Cheers,
Keith

> On Apr 22, 2024, at 11:53 AM, Alexey Proskuryakov  wrote:
> 
> + Keith for visibility
> 
>> 16 апр. 2024 г., в 3:01 PM, Steve Glass via webkit-dev 
>>  написал(а):
>> 
>> Hi,
>> 
>>> Hi, I’m trying to build jsc on my M1 Mac following the instructions at
>>> https://trac.webkit.org/wiki/JSCOnly and 
>>> https://webkit.org/getting-started/ .
>>> However when I run the built binary it exits immediately with a bus error
>>> which lldb shows to be EXC_BAD_ACCESS.
>> 
>> I'm also trying to build JSC on my M1 Mac and my experience is the exact 
>> same error as Laurence has reported above.
>> 
>> When I run I get a bus error at the same location in the code:
>> 
>>> [27467]>DYLD_FRAMEWORK_PATH=/users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug
>>>  lldb WebKitBuild/JSCOnly/Debug/bin/jsc 
>>> (lldb) target create "WebKitBuild/JSCOnly/Debug/bin/jsc"
>>> Current executable set to 
>>> '/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc' (arm64).
>>> (lldb) target create Web
>>> Available completions:
>>> WebKitBuild/   
>>> WebDriverTests/
>>> WebKit.xcworkspace/
>>> WebKitLibraries/   
>>> Websites/  
>>> (lldb) target create WebKitBuild/JSCOnly/Debug/b
>>> Available completions:
>>> WebKitBuild/JSCOnly/Debug/bmalloc/
>>> WebKitBuild/JSCOnly/Debug/bin/
>>> WebKitBuild/JSCOnly/Debug/build-webkit-options.txt
>>> (lldb) target create WebKitBuild/JSCOnly/Debug/bin/jsc 
>>> Current executable set to 
>>> '/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc' (arm64).
>>> (lldb) run
>>> Process 86562 launched: 
>>> '/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc' (arm64)
>>> Process 86562 stopped
>>> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
>>> (code=2, address=0x133804000)
>>> frame #0: 0x00018696f248 libsystem_platform.dylib`_platform_memmove 
>>> + 168
>>> libsystem_platform.dylib`:
>>> ->  0x18696f248 <+168>: stpq2, q3, [x0]
>>> 0x18696f24c <+172>: subs   x2, x2, #0x40
>>> 0x18696f250 <+176>: b.ls <http://b.ls/>   0x18696f26c   ; 
>>> <+204>
>>> 0x18696f254 <+180>: stpq0, q1, [x3]
>>> Target 1: (jsc) stopped.
>> 
>> This is what 'image list' reports at this point:
>>  
>>> (lldb) image list
>>> [  0] 7A464963-87D0-342F-BF0D-B030FC8488D4 0x0001 
>>> /Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc 
>>> [  1] F6DD3EC2-85A4-3AB1-8486-B189CD980EBE 0x0001865b /usr/lib/dyld 
>>> [  2] BDD21D2C-3C16-3379-9501-D64F8AFA3C0E 0x00010781c000 
>>> /Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/lib/JavaScriptCore.framework/Versions/1.0.0/JavaScriptCore
>>>  
>>> [  3] A356C2AE-08AC-30C6-B3D2-89535B87B958 0x0001d1096000 
>>> /usr/lib/libedit.3.dylib 
>>> [  4] 27A49F84-CD29-3448-BE8C-ED4240A78C9C 0x0001b06d7000 
>>> /usr/lib/libncurses.5.4.dylib 
>>> [  5] BE250157-7A2B-39DA-B404-983D7989DFC6 0x0001935ae000 
>>> /usr/lib/libSystem.B.dylib 
>>> [  6] C0BCBAE5-4913-3D80-8E3A-9D4DEC1EA827 0x0001935a8000 
>>> /usr/lib/system/libcache.dylib 
>>> [  7] 0BA453ED-E5A2-3C2F-86F4-CFCFFA6C1879 0x000193563000 
>>> /usr/lib/system/libcommonCrypto.dylib 
>>> [  8] DE476BC5-36E2-3F7A-87C8-1EF2BE6ADFDA 0x00019358f000 
>>> /usr/lib/system/libcompiler_rt.dylib 
>>> [  9] 3DF60503-459B-3DA5-BD91-E72518FA9370 0x000193585000 
>>> /usr/lib/system/libcopyfile.dylib 
>>> [ 10] 95C1D199-1B36-32B2-9BE7-5723A58D0D96 0x0001866a4000 
>>> /usr/lib/system/libcorecrypto.dylib 
>>> [ 11] 7F973554-8168-35BF-AE86-2E9123E81BF7 0x00018678a000 
>>> /usr/lib/system/libdispatch.dylib 
>>> [ 12] 72199A80-9C55-376D-8ECF-EE68AFA57B7A 0x000186945000 
>>> /usr/lib/system/libdyld.dylib 
>>> [ 13] 291CFCDE-CF87-3F39-A3E3-36C4303BEC16 0x00019359e000 
>>> /usr/lib/system/libkeymgr.dylib 
>>> [ 14] DD2A9F47-7F80-344C-B6FE-82682F8AAB4A 0x00019353b000 
>>> /usr/lib/system/li

Re: [webkit-dev] jsc bus error EXC_BAD_ACCESS with jsc-only build on Mac

[Alexey Proskuryakov via webkit-dev]

+ Keith for visibility

16 апр. 2024 г., в 3:01 PM, Steve Glass via webkit-dev 
 написал(а):

Hi,

Hi, I’m trying to build jsc on my M1 Mac following the instructions at
https://trac.webkit.org/wiki/JSCOnly and https://webkit.org/getting-started/ .
However when I run the built binary it exits immediately with a bus error
which lldb shows to be EXC_BAD_ACCESS.
I'm also trying to build JSC on my M1 Mac and my experience is the exact same 
error as Laurence has reported above.

When I run I get a bus error at the same location in the code:

[27467]>DYLD_FRAMEWORK_PATH=/users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug 
lldb WebKitBuild/JSCOnly/Debug/bin/jsc 
(lldb) target create "WebKitBuild/JSCOnly/Debug/bin/jsc"
Current executable set to 
'/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc' (arm64).
(lldb) target create Web
Available completions:
WebKitBuild/       
WebDriverTests/    
WebKit.xcworkspace/
WebKitLibraries/   
Websites/          
(lldb) target create WebKitBuild/JSCOnly/Debug/b
Available completions:
WebKitBuild/JSCOnly/Debug/bmalloc/                
WebKitBuild/JSCOnly/Debug/bin/                    
WebKitBuild/JSCOnly/Debug/build-webkit-options.txt
(lldb) target create WebKitBuild/JSCOnly/Debug/bin/jsc 
Current executable set to 
'/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc' (arm64).
(lldb) run
Process 86562 launched: 
'/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc' (arm64)
Process 86562 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
(code=2, address=0x133804000)
    frame #0: 0x00018696f248 libsystem_platform.dylib`_platform_memmove + 
168
libsystem_platform.dylib`:
->  0x18696f248 <+168>: stp    q2, q3, [x0]
    0x18696f24c <+172>: subs   x2, x2, #0x40
    0x18696f250 <+176>: b.ls <http://b.ls/>    0x18696f26c               ; 
<+204>
    0x18696f254 <+180>: stp    q0, q1, [x3]
Target 1: (jsc) stopped.

This is what 'image list' reports at this point:
 (lldb) image list
[  0] 7A464963-87D0-342F-BF0D-B030FC8488D4 0x0001 
/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc 
[  1] F6DD3EC2-85A4-3AB1-8486-B189CD980EBE 0x0001865b /usr/lib/dyld 
[  2] BDD21D2C-3C16-3379-9501-D64F8AFA3C0E 0x00010781c000 
/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/lib/JavaScriptCore.framework/Versions/1.0.0/JavaScriptCore
 
[  3] A356C2AE-08AC-30C6-B3D2-89535B87B958 0x0001d1096000 
/usr/lib/libedit.3.dylib 
[  4] 27A49F84-CD29-3448-BE8C-ED4240A78C9C 0x0001b06d7000 
/usr/lib/libncurses.5.4.dylib 
[  5] BE250157-7A2B-39DA-B404-983D7989DFC6 0x0001935ae000 
/usr/lib/libSystem.B.dylib 
[  6] C0BCBAE5-4913-3D80-8E3A-9D4DEC1EA827 0x0001935a8000 
/usr/lib/system/libcache.dylib 
[  7] 0BA453ED-E5A2-3C2F-86F4-CFCFFA6C1879 0x000193563000 
/usr/lib/system/libcommonCrypto.dylib 
[  8] DE476BC5-36E2-3F7A-87C8-1EF2BE6ADFDA 0x00019358f000 
/usr/lib/system/libcompiler_rt.dylib 
[  9] 3DF60503-459B-3DA5-BD91-E72518FA9370 0x000193585000 
/usr/lib/system/libcopyfile.dylib 
[ 10] 95C1D199-1B36-32B2-9BE7-5723A58D0D96 0x0001866a4000 
/usr/lib/system/libcorecrypto.dylib 
[ 11] 7F973554-8168-35BF-AE86-2E9123E81BF7 0x00018678a000 
/usr/lib/system/libdispatch.dylib 
[ 12] 72199A80-9C55-376D-8ECF-EE68AFA57B7A 0x000186945000 
/usr/lib/system/libdyld.dylib 
[ 13] 291CFCDE-CF87-3F39-A3E3-36C4303BEC16 0x00019359e000 
/usr/lib/system/libkeymgr.dylib 
[ 14] DD2A9F47-7F80-344C-B6FE-82682F8AAB4A 0x00019353b000 
/usr/lib/system/libmacho.dylib 
[ 15] 158A39C2-F9C6-32CA-845B-F1DFB711718A 0x000192a1c000 
/usr/lib/system/libquarantine.dylib 
[ 16] 92A7E10F-1F6C-30D5-9C44-D42352D3A674 0x00019359b000 
/usr/lib/system/libremovefile.dylib 
[ 17] B8B21C7C-4530-3EA2-AB35-BA98B82F33D0 0x00018c0bc000 
/usr/lib/system/libsystem_asl.dylib 
[ 18] E9F1A3B9-AE38-3F4C-BF14-8A6E012AD36C 0x000186639000 
/usr/lib/system/libsystem_blocks.dylib 
[ 19] 49477E07-E77B-332F-B98D-79CA210A866D 0x0001867d5000 
/usr/lib/system/libsystem_c.dylib 
[ 20] 2EA02C23-E13C-39AE-B850-82CEABACE7A6 0x000193593000 
/usr/lib/system/libsystem_collections.dylib 
[ 21] D57D8736-2800-3066-82D4-C433A2DC10C4 0x000191bf6000 
/usr/lib/system/libsystem_configuration.dylib 
[ 22] C9DB5B40-6F90-348A-A518-3ACFB49B39FE 0x000190c34000 
/usr/lib/system/libsystem_containermanager.dylib 
[ 23] 324A6A0A-BBDE-3257-9A75-6A74C85E3430 0x0001931d2000 
/usr/lib/system/libsystem_coreservices.dylib 
[ 24] 8DB1E11F-85AB-3699-AD96-228BE7D8C715 0x000189d5b000 
/usr/lib/system/libsystem_darwin.dylib 
[ 25] 0395D567-DBD9-3F03-A9E0-A0969963A834 0x00024d32a000 
/usr/lib/system/libsystem_darwindirectory.dylib 
[ 26] 4D030E4B-27FC-3C22-8467-A8CAFECA7761 0x00019359f000 
/usr/lib/system/libsystem_dnssd.dylib 
[ 27] 6C663441-D4D5-361C-ABE7-B68D7B6E5B9B 0x00024d32e000 
/usr/lib/system/libsystem_eligibility.dylib 
[ 28] D8AF5585-B9E4-38C0-B48B-CFD5C13DEB82 0x000186

Re: [webkit-dev] jsc bus error EXC_BAD_ACCESS with jsc-only build on Mac

[Steve Glass via webkit-dev]

::call_once[abi:un170006](__flag=0x00010ae2af68,
> __func=0x00016fdfef17) at mutex:677:9
> frame #13: 0x000108e9b704 
> JavaScriptCore`JSC::LLInt::defaultCallThunk()
> at LLIntThunks.cpp:309:5
> frame #14: 0x000108e9a9b8 JavaScriptCore`JSC::LLInt::defaultCall()
> at LLIntEntrypoint.cpp:198:16
> frame #15: 0x000108e9a87c JavaScriptCore`JSC::LLInt::initialize()
> at LLIntData.cpp:264:36
> frame #16: 0x0001091ba7b8 
> JavaScriptCore`JSC::initialize()::$_12::operator()(this=0x00016fdff0ff)
> const at InitializeThreading.cpp:121:9
> frame #17: 0x0001091ba6c0 
> JavaScriptCore`decltype(std::declval()())
> std::__1::__invoke[abi:un170006](__f=0x00016fdff0ff)
> at invoke.h:340:25
> frame #18: 0x0001091ba69c JavaScriptCore`void
> std::__1::__call_once_param>::__execute[abi:un170006]<>(this=0x00016fdff0c0,
> (null)=__tuple_indices<> @ 0x00016fdff01f) at mutex:632:9
> frame #19: 0x0001091ba670 
> JavaScriptCore`std::__1::__call_once_param>::operator()[abi:un170006](this=0x00016fdff0c0)
> at mutex:624:9
> frame #20: 0x0001091ba570 JavaScriptCore`void
> std::__1::__call_once_proxy[abi:un170006]>(__vp=0x00016fdff0c0)
> at mutex:660:5
> frame #21: 0x00018686ae44 
> libc++.1.dylib`std::__1::__call_once(unsigned
> long volatile&, void*, void (*)(void*)) + 180
> frame #22: 0x000109191860 JavaScriptCore`void
> std::__1::call_once[abi:un170006](__flag=0x00010ae2b7f0,
> __func=0x00016fdff0ff) at mutex:677:9
> frame #23: 0x0001091917f4 JavaScriptCore`JSC::initialize() at
> InitializeThreading.cpp:73:5
> frame #24: 0x00010000987c jsc`jscmain(argc=1,
> argv=0x00016fdff440) at jsc.cpp:4361:5
> frame #25: 0x00019680 jsc`main(argc=1,
> argv=0x00016fdff440) at jsc.cpp:3541:15
> frame #26: 0x0001865b60e0 dyld`start + 2360
> (lldb)


My software versions are different to those reported by Laurence:

  Versions:

- WebKit main (9dc3f9d6339)
- Xcode 15.3 (15E204a)
- macOS 14.4.1
- CMake.app 3.24.4

I run the tests for JSC using 'Tools/Scripts/run-javascriptcore-tests
--jsc-only --debug --no-build --no-fail-fast' and it is reporting bus
errors everywhere. I've tried pulling newer versions of webkit but this
error has persisted for the last couple of weeks.

Thanks

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

Re: [webkit-dev] [EXTERNAL] Re: Lost docs!

[Max Schmitt via webkit-dev]

Would it be also possible to redirect the webkit.org build 
instructions<https://webkit.org/webkit-on-windows/> for Windows over to the 
docs.webkit.org build 
instructions<https://docs.webkit.org/Ports/WindowsPort.html>? Since they are 
getting more and more outdated.

Thanks,

Max

From: Michael Catanzaro via webkit-dev 
Sent: Thursday, April 4, 2024 2:45 PM
To: Brandon Stewart 
Cc: webkit-dev@lists.webkit.org 
Subject: [EXTERNAL] Re: [webkit-dev] Lost docs!

On Wed, Apr 3 2024 at 09:47:05 PM -05:00:00, Brandon Stewart
 wrote:
> I did copy the documentation over a year ago, but anything added
> there since then would be missing on docs.webkit.org.

Perhaps we should just turn off the wiki to prevent more stuff from
being added by mistake? Anybody still need the GitHub wiki? It's really
best to have just one place for our docs.


___________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.webkit.org%2Fmailman%2Flistinfo%2Fwebkit-dev=05%7C02%7Cmax.schmitt%40microsoft.com%7C5374fe722fe24095285708dc54a554ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638478316310746385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=KjAC7J55jvRKpS2U9uXdHhZ2zAx5fNTL0TtSMhgWhTc%3D=0<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] Lost docs!

[Michael Catanzaro via webkit-dev]

On Wed, Apr 3 2024 at 09:47:05 PM -05:00:00, Brandon Stewart 
 wrote:
I did copy the documentation over a year ago, but anything added 
there since then would be missing on docs.webkit.org.


Perhaps we should just turn off the wiki to prevent more stuff from 
being added by mistake? Anybody still need the GitHub wiki? It's really 
best to have just one place for our docs.



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

Re: [webkit-dev] Lost docs!

[Brandon Stewart via webkit-dev]

I did copy the documentation over a year ago, but anything added there since 
then would be missing on docs.webkit.org <http://docs.webkit.org/>.

The document you pointed out hasn’t been ported yet, so it would be good to 
copy that as well.

I tried to get most of the relevant documentation from trac too, but I am sure 
there might have been a few things I missed.

Brandon

> On Mar 25, 2024, at 12:28 PM, Michael Catanzaro via webkit-dev 
>  wrote:
> 
> Hi,
> 
> I've noticed we have a bunch of documentation on 
> https://github.com/WebKit/WebKit/wiki that has not been migrated to 
> https://docs.webkit.org/index.html. Some of the documentation looks pretty 
> important, e.g. [1]. In the case of this specific page, we can probably just 
> copy/paste it onto the bottom of [2] or similiar; it's easy to move since 
> it's Markdown in either place. We should think about what to do with the 
> other pages, though.
> 
> Michael
> 
> [1] https://github.com/WebKit/WebKit/wiki/Smart-Pointer-Usage-Guidelines
> [2] https://docs.webkit.org/Deep%20Dive/MemoryManagement.html
> 
> 
> ___________
> 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] ASSERT vs. RELEASE_ASSERT

[Patrick Griffis via webkit-dev]

On 2024-04-01 16:18, Michael Catanzaro via webkit-dev wrote:
> Hi,
> 
> Just brainstorming, but I generally think it's worth enabling way more 
> assertions in production builds to the extent we can do so without 
> unacceptable performance impact. My ideal would be to rename ASSERT() to 
> SLOW_ASSERT() and then rename RELEASE_ASSERT() to ASSERT(), to make release 
> asserts the "default" type of assert. But I'm not ambitious enough to attempt 
> that. Notably, this would in many cases downgrade the severity of security 
> bugs, since hitting a RELEASE_ASSERT() is at worst a denial of service issue. 
> Curious what other WebKit developers think about this.
> 
> Michael

I'm not suggesting this has the same result as what you propose but I
think it's worth mentioning the CMake build supports `-DENABLE_ASSERTS`
on Release builds now and this was always possible on macOS.
___________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] ASSERT vs. RELEASE_ASSERT

[Michael Catanzaro via webkit-dev]

Hi,

Just brainstorming, but I generally think it's worth enabling way more 
assertions in production builds to the extent we can do so without 
unacceptable performance impact. My ideal would be to rename ASSERT() 
to SLOW_ASSERT() and then rename RELEASE_ASSERT() to ASSERT(), to make 
release asserts the "default" type of assert. But I'm not ambitious 
enough to attempt that. Notably, this would in many cases downgrade the 
severity of security bugs, since hitting a RELEASE_ASSERT() is at worst 
a denial of service issue. Curious what other WebKit developers think 
about this.


Michael


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

[webkit-dev] Lost docs!

[Michael Catanzaro via webkit-dev]

Hi,

I've noticed we have a bunch of documentation on 
https://github.com/WebKit/WebKit/wiki that has not been migrated to 
https://docs.webkit.org/index.html. Some of the documentation looks 
pretty important, e.g. [1]. In the case of this specific page, we can 
probably just copy/paste it onto the bottom of [2] or similiar; it's 
easy to move since it's Markdown in either place. We should think about 
what to do with the other pages, though.


Michael

[1] https://github.com/WebKit/WebKit/wiki/Smart-Pointer-Usage-Guidelines
[2] https://docs.webkit.org/Deep%20Dive/MemoryManagement.html


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

[webkit-dev] Matthew Finkel is now a WebKit reviewer

[John Wilander via webkit-dev]

Hullo!

I’m delighted to announce that Matthew Finkel, GitHub name sysrqb, is now a 
WebKit reviewer!   

He’s been working on features like partitioned SessionStorage, partitioned blob 
URLs, Mixed Content Level 2, and various things networking. He also has plenty 
of experience in the web standards world from IETF and W3C.

Please feel free to reach out to him for code reviews.

   Regards, John___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Replacing Cairo in WebKit with Skia

[Dominik Röttsches via webkit-dev]

Hi,

Thanks for taking on this effort and the technical investigation that went
into this!

One question I had asked on X: Does this have implications for font format
support: Will WebKitGTK/WPE with Skia support COLRv1 fonts through Skia?
Will it also support the Fontations Rust backend of Skia, that's in
development?

Thanks,

Dominik




On Fri, Feb 2, 2024 at 4:49 PM Carlos Garcia Campos via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> Hi WebKittens,
>
> At Igalia we have spent some time exploring different options to
> replace the Cairo 2D rendering library in the GTK and WPE ports (we
> even tried rolling our own library). Recently we decided to try Skia
> and we have successfully integrated it in the WPE port. Right now we
> can compile WebKit with Skia linked statically, as part of the CMake
> build, and run a number benchmarks. This has allowed us to compare the
> Skia GPU and CPU renderers with the existing Cairo one in different
> devices.
>
> The results are very promising: benchmarks are faster than Cairo's CPU
> rendering, specially with Skia's GPU renderer. The improvement varies
> for each device, but in any case it is already clear that the change is
> a net positive on every configuration we have tested. Additionally, the
> integration in the build system is well isolated: importing Skia under
> Source/ThirdParty there is no need for any additional dependencies,
> patching Skia has not been needed, and the changes in WebKit are
> limited to code from the WPE port.
>
> After talking to teams from Google, Sony, Apple and RedHat during this
> week, everyone thinks using Skia will be a great improvement for the
> GTK, WPE, PlayStation and WinCairo ports. Therefore, we would like to
> start upstreaming what we have to the WebKit repository and continue
> the work there.
>
> Points we need to consider:
>
> - Skia is licensed under the BSD 3-Clause “New” license, which
> should be compatible with WebKit's.
>
> - The Skia source tree would add about 170MiB to the repository
> under Source/ThirdParty. For the sake of comparison, libwebrtc weighs
> 367MiB and ANGLE 73MiB.
>
> - We plan to update Skia frequently following Google's
> recommendation. We have already agreed with the Skia maintainers to
> stay in contact and will explore integrating an automated system to
> test updates. We have also discussed Skia's security policy with
> Google, and we will have a procedure in place to incorporate security
> fixes, the latest when we start making releases using Skia.
>
> - We cannot promise a timeline at the moment but expect refactors
> in the GTK and WPE ports after the initial integration. We have big
> plans for rearchitecting the rendering pipeline to better take
> advantage of GPUs, and we hope we can get rid of some complex code
> while at it.
>
> Please let us know if you have any questions, we plan to do this job
> sooner rather than later if there are no objections. We are very
> excited about this move since we really think it will be a great step
> ahead for the non Apple ports of WebKit, allowing the project to grow
> even bigger and stronger.
>
> Best regards,
>
> - The Igalia team
>
> --
> Carlos Garcia Campos
> ___________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Intent to Ship Sec-CH-UA-Form-Factor client hint in Blink

[Dustin Mitchell via webkit-dev]

On Mon, Feb 26, 2024 at 9:22 AM Dustin Mitchell  wrote:

> I was following what appears to have been an outdated example -- sorry
> about that! I will raise the issue there, instead.
>

I've commented in https://github.com/WebKit/standards-positions/issues/70.

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

Re: [webkit-dev] Intent to Ship Sec-CH-UA-Form-Factor client hint in Blink

[Dustin Mitchell via webkit-dev]

I was following what appears to have been an outdated example -- sorry
about that! I will raise the issue there, instead.

Dustin

On Mon, Feb 26, 2024 at 9:05 AM Anne van Kesteren  wrote:

> On Wed, Feb 21, 2024 at 4:19 PM Dustin Mitchell via webkit-dev
>  wrote:
> > We are working to ship a new client hint, form-factor, in Blink. Please
> let us know if you have any questions or comments.
> >
> > You can check the following documents for details:
> > *
> https://github.com/djmitche/web-explainers/blob/main/sec-ch-ua-form-factor.md
> > * https://wicg.github.io/ua-client-hints/#sec-ch-ua-form-factor
>
> Is there a reason this is not raised as part of
> https://github.com/WebKit/standards-positions/issues/70 or a new issue
> against that repository?
>
___________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Intent to Ship Sec-CH-UA-Form-Factor client hint in Blink

[Anne van Kesteren via webkit-dev]

On Wed, Feb 21, 2024 at 4:19 PM Dustin Mitchell via webkit-dev
 wrote:
> We are working to ship a new client hint, form-factor, in Blink. Please let 
> us know if you have any questions or comments.
>
> You can check the following documents for details:
> * 
> https://github.com/djmitche/web-explainers/blob/main/sec-ch-ua-form-factor.md
> * https://wicg.github.io/ua-client-hints/#sec-ch-ua-form-factor

Is there a reason this is not raised as part of
https://github.com/WebKit/standards-positions/issues/70 or a new issue
against that repository?
___________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] WebKit Tree Closure - Revised Time Window

[Chris Gibb via webkit-dev]

WebKit Tree Closure - Revised Time Window
What: WebKit tree closure
When: 11pm PT 2/24/2024 until 7am PT 2/25/2024
Impact
Affected services:
github.com/webkit/webkit
The default (main) branch of WebKit will be closed during the above time 
window. It will not be possible to commit changes to this branch during the 
specified time period. Pull requests and EWS will be unaffected.  Merge-queue 
labels may still be added to pull requests. They will not be processed until 
the tree is reopened.


Chris Gibb
Production Services Engineer
Apple
Internet Technologies and User Privacy
One Apple Park Way
Cupertino, CA 95014, USA
cgi...@apple.com

This email and any attachments may contain confidential information intended 
only for the recipient(s) named above. Any other distribution, forwarding, 
copying or disclosure of this message is strictly prohibited. If you have 
received this email in error, please notify me immediately by telephone or 
return email, and delete this message from your system.

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

Re: [webkit-dev] WebKit Tree Closure

[Jonathan Bedard via webkit-dev]

This tree closure has been canceled. ‘main’ will remain open for commits for 
the duration of 2/23 and 2/24.
Thank you for your patience!

Jonathan Bedard
WebKit Continuous Integration

> What: WebKit tree closure
> When: 8pm PT 2/23/2024 until 12pm PT 2/24/2024
> 
> Impact
> Affected services:
> github.com/webkit/webkit
> What: WebKit tree closure
> The default (main) branch of WebKit will be closed during the above time 
> window. It will not be possible to commit changes to this branch during the 
> specified time period. Pull requests and EWS will be unaffected. Merge-queue 
> labels may still be added to pull requests. They will not be processed until 
> the tree is reopened.


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

[webkit-dev] WebKit Tree Closure

[Chris Gibb via webkit-dev]

What: WebKit tree closure
When: 8pm PT 2/23/2024 until 12pm PT 2/24/2024
Impact
Affected services:
github.com/webkit/webkit
The default (main) branch of WebKit will be closed during the above time 
window. It will not be possible to commit changes to this branch during the 
specified time period. Pull requests and EWS will be unaffected. Merge-queue 
labels may still be added to pull requests. They will not be processed until 
the tree is reopened.


Chris Gibb
Production Services Engineer
Apple
Internet Technologies and User Privacy
One Apple Park Way
Cupertino, CA 95014, USA
cgi...@apple.com

This email and any attachments may contain confidential information intended 
only for the recipient(s) named above. Any other distribution, forwarding, 
copying or disclosure of this message is strictly prohibited. If you have 
received this email in error, please notify me immediately by telephone or 
return email, and delete this message from your system.

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

[webkit-dev] Intent to Ship Sec-CH-UA-Form-Factor client hint in Blink

[Dustin Mitchell via webkit-dev]

We are working to ship a new client hint, form-factor, in Blink. Please let
us know if you have any questions or comments.

You can check the following documents for details:
*
https://github.com/djmitche/web-explainers/blob/main/sec-ch-ua-form-factor.md
* https://wicg.github.io/ua-client-hints/#sec-ch-ua-form-factor

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

Re: [webkit-dev] Replacing Cairo in WebKit with Skia

[Kirsling, Ross via webkit-dev]

Seems like a great opportunity to turn WinCairo into simply "Win".

Ross

On 2/7/24, 3:31 PM, "Yusuke Suzuki via webkit-dev" 
mailto:webkit-dev@lists.webkit.org>> wrote:


Nice, this sounds really good.
Cairo performance was one of the limiting factors in WebKitGTK, and adopting 
some libraries which can use GPU is great improvement.
One of questions is, should we rename WinCairo to something different? (Like, 
Win, or WinSkia).


-Yusuke


> On Feb 2, 2024, at 6:49 AM, Carlos Garcia Campos via webkit-dev 
> mailto:webkit-dev@lists.webkit.org>> wrote:
> 
> Hi WebKittens,
> 
> At Igalia we have spent some time exploring different options to
> replace the Cairo 2D rendering library in the GTK and WPE ports (we
> even tried rolling our own library). Recently we decided to try Skia
> and we have successfully integrated it in the WPE port. Right now we
> can compile WebKit with Skia linked statically, as part of the CMake
> build, and run a number benchmarks. This has allowed us to compare the
> Skia GPU and CPU renderers with the existing Cairo one in different
> devices.
> 
> The results are very promising: benchmarks are faster than Cairo's CPU
> rendering, specially with Skia's GPU renderer. The improvement varies
> for each device, but in any case it is already clear that the change is
> a net positive on every configuration we have tested. Additionally, the
> integration in the build system is well isolated: importing Skia under
> Source/ThirdParty there is no need for any additional dependencies,
> patching Skia has not been needed, and the changes in WebKit are
> limited to code from the WPE port.
> 
> After talking to teams from Google, Sony, Apple and RedHat during this
> week, everyone thinks using Skia will be a great improvement for the
> GTK, WPE, PlayStation and WinCairo ports. Therefore, we would like to
> start upstreaming what we have to the WebKit repository and continue
> the work there.
> 
> Points we need to consider:
> 
> - Skia is licensed under the BSD 3-Clause “New” license, which
> should be compatible with WebKit's.
> 
> - The Skia source tree would add about 170MiB to the repository
> under Source/ThirdParty. For the sake of comparison, libwebrtc weighs
> 367MiB and ANGLE 73MiB.
> 
> - We plan to update Skia frequently following Google's
> recommendation. We have already agreed with the Skia maintainers to
> stay in contact and will explore integrating an automated system to
> test updates. We have also discussed Skia's security policy with
> Google, and we will have a procedure in place to incorporate security
> fixes, the latest when we start making releases using Skia.
> 
> - We cannot promise a timeline at the moment but expect refactors
> in the GTK and WPE ports after the initial integration. We have big
> plans for rearchitecting the rendering pipeline to better take
> advantage of GPUs, and we hope we can get rid of some complex code
> while at it.
> 
> Please let us know if you have any questions, we plan to do this job
> sooner rather than later if there are no objections. We are very
> excited about this move since we really think it will be a great step
> ahead for the non Apple ports of WebKit, allowing the project to grow
> even bigger and stronger.
> 
> Best regards,
> 
> - The Igalia team
> 
> -- 
> Carlos Garcia Campos
> ___________
> 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] Replacing Cairo in WebKit with Skia

[Yusuke Suzuki via webkit-dev]

Nice, this sounds really good.
Cairo performance was one of the limiting factors in WebKitGTK, and adopting 
some libraries which can use GPU is great improvement.
One of questions is, should we rename WinCairo to something different? (Like, 
Win, or WinSkia).

-Yusuke

> On Feb 2, 2024, at 6:49 AM, Carlos Garcia Campos via webkit-dev 
>  wrote:
> 
> Hi WebKittens,
> 
> At Igalia we have spent some time exploring different options to
> replace the Cairo 2D rendering library in the GTK and WPE ports (we
> even tried rolling our own library). Recently we decided to try Skia
> and we have successfully integrated it in the WPE port. Right now we
> can compile WebKit with Skia linked statically, as part of the CMake
> build, and run a number benchmarks. This has allowed us to compare the
> Skia GPU and CPU renderers with the existing Cairo one in different
> devices.
> 
> The results are very promising: benchmarks are faster than Cairo's CPU
> rendering, specially with Skia's GPU renderer. The improvement varies
> for each device, but in any case it is already clear that the change is
> a net positive on every configuration we have tested. Additionally, the
> integration in the build system is well isolated: importing Skia under
> Source/ThirdParty there is no need for any additional dependencies,
> patching Skia has not been needed, and the changes in WebKit are
> limited to code from the WPE port.
> 
> After talking to teams from Google, Sony, Apple and RedHat during this
> week, everyone thinks using Skia will be a great improvement for the
> GTK, WPE, PlayStation and WinCairo ports. Therefore, we would like to
> start upstreaming what we have to the WebKit repository and continue
> the work there.
> 
> Points we need to consider:
> 
>- Skia is licensed under the BSD 3-Clause “New” license, which
> should be compatible with WebKit's.
> 
>- The Skia source tree would add about 170MiB to the repository
> under Source/ThirdParty. For the sake of comparison, libwebrtc weighs
> 367MiB and ANGLE 73MiB.
> 
>- We plan to update Skia frequently following Google's
> recommendation. We have already agreed with the Skia maintainers to
> stay in contact and will explore integrating an automated system to
> test updates. We have also discussed Skia's security policy with
> Google, and we will have a procedure in place to incorporate security
> fixes, the latest when we start making releases using Skia.
> 
>- We cannot promise a timeline at the moment but expect refactors
> in the GTK and WPE ports after the initial integration. We have big
> plans for rearchitecting the rendering pipeline to better take
> advantage of GPUs, and we hope we can get rid of some complex code
> while at it.
> 
> Please let us know if you have any questions, we plan to do this job
> sooner rather than later if there are no objections. We are very
> excited about this move since we really think it will be a great step
> ahead for the non Apple ports of WebKit, allowing the project to grow
> even bigger and stronger.
> 
> Best regards,
> 
> - The Igalia team
> 
> -- 
> Carlos Garcia Campos
> ___________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[webkit-dev] Replacing Cairo in WebKit with Skia

[Carlos Garcia Campos via webkit-dev]

Hi WebKittens,

At Igalia we have spent some time exploring different options to
replace the Cairo 2D rendering library in the GTK and WPE ports (we
even tried rolling our own library). Recently we decided to try Skia
and we have successfully integrated it in the WPE port. Right now we
can compile WebKit with Skia linked statically, as part of the CMake
build, and run a number benchmarks. This has allowed us to compare the
Skia GPU and CPU renderers with the existing Cairo one in different
devices.

The results are very promising: benchmarks are faster than Cairo's CPU
rendering, specially with Skia's GPU renderer. The improvement varies
for each device, but in any case it is already clear that the change is
a net positive on every configuration we have tested. Additionally, the
integration in the build system is well isolated: importing Skia under
Source/ThirdParty there is no need for any additional dependencies,
patching Skia has not been needed, and the changes in WebKit are
limited to code from the WPE port.

After talking to teams from Google, Sony, Apple and RedHat during this
week, everyone thinks using Skia will be a great improvement for the
GTK, WPE, PlayStation and WinCairo ports. Therefore, we would like to
start upstreaming what we have to the WebKit repository and continue
the work there.

Points we need to consider:

- Skia is licensed under the BSD 3-Clause “New” license, which
should be compatible with WebKit's.

- The Skia source tree would add about 170MiB to the repository
under Source/ThirdParty. For the sake of comparison, libwebrtc weighs
367MiB and ANGLE 73MiB.

- We plan to update Skia frequently following Google's
recommendation. We have already agreed with the Skia maintainers to
stay in contact and will explore integrating an automated system to
test updates. We have also discussed Skia's security policy with
Google, and we will have a procedure in place to incorporate security
fixes, the latest when we start making releases using Skia.

- We cannot promise a timeline at the moment but expect refactors
in the GTK and WPE ports after the initial integration. We have big
plans for rearchitecting the rendering pipeline to better take
advantage of GPUs, and we hope we can get rid of some complex code
while at it.

Please let us know if you have any questions, we plan to do this job
sooner rather than later if there are no objections. We are very
excited about this move since we really think it will be a great step
ahead for the non Apple ports of WebKit, allowing the project to grow
even bigger and stronger.

Best regards,

- The Igalia team

-- 
Carlos Garcia Campos


signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] maybe_unused vs UNUSED_PARAM

[Darin Adler via webkit-dev]

I support using standardized and widely enough available language features 
directly instead of through macros whenever we can. It’s similar to when we 
drop our own classes and use the ones from the C++ standard, which I think has 
been good for the project.

It’s also fine with me to use the style checker script to catch mistakes and 
help educate contributors about this once we’ve decided.

Not sure others agree with this, but I’d even support using global replace to 
move from old style to new style.

One nice thing about language features is we don’t have to be so careful about 
not using them in headers. We don’t want to pull in lots of our own macros into 
headers that are used outside the project.

It’s great for the long term health of the project to cut down the number of 
unique special things you need to know to understand and work with the code.

I have two thoughts about possible reasons for caution as we do these 
transitions:

Macros can be a flexible solution to cross-platform or cross-language issues. 
It would be a shame to move to a new language feature and discover only 
afterward that we as a project want to continue to support at least one 
compiler or platform that doesn’t have a good implementation yet, or support 
using some header from C, or that there was something else we can work around 
with macros. This would make me want to do some testing first on each of these 
before taking the plunge.

We should be open to the possibility that some of our macros may still be 
better solutions to a problem than directly using the new language feature. For 
example, it is possible that ASSERT_UNUSED is slightly better for its purpose 
than [[maybe_unused]] since it has a more specific purpose. Marking the 
argument [[maybe_unused]] when we specifically know it’s only used for 
assertions isn’t perfect. Of course, ASSERT_UNUSED doesn’t quite do what we’d 
want either, but it’s still more specific than just saying “maybe”. The unused 
argument warning macros aren’t superb right now. It’s almost always better to 
leave out argument names instead of using them, because then there is no 
“maybe” about it. Unfortunately, the unused argument warning is mostly not 
turned on outside JavaScriptCore and WebCore. Also, it’s easy to have stale 
“unused” markings on things that are actually always used, so we leave behind 
macros that are both no longer needed and subtly misleading. I’m pretty sure 
[[maybe_unused]] is nearly identical in its properties to UNUSED_PARAM, so none 
of this really seems like an argument against that. And I’m not sure 
ASSERT_UNUSED is actually good enough to keep, despite these considerations.

I agree with moving in the direction of using these.

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

Re: [webkit-dev] maybe_unused vs UNUSED_PARAM

[Chris Dumez via webkit-dev]

Right, as long as it is part of the language and consistent across compilers / 
platforms, I don’t think we need to use macros.

> On Jan 24, 2024, at 11:59 PM, Anne van Kesteren  wrote:
> 
> I had a [[fallthrough]] patch, but internal C code got in the way:
> 
> - https://en.cppreference.com/w/c/language/attributes/fallthrough
> - https://bugs.webkit.org/show_bug.cgi?id=265789
> 
> Using them directly where we can seems nice for (new) readers of the code at 
> least. Not sure what a macro for [[fallthrough]] would buy us for instance.
> 
>> On Jan 25, 2024, at 12:28 AM, Ryosuke Niwa via webkit-dev 
>>  wrote:
>> 
>> If we’re adopting [[maybe_unused]], do we just write that directly in each 
>> function declaration / definition? Or do we define some a macro to do that 
>> anyway?
>> 
>> What bout other kinds of attributes like [[noreturn]], [[fallthrough]], and 
>> [[likely]]? Are we gonna start writing them directly in code, or are we 
>> gonna continue to use macros?
>> 
>> - R. NIwa
>> 
>>> On Jan 24, 2024, at 9:49 AM, Chris Dumez via webkit-dev 
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>> Thanks for starting this discussion.
>>> 
>>> I personally think it would be nice for us to switch to [[maybe_unused]] 
>>> since it is now part of the language and it seems to fit our needs. 
>>> However, I do think we should be consistent and stop using UNUSED_PARAM() / 
>>> ASSERT_UNUSED() in new code entirely then.
>>> 
>>> So if we decide to switch, I think should add style checks to prevent using 
>>> UNUSED_PARAM() / ASSERT_UNUSED() and recommend using [[maybe_unused]] 
>>> instead. Eventually, we should try to phase out existing usage of these 
>>> macros so that we can remove them entirely.
>>> 
>>> Cheers,
>>> Chris.
>>> 
>>>> On Jan 24, 2024, at 9:34 AM, Alex Christensen via webkit-dev 
>>>>  wrote:
>>>> 
>>>> For many years we have used the UNUSED_PARAM macros, and we have almost 
>>>> 3000 of them.  C++17 introduced [[maybe_unused]] for this purpose, and a 
>>>> few uses of it are starting to pop up in WebKit.  Should we switch, should 
>>>> we transition, should we allow both, or should we just stick with 
>>>> UNUSED_PARAM?
>>>> _______________
>>>> webkit-dev mailing list
>>>> webkit-dev@lists.webkit.org
>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>> 
>>> ___________
>>> webkit-dev 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] maybe_unused vs UNUSED_PARAM

[Anne van Kesteren via webkit-dev]

I had a [[fallthrough]] patch, but internal C code got in the way:

- https://en.cppreference.com/w/c/language/attributes/fallthrough
- https://bugs.webkit.org/show_bug.cgi?id=265789

Using them directly where we can seems nice for (new) readers of the code at 
least. Not sure what a macro for [[fallthrough]] would buy us for instance.

> On Jan 25, 2024, at 12:28 AM, Ryosuke Niwa via webkit-dev 
>  wrote:
> 
> If we’re adopting [[maybe_unused]], do we just write that directly in each 
> function declaration / definition? Or do we define some a macro to do that 
> anyway?
> 
> What bout other kinds of attributes like [[noreturn]], [[fallthrough]], and 
> [[likely]]? Are we gonna start writing them directly in code, or are we gonna 
> continue to use macros?
> 
> - R. NIwa
> 
>> On Jan 24, 2024, at 9:49 AM, Chris Dumez via webkit-dev 
>>  wrote:
>> 
>> Hi,
>> 
>> Thanks for starting this discussion.
>> 
>> I personally think it would be nice for us to switch to [[maybe_unused]] 
>> since it is now part of the language and it seems to fit our needs. However, 
>> I do think we should be consistent and stop using UNUSED_PARAM() / 
>> ASSERT_UNUSED() in new code entirely then.
>> 
>> So if we decide to switch, I think should add style checks to prevent using 
>> UNUSED_PARAM() / ASSERT_UNUSED() and recommend using [[maybe_unused]] 
>> instead. Eventually, we should try to phase out existing usage of these 
>> macros so that we can remove them entirely.
>> 
>> Cheers,
>> Chris.
>> 
>>> On Jan 24, 2024, at 9:34 AM, Alex Christensen via webkit-dev 
>>>  wrote:
>>> 
>>> For many years we have used the UNUSED_PARAM macros, and we have almost 
>>> 3000 of them.  C++17 introduced [[maybe_unused]] for this purpose, and a 
>>> few uses of it are starting to pop up in WebKit.  Should we switch, should 
>>> we transition, should we allow both, or should we just stick with 
>>> UNUSED_PARAM?
>>> ___________
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
>> _______
>> webkit-dev 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] maybe_unused vs UNUSED_PARAM

[Ryosuke Niwa via webkit-dev]

If we’re adopting [[maybe_unused]], do we just write that directly in each 
function declaration / definition? Or do we define some a macro to do that 
anyway?

What bout other kinds of attributes like [[noreturn]], [[fallthrough]], and 
[[likely]]? Are we gonna start writing them directly in code, or are we gonna 
continue to use macros?

- R. NIwa

> On Jan 24, 2024, at 9:49 AM, Chris Dumez via webkit-dev 
>  wrote:
> 
> Hi,
> 
> Thanks for starting this discussion.
> 
> I personally think it would be nice for us to switch to [[maybe_unused]] 
> since it is now part of the language and it seems to fit our needs. However, 
> I do think we should be consistent and stop using UNUSED_PARAM() / 
> ASSERT_UNUSED() in new code entirely then.
> 
> So if we decide to switch, I think should add style checks to prevent using 
> UNUSED_PARAM() / ASSERT_UNUSED() and recommend using [[maybe_unused]] 
> instead. Eventually, we should try to phase out existing usage of these 
> macros so that we can remove them entirely.
> 
> Cheers,
> Chris.
> 
>> On Jan 24, 2024, at 9:34 AM, Alex Christensen via webkit-dev 
>>  wrote:
>> 
>> For many years we have used the UNUSED_PARAM macros, and we have almost 3000 
>> of them.  C++17 introduced [[maybe_unused]] for this purpose, and a few uses 
>> of it are starting to pop up in WebKit.  Should we switch, should we 
>> transition, should we allow both, or should we just stick with UNUSED_PARAM?
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> _______
> webkit-dev 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] maybe_unused vs UNUSED_PARAM

[Chris Dumez via webkit-dev]

Hi,

Thanks for starting this discussion.

I personally think it would be nice for us to switch to [[maybe_unused]] since 
it is now part of the language and it seems to fit our needs. However, I do 
think we should be consistent and stop using UNUSED_PARAM() / ASSERT_UNUSED() 
in new code entirely then.

So if we decide to switch, I think should add style checks to prevent using 
UNUSED_PARAM() / ASSERT_UNUSED() and recommend using [[maybe_unused]] instead. 
Eventually, we should try to phase out existing usage of these macros so that 
we can remove them entirely.

Cheers,
Chris.

> On Jan 24, 2024, at 9:34 AM, Alex Christensen via webkit-dev 
>  wrote:
> 
> For many years we have used the UNUSED_PARAM macros, and we have almost 3000 
> of them.  C++17 introduced [[maybe_unused]] for this purpose, and a few uses 
> of it are starting to pop up in WebKit.  Should we switch, should we 
> transition, should we allow both, or should we just stick with UNUSED_PARAM?
> ___________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[webkit-dev] maybe_unused vs UNUSED_PARAM

[Alex Christensen via webkit-dev]

For many years we have used the UNUSED_PARAM macros, and we have almost 3000 of 
them.  C++17 introduced [[maybe_unused]] for this purpose, and a few uses of it 
are starting to pop up in WebKit.  Should we switch, should we transition, 
should we allow both, or should we just stick with UNUSED_PARAM?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Anne Van Kesteren is now a WebKit reviewer

[Kirsling, Ross via webkit-dev]

Indeed, congratulations!!

From: Mathias Bynens via webkit-dev 
Sent: Friday, January 12, 2024 10:02:13 PM
To: Tim Nguyen 
Cc: WebKit Development 
Subject: Re: [webkit-dev] Anne Van Kesteren is now a WebKit reviewer

Congrats Anne!

On Thu, Jan 11, 2024 at 8:32 PM Tim Nguyen via webkit-dev 
mailto:webkit-dev@lists.webkit.org>> wrote:
Hi everyone!

I’m delighted to announce that Anne Van Kesteren is now a WebKit reviewer!  

He’s been working on HTML parsing, CSS parsing and native theme related things.

Please feel free to reach out to him for reviews.

Cheers,
Tim
___
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] Anne Van Kesteren is now a WebKit reviewer

[Mathias Bynens via webkit-dev]

Congrats Anne!

On Thu, Jan 11, 2024 at 8:32 PM Tim Nguyen via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> Hi everyone!
>
> I’m delighted to announce that Anne Van Kesteren is now a WebKit
> reviewer!  
>
> He’s been working on HTML parsing, CSS parsing and native theme related
> things.
>
> Please feel free to reach out to him for reviews.
>
> Cheers,
> Tim
> _______________
> 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] Matthieu Dubet is now a WebKit reviewer

[Tim Nguyen via webkit-dev]

Hi everyone!

I’m delighted to announce that Matthieu Dubet is now a WebKit reviewer!   

He’s been working on many complex CSS features, and many areas of the CSS 
engine.

Please feel free to reach out to him for reviews.

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

[webkit-dev] Anne Van Kesteren is now a WebKit reviewer

[Tim Nguyen via webkit-dev]

Hi everyone!

I’m delighted to announce that Anne Van Kesteren is now a WebKit reviewer!   

He’s been working on HTML parsing, CSS parsing and native theme related things.

Please feel free to reach out to him for reviews.

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

[webkit-dev] Charlie Wolfe is now a reviewer!

[Pascoe via webkit-dev]

Howdy,

I'm excited to announce that Charlie Wolfe is now a WebKit reviewer. 拾

Charlie has been doing a lot of great work on site isolation and privacy. 
Please feel free to reach out to Charlie for reviews.

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

[webkit-dev] Stricter type checking in downcast<>()

[Chris Dumez via webkit-dev]

Hi,

I have recently landed stricter type checking in downcast<>() [1]. It is 
stricter because the check is now happening in release / production builds on 
some platforms (ARM-based).
My objective is to enable to check in release on all platforms in the near 
future (still a small performance hit on remaining platforms at the moment).

Because of this, it is now recommended to use dynamicDowncast<>() instead of 
is<>() + downcast<>(), to avoid duplicating the type check.
dynamicDowncast<>() is also less error-prone and often results in more concise 
code.

If you have a case where performance matters and you’re confident a type check 
is not required, you may rely on uncheckedDowncast<>().
uncheckedDowncast<>() behaves the same way downcast<>() used to before my 
change (type check on debug builds only).

One such example I’ve seen in our codebase is when using a switch statement 
based on the type:
```
switch (node.nodeType()) {
case Node::DOCUMENT_TYPE_NODE:
  uncheckedDowncast(node)->foo();
```

Please let me know if you have any concerns / questions.

Cheers,
Chris Dumez.

[1] https://commits.webkit.org/272296@main

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

[webkit-dev] Patch WebKit to support custom Audio I/O handlers

[webkitdev--- via webkit-dev]

Dear Everyone!

Currently, we are working on a project that aims to extend Selenium's 
functionality in regard to the Audio Input and Output, which Selenium currently 
does not support. The goal is to be able to provide custom audio input/output 
to an internal website, which we want to test automatically.
For this, we are currently evaluating a rather complex approach involving using 
special Linux VMs and PulseAudio, thus rerouting the audio through the 
PulseAudio server.
This approach is, of course, rather unsatisfying and error prone. Which is why 
we are thinking about forking WebKit and implementing a custom audio backend 
relaying the audio input and the audio output of the website to a custom 
handler.

Which is why I want to ask:

  *   I am a novice in the WebKit project, how would you suggest starting this 
task?
  *   If we really were to go this route, would you be interested in an 
upstream patch or would you prefer a fork instead?
  *   (off-topic) Are there any different approaches other than the two 
suggested above?

Yours faithfully,
Alexander

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

[webkit-dev] Patch WebKit to support custom Audio I/O handlers

[webkitdev--- via webkit-dev]

Dear Everyone!

Currently, we are working on a project that aims to extend Selenium's 
functionality in regard to the Audio Input and Output, which Selenium currently 
does not support. The goal is to be able to provide custom audio input/output 
to an internal website, which we want to test automatically.
For this, we are currently evaluating a rather complex approach involving using 
special Linux VMs and PulseAudio, thus rerouting the audio through the 
PulseAudio server.
This approach is, of course, rather unsatisfying and error prone. Which is why 
we are thinking about forking WebKit and implementing a custom audio backend 
relaying the audio input and the audio output of the website to a custom 
handler.

Which is why I want to ask:

  *   I am a novice in the WebKit project, how would you suggest starting this 
task?
  *   If we really were to go this route, would you be interested in an 
upstream patch or would you prefer a fork instead?
  *   (off-topic) Are there any different approaches other than the two 
suggested above?

Yours faithfully,
Alexander

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

Re: [webkit-dev] WPT import status

[Fujii Hironori via webkit-dev]

This is useful information. It should be documented at
https://docs.webkit.org/Infrastructure/WPTTests.html even though it is
still work in progress.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] webkit-unassigned

[Michael Catanzaro via webkit-dev]

On Mon, Dec 18 2023 at 09:58:14 PM +00:00:00, Alexey Proskuryakov 
 wrote:
Are you thinking of scraping Bugzilla? No plans to further limit 
public access at all (we do have some rate limiting already though, 
to protect service availability). I don't think that "it's in 
principle possible to notice a misplaced comment" is equivalent to 
"let's maintain a way to have every misplaced comment delivered to 
the mailbox of anyone who cares to collect those".


Not me personally.

Or if there is a similar way to follow all public activity that 
irreversibly emails everything out, then I don't know about it.


Hm, maybe not. I assumed there was, but can't find settings for it in 
Bugzilla. Maybe I was wrong.



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

[webkit-dev] WPT import status

[Sam Sneddon via webkit-dev]

https://github.com/WebKit/WebKit/pull/21912 hopefully serves as good progress 
here: this PR is almost largely done by automated tooling.

The first commit is the result of `import-w3c-tests` (the long standing 
command), but with no further work (to the expectations or baselines).

It then ran through EWS with the `no-failure-limits` label, before I added a 
second commit: the output of `update-test-expectations github-pr`, albeit 
limited to only changes it made to the relevant (dom) directory. This is where 
all the baselines come from in the PR.

This a roughly a workflow that’s useable in some cases today.

The most obvious limitation is that it only deals with baseline files 
(*-expected.txt), and not TestExpectations files (which means for things where 
the result is stored there—including reftest failures, debug differences, 
timeouts and crashes—it doesn’t work). Of the limitations this causes, reftests 
are by far the more apparent and mean this doesn’t work for most CSS tests yet.

The other obvious limitation is that it doesn’t deal with flaky tests, as shown 
by the PR failing after the second commit.

The final limitation, hinted at above, is that this doesn’t take any 
consideration of the current results on main—so it rebaselines far too much, 
depending on how well gardened main is when the PR run.

That said, the first and last of these are very much things we care about 
fixing, and we’ll see how problematic the second requiring manual intervention 
is.

I’d encourage people importing directories which have few reftests to try using 
the scripts mentioned above, and file any bugs they find.

What would be super helpful, to avoid making “turn on automated import” too 
painful, is updating directories we have imported that haven’t been updated 
recently.

And finally, as an aside, the `import-expectations.json` file now explicitly 
skips every top level directory we don’t import: I’d encourage you to take a 
look at what’s marked as skip, and if there’s more you think we should be 
importing (especially because we have implemented the spec in question!), I’d 
encourage you to do so by running `import-w3c-tests` with that directory, which 
will also change the relevant line in `import-expectations.json` from “skip” to 
“import”.

Happy New Year, (Web)Kittens,

Sam

PS: Apparently I messed up and my original draft with many more links to bugs 
didn’t get saved to a server-side draft mailbox, and I’m now on vacation, so 
please accept this much less-useful-than-intended email on current WPT import 
work! (I’ll try to reply with all the links once I get home in the New Year, 
although I will remain on leave for a while beyond.)___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] webkit-unassigned

[Alexey Proskuryakov via webkit-dev]

> 18 дек. 2023 г., в 1:44 PM, Michael Catanzaro  
> написал(а):
> 
> On Mon, Dec 18 2023 at 09:16:21 PM +00:00:00, Alexey Proskuryakov 
>  wrote:
>> Same thing - limiting the ability to trivially watch for security bugs that 
>> are initially filed in a wrong component,
> 
> You can currently follow all public activity on the Bugzilla. Are you 
> planning to limit that too?

Are you thinking of scraping Bugzilla? No plans to further limit public access 
at all (we do have some rate limiting already though, to protect service 
availability). I don't think that "it's in principle possible to notice a 
misplaced comment" is equivalent to "let's maintain a way to have every 
misplaced comment delivered to the mailbox of anyone who cares to collect 
those".

Or if there is a similar way to follow all public activity that irreversibly 
emails everything out, then I don't know about it.

- Alexey


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

Re: [webkit-dev] webkit-unassigned

[Michael Catanzaro via webkit-dev]

On Mon, Dec 18 2023 at 09:16:21 PM +00:00:00, Alexey Proskuryakov 
 wrote:
Same thing - limiting the ability to trivially watch for security 
bugs that are initially filed in a wrong component,


You can currently follow all public activity on the Bugzilla. Are you 
planning to limit that too?



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

Re: [webkit-dev] webkit-unassigned

[Alexey Proskuryakov via webkit-dev]

> 18 дек. 2023 г., в 1:11 PM, Michael Catanzaro via webkit-dev 
>  написал(а):
> 
> On Mon, Dec 18 2023 at 06:07:48 PM +00:00:00, Alexey Proskuryakov via 
> webkit-dev  wrote:
>> I'm still inclined to break the scenario of watching webkit-unassigned. What 
>> do others think?
> 
> I don't think there's any need to disable the ability to watch the Bugzilla 
> account? It shouldn't give anybody access to anything they don't already have 
> permission to see, so what's the point?

Same thing - limiting the ability to trivially watch for security bugs that are 
initially filed in a wrong component, or accidental comments that expose 
something and need to be hidden.

The alternative would be to periodically verify who is watching the account, 
which I don't think is practical.

- Alexey

> Turning off the public mailing list seems good.
> 
> 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] webkit-unassigned

[Michael Catanzaro via webkit-dev]

On Mon, Dec 18 2023 at 06:07:48 PM +00:00:00, Alexey Proskuryakov via 
webkit-dev  wrote:
I'm still inclined to break the scenario of watching 
webkit-unassigned. What do others think?


I don't think there's any need to disable the ability to watch the 
Bugzilla account? It shouldn't give anybody access to anything they 
don't already have permission to see, so what's the point?


Turning off the public mailing list seems good.

Michael


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

Re: [webkit-dev] webkit-unassigned

[Alexey Proskuryakov via webkit-dev]

There isn't a lot of difference between unassigned bugs, and those that are 
assigned to people who don't read their bugmail for various reasons. If you 
want to get a decent subset of bugs that aren't being worked on, but not all, 
perhaps a query like this would work for you, 
https://bugs.webkit.org/buglist.cgi?bug_status=UNCONFIRMED_status=NEW_status=ASSIGNED_status=REOPENED=1d=Now=assigned_to=substring_format=advanced=unassigned
 ? This can even go into RSS, to track what's already been read.

Bugs that were filed a while ago and get updates is another query to 
potentially follow, which would have interesting updates and exclude bugs that 
are just opened for PR purposes.

I'm still inclined to break the scenario of watching webkit-unassigned. What do 
others think?

- Alexey

15 дек. 2023 г., в 5:43 PM, Fujii Hironori  
написал(а):

The user watching feature doesn't expose comments that you don't have access to 
the bug.
I'd like to notice that someone commented to unassigned bugs. I don't have to 
check bugs assigned to a developer.

On Sat, Dec 16, 2023 at 8:04 AM Alexey Proskuryakov mailto:a...@webkit.org> > wrote:

My approach would be to also disable the ability to watch the account, for the 
same reason of reducing exposure of accidental postings.

Would you mind sharing your use case? Bugs assigned to webkit-unassigned are 
not a very well defined set of bugs, so perhaps there is another solution that 
works.

- Alexey

15 дек. 2023 г., в 2:25 PM, Fujii Hironori via webkit-dev 
mailto:webkit-dev@lists.webkit.org> > написал(а):


I check it every day. Can I receive the same mails by setting my user watching 
to webkit-unassig...@lists.webkit.org 
<mailto:webkit-unassig...@lists.webkit.org> ?

On Sat, Dec 16, 2023 at 7:12 AM Alexey Proskuryakov via webkit-dev 
mailto:webkit-dev@lists.webkit.org> > wrote:
Hello,

Does anybody make use of the webkit-unassigned mailing list? I'd like to 
disable it, to reduce exposure of spam and accidental postings.

- Alexey
_______
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] Meaning of '7' in WebKit Versioning

[강수진 via webkit-dev]

Hi Timothy,
Thank you for your answer. I understand that the prefix was added to 
differentiate versions with different feature flags based on the target SDK 
version. For example, Safari was built for 10.6 Snow Leopard and was versioned 
as 6616.1.20, and Safari was built for 10.7 Lion and was versioned as 7616.1.20.
And I have a few follow-up questions:
1.
You said, "Safari updates, which shipped to older OS versions, were also 
included in new OS releases."
I understand that Safari is automatically updated when I upgrade to a new OS. 
So, I don't understand what you mean by "Safari updates for older OS versions 
were also included in new OS releases."
After some research, I found that Safari may need to be updated on all OSes for 
security reasons. For example, there are both Lion and Snow Leopard versions of 
Safari 5.1.7 update for Adobe Flash Player 
(https://support.apple.com/en-vn/103351)
Is this the situation you were describing?
2.
You also said, "the version number's prefix was introduced to differentiate 
these versions and ensure proper file updates during installation."
How does this versioning ensure correct updates? Does the OS installer have 
Safari programs built for different target SDKs, and does it check the 
currently installed OS environment to install the Safari version corresponding 
to that environment? For example, if the current OS version is 10.7, does it 
download the Safari program with a version number starting with 7?
3.
Finally, why isn't this versioning scheme needed anymore? Could you give me an 
example?
Thanks, Sujin

-Original Message-
From: "Timothy Hatcher"
To: "강수진";
Cc: ;
Sent: 2023-12-16 (토) 02:18:57 (GMT+09:00)
Subject: Re: [webkit-dev] Meaning of '7' in WebKit Versioning

Your research is on the right track. The prefix originally reflected the minor 
dot-number from Mac OS X's version naming convention.

I implemented this versioning scheme many years ago to address versioning 
conflicts with the OS X installer. Safari updates, which shipped to older OS 
versions, were also included in new OS releases. To ensure the OS installer 
updated WebKit and Safari correctly, distinct bundle version numbers were 
necessary, as these components were built with different feature flags 
depending on the target SDK version (they were not intended for use outside the 
OS version they were compiled against). Thus, the version number's prefix was 
introduced to differentiate these versions and ensure proper file updates 
during installation (since 7616.1.20 is larger, thus newer to the installer, 
than 6616.1.20).

This versioning scheme isn't needed anymore, which is why the prefix number 
hasn't changed in the last few years.

— Timothy Hatcher


On Oct 29, 2023, at 10:07 PM, 강수진 via webkit-dev  
wrote:

Meaning of '7' in WebKit Versioning
Hello,
I have a question about the versioning rules in WebKit.
I am aware that the version of WebKit used varies based on the iOS version. For 
example, in iOS 17.0, the WebKit framework's WebKit.tbd file shows the current 
version as 616.1.27, while in iOS 16.4, it's 615.1.26.
When I checked the corresponding source for each version on WebKit's GitHub, I 
noticed that the tags for these versions are labeled as WebKit-7616.1.20.
Upon inspecting Version.xcconfig, I found that 616.1.20 represents the Major, 
Minor, and Tiny versions, respectively. However, I couldn't determine the 
significance of '7'.
I speculated that '7' might represent the SYSTEM_VERSION_PREFIX since 
BUNDLE_VERSION_Production is set to $(SYSTEM_VERSION_PREFIX)$(FULL_VERSION); in 
the same file. But considering the system version prefix for iPhone SDK is set 
to 8, '7' couldn't denote that.
After some research, I found that '7' signifies the release year of Mac OS 10.7 
(Lion), which was launched in 2011.
Could you please clarify the meaning of '7' in tags like WebKit-7616.1.20?
_______________
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] webkit-unassigned

[Fujii Hironori via webkit-dev]

The user watching feature doesn't expose comments that you don't have
access to the bug.
I'd like to notice that someone commented to unassigned bugs. I don't have
to check bugs assigned to a developer.

On Sat, Dec 16, 2023 at 8:04 AM Alexey Proskuryakov  wrote:

>
> My approach would be to also disable the ability to watch the account, for
> the same reason of reducing exposure of accidental postings.
>
> Would you mind sharing your use case? Bugs assigned to webkit-unassigned
> are not a very well defined set of bugs, so perhaps there is another
> solution that works.
>
> - Alexey
>
> 15 дек. 2023 г., в 2:25 PM, Fujii Hironori via webkit-dev <
> webkit-dev@lists.webkit.org> написал(а):
>
> I check it every day. Can I receive the same mails by setting my user
> watching to webkit-unassig...@lists.webkit.org?
>
> On Sat, Dec 16, 2023 at 7:12 AM Alexey Proskuryakov via webkit-dev <
> webkit-dev@lists.webkit.org> wrote:
>
>> Hello,
>>
>> Does anybody make use of the webkit-unassigned mailing list? I'd like to
>> disable it, to reduce exposure of spam and accidental postings.
>>
>> - Alexey
>> ___
>> 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] webkit-unassigned

[Alexey Proskuryakov via webkit-dev]

My approach would be to also disable the ability to watch the account, for the 
same reason of reducing exposure of accidental postings.

Would you mind sharing your use case? Bugs assigned to webkit-unassigned are 
not a very well defined set of bugs, so perhaps there is another solution that 
works.

- Alexey

15 дек. 2023 г., в 2:25 PM, Fujii Hironori via webkit-dev 
 написал(а):

I check it every day. Can I receive the same mails by setting my user watching 
to webkit-unassig...@lists.webkit.org 
<mailto:webkit-unassig...@lists.webkit.org> ?

On Sat, Dec 16, 2023 at 7:12 AM Alexey Proskuryakov via webkit-dev 
mailto:webkit-dev@lists.webkit.org> > wrote:
Hello,

Does anybody make use of the webkit-unassigned mailing list? I'd like to 
disable it, to reduce exposure of spam and accidental postings.

- Alexey
_______
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] webkit-unassigned

[Fujii Hironori via webkit-dev]

I check it every day. Can I receive the same mails by setting my user
watching to webkit-unassig...@lists.webkit.org?

On Sat, Dec 16, 2023 at 7:12 AM Alexey Proskuryakov via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> Hello,
>
> Does anybody make use of the webkit-unassigned mailing list? I'd like to
> disable it, to reduce exposure of spam and accidental postings.
>
> - Alexey
> ___________
> 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] webkit-unassigned

[Alexey Proskuryakov via webkit-dev]

Hello,

Does anybody make use of the webkit-unassigned mailing list? I'd like to 
disable it, to reduce exposure of spam and accidental postings.

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

Re: [webkit-dev] Meaning of '7' in WebKit Versioning

[Timothy Hatcher via webkit-dev]

Your research is on the right track. The prefix originally reflected the minor 
dot-number from Mac OS X's version naming convention.

I implemented this versioning scheme many years ago to address versioning 
conflicts with the OS X installer. Safari updates, which shipped to older OS 
versions, were also included in new OS releases. To ensure the OS installer 
updated WebKit and Safari correctly, distinct bundle version numbers were 
necessary, as these components were built with different feature flags 
depending on the target SDK version (they were not intended for use outside the 
OS version they were compiled against). Thus, the version number's prefix was 
introduced to differentiate these versions and ensure proper file updates 
during installation (since 7616.1.20 is larger, thus newer to the installer, 
than 6616.1.20).

This versioning scheme isn't needed anymore, which is why the prefix number 
hasn't changed in the last few years.

— Timothy Hatcher

> On Oct 29, 2023, at 10:07 PM, 강수진 via webkit-dev 
>  wrote:
> 
> Meaning of '7' in WebKit Versioning
> 
> Hello,
> 
> I have a question about the versioning rules in WebKit.
> 
> I am aware that the version of WebKit used varies based on the iOS version. 
> For example, in iOS 17.0, the WebKit framework's WebKit.tbd file shows the 
> current version as 616.1.27, while in iOS 16.4, it's 615.1.26.
> 
> When I checked the corresponding source for each version on WebKit's GitHub, 
> I noticed that the tags for these versions are labeled as WebKit-7616.1.20.
> 
> Upon inspecting Version.xcconfig, I found that 616.1.20 represents the Major, 
> Minor, and Tiny versions, respectively. However, I couldn't determine the 
> significance of '7'.
> 
> I speculated that '7' might represent the SYSTEM_VERSION_PREFIX since 
> BUNDLE_VERSION_Production is set to $(SYSTEM_VERSION_PREFIX)$(FULL_VERSION); 
> in the same file. But considering the system version prefix for iPhone SDK is 
> set to 8, '7' couldn't denote that.
> 
> After some research, I found that '7' signifies the release year of Mac OS 
> 10.7 (Lion), which was launched in 2011.
> 
> Could you please clarify the meaning of '7' in tags like WebKit-7616.1.20?
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org <mailto: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] Approving / Rejects PRs on GitHub when not a reviewer?

[Ryosuke Niwa via webkit-dev]

I don't think non-reviewers should be able to reject/block PRs as well.- R. NiwaOn Nov 29, 2023, at 07:45, Chris Dumez via webkit-dev  wrote:FYI, our official documentation on WebKit.org says:```Making unofficial reviews before you become a reviewer is encouraged. This is an excellent way to show your skills. Note that you should not put r+ nor r- on patches in such unofficial reviews.```I guess this wan’t updated after the move to GitHub. For me, no r+ or r- on bugzilla translates to no approve / deny PRs on GitHub. So I simply wish we’d start enforcing this policy again.Having the tools help us would be great but I don’t think it stops us from enforcing our own policies like we used to.On Nov 28, 2023, at 1:58 PM, Michael Catanzaro  wrote:On Tue, Nov 28 2023 at 01:23:12 PM -0800, Chris Dumez via webkit-dev  wrote:I´m on board if it also cancels PR rejections from non-reviewers, not just approvals. I don´t see how approvals differ from rejections.Sure. It doesn't really matter whether rejections are canceled or not, because the important part of the rejection is the comments that were added, not the rejection status itself. A rejection from a non-reviewer is not effective anyway, so it's fine to have a bot clarify that.Michael___webkit-dev mailing listwebkit-dev@lists.webkit.orghttps://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] Approving / Rejects PRs on GitHub when not a reviewer?

[Chris Dumez via webkit-dev]

> On Nov 28, 2023, at 4:06 PM, Jean-Yves Avenard  
> wrote:
> 
> Hi
> 
>> On 29 Nov 2023, at 9:44 am, Chris Dumez via webkit-dev 
>>  wrote:
>> 
>> FYI, our official documentation on WebKit.org <http://webkit.org/> says:
>> ```
>> Making unofficial reviews before you become a reviewer is encouraged. This 
>> is an excellent way to show your skills. Note that you should not put r+ nor 
>> r- on patches in such unofficial reviews.
>> ```
>> I guess this wan’t updated after the move to GitHub. For me, no r+ or r- on 
>> bugzilla translates to no approve / deny PRs on GitHub. So I simply wish 
>> we’d start enforcing this policy again.
>> 
>> Having the tools help us would be great but I don’t think it stops us from 
>> enforcing our own policies like we used to.
> 
> Personally, I’ve been requesting non-official reviewers to review my patches 
> because I know that their skill set is perfectly matched (and it will help 
> make them official reviewer)
> 
> Having them giving r+ explicitly is, I find, easier to spot than looking 
> through the often busy GitHub page to find the comments.

Even if someone approves, you’d still need to find the comments. r+ with 
comments is super common.

> 
> Could we relax the ability to give informal r+ review to people with commit 
> rights? 

They can just leave a comment saying the patch looks good. They don’t have to 
approve the PR. Approving the PR means nothing since it won’t let you merge 
your PR.
People are expected to wait for an official review to trigger the merge queue, 
we’re currently making it harder than it needs to be if we have an official 
review or not.

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

Re: [webkit-dev] Approving / Rejects PRs on GitHub when not a reviewer?

[Jean-Yves Avenard via webkit-dev]

Hi

> On 29 Nov 2023, at 9:44 am, Chris Dumez via webkit-dev 
>  wrote:
> 
> FYI, our official documentation on WebKit.org <http://webkit.org/> says:
> ```
> Making unofficial reviews before you become a reviewer is encouraged. This is 
> an excellent way to show your skills. Note that you should not put r+ nor r- 
> on patches in such unofficial reviews.
> ```
> I guess this wan’t updated after the move to GitHub. For me, no r+ or r- on 
> bugzilla translates to no approve / deny PRs on GitHub. So I simply wish we’d 
> start enforcing this policy again.
> 
> Having the tools help us would be great but I don’t think it stops us from 
> enforcing our own policies like we used to.

Personally, I’ve been requesting non-official reviewers to review my patches 
because I know that their skill set is perfectly matched (and it will help make 
them official reviewer)

Having them giving r+ explicitly is, I find, easier to spot than looking 
through the often busy GitHub page to find the comments.

Could we relax the ability to give informal r+ review to people with commit 
rights? 

(And it’s also great to be able to provide stats later to say see, that person 
did XX informal reviews :) )

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

Re: [webkit-dev] Approving / Rejects PRs on GitHub when not a reviewer?

[Chris Dumez via webkit-dev]

FYI, our official documentation on WebKit.org <http://webkit.org/> says:
```
Making unofficial reviews before you become a reviewer is encouraged. This is 
an excellent way to show your skills. Note that you should not put r+ nor r- on 
patches in such unofficial reviews.
```
I guess this wan’t updated after the move to GitHub. For me, no r+ or r- on 
bugzilla translates to no approve / deny PRs on GitHub. So I simply wish we’d 
start enforcing this policy again.

Having the tools help us would be great but I don’t think it stops us from 
enforcing our own policies like we used to.

> On Nov 28, 2023, at 1:58 PM, Michael Catanzaro  wrote:
> 
> On Tue, Nov 28 2023 at 01:23:12 PM -0800, Chris Dumez via webkit-dev 
>  wrote:
>> I´m on board if it also cancels PR rejections from non-reviewers, not just 
>> approvals. I don´t see how approvals differ from rejections.
> 
> Sure. It doesn't really matter whether rejections are canceled or not, 
> because the important part of the rejection is the comments that were added, 
> not the rejection status itself. A rejection from a non-reviewer is not 
> effective anyway, so it's fine to have a bot clarify that.
> 
> Michael
> 
> 

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

Re: [webkit-dev] Approving / Rejects PRs on GitHub when not a reviewer?

[Michael Catanzaro via webkit-dev]

On Tue, Nov 28 2023 at 01:23:12 PM -0800, Chris Dumez via webkit-dev 
 wrote:
I’m on board if it also cancels PR rejections from non-reviewers, 
not just approvals. I don’t see how approvals differ from 
rejections.


Sure. It doesn't really matter whether rejections are canceled or not, 
because the important part of the rejection is the comments that were 
added, not the rejection status itself. A rejection from a non-reviewer 
is not effective anyway, so it's fine to have a bot clarify that.


Michael


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

Re: [webkit-dev] Approving / Rejects PRs on GitHub when not a reviewer?

[Jonathan Bedard via webkit-dev]

> Hi,
> 
> Back in the Bugzilla days, only reviewers were allowed to r+ or r- patches. 
> Non-reviewers were - of course - encouraged to do informal reviews but they 
> would do so by leaving comments. They would never r+ / r-.
> 
> Since we?ve moved to Github, it seems we have become a lot more lax about 
> this and I have seen non-reviewers approve and reject PRs, not just leaving 
> comments.
> My understanding is that there is no way to prevent this with Github but 
> could we at least make it a policy that non-reviewers should not approve / 
> reject PRs and only leave comments instead?

To provide some context, one of the reasons I didn’t attempt to exactly 
replicate Bugzilla’s behavior when porting our review mechanisms to GitHub was 
that Bugzilla only allows a single reviewer, which meant that an r+ would 
naturally clobber an r-, regardless of who gave the r- initially. Even in 
Bugzilla, non-reviewers could give r+es or r-es, it’s just that Commit-Queue 
wouldn’t respect them.

> The reason I would like us to make enforce this rule is that I find it 
> confusing. We have a lot of new comers in the project and I do not always 
> know if a person is a reviewer or not yet. I imagine it may be even more 
> confusing for non-Apple people.

I agree with this, especially since folks GitHub usernames are not always 
obvious.

> I have in some cases not reviewed patches because I had seen the "green 
> check? and thought the PR already had been approved.
> I have also seen cases of PRs rejected, asking the author to do more work, 
> that I didn?t feel was necessary.
> There is no easy way from the GitHub UI to tell if the person who 
> approved/rejected your PR is actually a reviewer, as far as I know.

I think it’s fair for a non-reviewer to “Request Changes” on a PR, it’s often 
the case that a non-reviewer has comments that should block a change from 
landing. If a reviewer (or even the PR author) thinks that the blocking comment 
has been addressed, they can “re-request review” which will get-rid of symbol 
until the account whose review is requested re-reviews the PR.

I think this also points to the right way to address the confusion for r+es 
(which I think are the bigger issue): if we formally make our policy that 
non-reviewers should not leave a persistent “Approved” checkmark on a PR, we 
could have EWS listen for PR approvals and simply request a re-review any time 
a non-reviewer approves a PR. In practice, this will mean that a non-reviewer 
which approves a PR will have their approval nearly instantly removed by a bot. 
We could even have the bot comment something like “Unofficial r+ from 
non-reviewer ” to make exactly what’s going on clear.

The issue with a policy change like this one is that it’s WebKit reviewers who 
deeply understand the policies of the WebKit project, but it’s non-reviewers 
who need to change their behavior. If we don’t back this policy clarification 
with a tools change, I think non-reviewers are unlikely to be aware project 
policy has changed.

> 
> What do you think?
> 
> Thanks,
> Chris Dumez.

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

Re: [webkit-dev] Approving / Rejects PRs on GitHub when not a reviewer?

[Tim Nguyen via webkit-dev]

(I already answered this, but that message failed to reach the mailing list, 
sorry to the folks receiving my reply twice)

Everyone in the WebKit Github organization gets a green checkmark afaik (that’s 
just how the Github UI works), so as of right now that means everyone in 
contributors.json with a Github username.

> On Nov 28, 2023, at 12:34 PM, Darin Adler via webkit-dev 
>  wrote:
> 
>> On Nov 28, 2023, at 3:02 PM, Chris Dumez wrote:
>> 
>> FYI, my understanding is that the person gets a *green* checkmark when the 
>> person is present in contributors.json (common case), even if not marked as 
>> a reviewer in that file.
> 
> Does anyone know why we chose green for all contributors rather than green 
> for reviewers?
> 
> — 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] Approving / Rejects PRs on GitHub when not a reviewer?

[Darin Adler via webkit-dev]

> On Nov 28, 2023, at 3:02 PM, Chris Dumez wrote:
> 
> FYI, my understanding is that the person gets a *green* checkmark when the 
> person is present in contributors.json (common case), even if not marked as a 
> reviewer in that file.

Does anyone know why we chose green for all contributors rather than green for 
reviewers?

— Darin
_______
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Approving / Rejects PRs on GitHub when not a reviewer?

[J Pascoe via webkit-dev]

I think we could fix this by making EWS smarter. 

There is GitHub API to list and “dismiss” reviews on a PR that repository 
admins have permissions to use. 

https://docs.github.com/en/rest/pulls/reviews?apiVersion=2022-11-28#dismiss-a-review-for-a-pull-request

Thanks,
Pascoe

> On Nov 28, 2023, at 12:02 PM, Chris Dumez via webkit-dev 
>  wrote:
> 
> 
>> On Nov 28, 2023, at 11:51 AM, Michael Catanzaro  
>> wrote:
>> 
>> On Tue, Nov 28 2023 at 10:27:41 AM -0800, Chris Dumez via webkit-dev 
>>  wrote:
>>> The reason I would like us to make enforce this rule is that I find it 
>>> confusing. We have a lot of new comers in the project and I do not always 
>>> know if a person is a reviewer or not yet. I imagine it may be even more 
>>> confusing for non-Apple people.
>>> I have in some cases not reviewed patches because I had seen the "green 
>>> check” and thought the PR already had been approved.
>> 
>> +1, if there is a green checkmark, then I assume that person is a reviewer. 
>> It's really confusing when non-reviewers add the green checkmark.
> 
> FYI, my understanding is that the person gets a *green* checkmark when the 
> person is present in contributors.json (common case), even if not marked as a 
> reviewer in that file.
> They get a *grey* checkmark when they’re not present in contributors.json 
> (not common). Also, the difference between green and grey for this tiny 
> checkmark is super subtle.
> 
> That said, most of the instances where I saw it happened was with a green 
> checkmark.
> 
> Either way, I think non-reviewers should not approve/reject PR, just add 
> comments to avoid confusion.
> ___
> 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] Approving / Rejects PRs on GitHub when not a reviewer?

[Chris Dumez via webkit-dev]

> On Nov 28, 2023, at 11:51 AM, Michael Catanzaro  wrote:
> 
> On Tue, Nov 28 2023 at 10:27:41 AM -0800, Chris Dumez via webkit-dev 
>  wrote:
>> The reason I would like us to make enforce this rule is that I find it 
>> confusing. We have a lot of new comers in the project and I do not always 
>> know if a person is a reviewer or not yet. I imagine it may be even more 
>> confusing for non-Apple people.
>> I have in some cases not reviewed patches because I had seen the "green 
>> check” and thought the PR already had been approved.
> 
> +1, if there is a green checkmark, then I assume that person is a reviewer. 
> It's really confusing when non-reviewers add the green checkmark.

FYI, my understanding is that the person gets a *green* checkmark when the 
person is present in contributors.json (common case), even if not marked as a 
reviewer in that file.
They get a *grey* checkmark when they’re not present in contributors.json (not 
common). Also, the difference between green and grey for this tiny checkmark is 
super subtle.

That said, most of the instances where I saw it happened was with a green 
checkmark.

Either way, I think non-reviewers should not approve/reject PR, just add 
comments to avoid confusion.
___________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Approving / Rejects PRs on GitHub when not a reviewer?

[Tim Horton via webkit-dev]

+1! The bugzilla-style “unofficial r=me” comment was much clearer for exactly 
these reasons.

> On Nov 28, 2023, at 10:27 AM, Chris Dumez via webkit-dev 
>  wrote:
> 
> Hi,
> 
> Back in the Bugzilla days, only reviewers were allowed to r+ or r- patches. 
> Non-reviewers were - of course - encouraged to do informal reviews but they 
> would do so by leaving comments. They would never r+ / r-.
> 
> Since we’ve moved to Github, it seems we have become a lot more lax about 
> this and I have seen non-reviewers approve and reject PRs, not just leaving 
> comments.
> My understanding is that there is no way to prevent this with Github but 
> could we at least make it a policy that non-reviewers should not approve / 
> reject PRs and only leave comments instead?
> 
> The reason I would like us to make enforce this rule is that I find it 
> confusing. We have a lot of new comers in the project and I do not always 
> know if a person is a reviewer or not yet. I imagine it may be even more 
> confusing for non-Apple people.
> 
> I have in some cases not reviewed patches because I had seen the "green 
> check” and thought the PR already had been approved.
> I have also seen cases of PRs rejected, asking the author to do more work, 
> that I didn’t feel was necessary.
> There is no easy way from the GitHub UI to tell if the person who 
> approved/rejected your PR is actually a reviewer, as far as I know.
> 
> What do you think?
> 
> Thanks,
> Chris Dumez.
> ___
> 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] Approving / Rejects PRs on GitHub when not a reviewer?

[Chris Dumez via webkit-dev]

Hi,

Back in the Bugzilla days, only reviewers were allowed to r+ or r- patches. 
Non-reviewers were - of course - encouraged to do informal reviews but they 
would do so by leaving comments. They would never r+ / r-.

Since we’ve moved to Github, it seems we have become a lot more lax about this 
and I have seen non-reviewers approve and reject PRs, not just leaving comments.
My understanding is that there is no way to prevent this with Github but could 
we at least make it a policy that non-reviewers should not approve / reject PRs 
and only leave comments instead?

The reason I would like us to make enforce this rule is that I find it 
confusing. We have a lot of new comers in the project and I do not always know 
if a person is a reviewer or not yet. I imagine it may be even more confusing 
for non-Apple people.

I have in some cases not reviewed patches because I had seen the "green check” 
and thought the PR already had been approved.
I have also seen cases of PRs rejected, asking the author to do more work, that 
I didn’t feel was necessary.
There is no easy way from the GitHub UI to tell if the person who 
approved/rejected your PR is actually a reviewer, as far as I know.

What do you think?

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

Re: [webkit-dev] Web Authn support for webkitgtk

[Michael Catanzaro via webkit-dev]

Hi,

We've hired a contractor to work on this as part of:

https://foundation.gnome.org/2023/11/09/gnome-recognized-as-public-interest-infrastructure/

However no work has started yet. The first step will be to get a 
working portal:


https://github.com/flatpak/xdg-desktop-portal/issues/989

(Without a portal, WebKit would have to use libfido2 directly, which 
will be blocked by WebKit's bubblewrap sandbox or the flatpak sandbox. 
So there is no point to attempting that approach; it has to go via a 
portal.)


The portal might be a good place to start helping since it doesn't 
require modifying WebKit and we don't have a clear sense of direction 
regarding the portal yet. We need to figure out what the D-Bus API for 
the portal should look like. There is a "downstream" or experimental 
project xdg-credentials-portal that we might want to use as a basis, 
but we don't know exactly how. So commenting in that issue and trying 
to build consensus on what the API should look like could be a good way 
to push this forward.


Michael


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

[webkit-dev] Web Authn support for webkitgtk

[ChandraSekharVarma Dasaraju via webkit-dev]

Hi ,


Are there any plans  to enable  Web Authn support  for   webkitgtk ?

I see below bug is  submitted  but not sure if there is any work going on
or not ?
https://bugs.webkit.org/show_bug.cgi?id=205350

Thanks for your help.

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

[webkit-dev] Meaning of '7' in WebKit Versioning

[강수진 via webkit-dev]

Meaning of '7' in WebKit Versioning
Hello,
I have a question about the versioning rules in WebKit.
I am aware that the version of WebKit used varies based on the iOS version. For 
example, in iOS 17.0, the WebKit framework's WebKit.tbd file shows the current 
version as 616.1.27, while in iOS 16.4, it's 615.1.26.
When I checked the corresponding source for each version on WebKit's GitHub, I 
noticed that the tags for these versions are labeled as WebKit-7616.1.20.
Upon inspecting Version.xcconfig, I found that 616.1.20 represents the Major, 
Minor, and Tiny versions, respectively. However, I couldn't determine the 
significance of '7'.
I speculated that '7' might represent the SYSTEM_VERSION_PREFIX since 
BUNDLE_VERSION_Production is set to $(SYSTEM_VERSION_PREFIX)$(FULL_VERSION); in 
the same file. But considering the system version prefix for iPhone SDK is set 
to 8, '7' couldn't denote that.
After some research, I found that '7' signifies the release year of Mac OS 10.7 
(Lion), which was launched in 2011.
Could you please clarify the meaning of '7' in tags like WebKit-7616.1.20?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] 2023 WebKit Contributors Meeting — Save the Date

[Jonathan Davis via webkit-dev]

Hello WebKit Contributors, save the date!

You are invited to participate in the 2023 WebKit Contributors Meeting at the 
Apple Park campus or available online via WebEx on Tuesday, October 24th, from 
1 PM to around 6 PM Pacific and Wednesday, October 25th, from 8 AM to around 2 
PM Pacific.

To attend, you must be an active contributor to the WebKit open-source project. 
The meeting will be free of charge, and registration will open soon. 
Registration is required whether you are attending in person or virtually. You 
can find more details about the event and register when registration is open at 
the 2023 WebKit Contributors Meeting page: https://webkit.org/meeting/

**Health & Safety**
For the safety of everyone at Apple Park, in-person attendees will be required 
to wear a mask indoors except while eating and drinking. If you are feeling 
ill, we encourage you to join remotely using WebEx. We also strongly encourage 
testing for COVID prior to attending in-person and attending online if you 
receive any positive result.

This year’s event is being organized by Jon Davis, Brian Kardell, Eric Meyer, 
and Jen Simmons. The event will feature presentation-led discussions of 10-40 
minutes long, followed by queue-moderated discussion. There will also be a 
lightning talk segment if you have a topic you can present in less than 10 
minutes.

If you have a topic to present for discussion, please email any of the 
organizers or message them on WebKit Slack.

Feel free to reach out to any of the organizers with ideas or questions about 
this year’s online event.

We’re looking forward to seeing you there!

---
Jon Davis, on behalf of the WebKit Contributors Meeting Organizers
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Phasing out explicit MIPS support

[Angelos Oikonomopoulos via webkit-dev]

On 9/13/23 12:40, Angelos Oikonomopoulos via webkit-dev wrote:

We (Igalia) plan to discontinue our maintenance of WebKit on MIPS.


To be clear, this refers to 32-bit MIPS.

Angelos

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

[webkit-dev] Phasing out explicit MIPS support

[Angelos Oikonomopoulos via webkit-dev]

We (Igalia) plan to discontinue our maintenance of WebKit on MIPS.

- First, we will stop the MIPS buildbots for JSC on November 1st 2023.
- Soon afterwards, we plan to submit a patch to remove any MIPS-specific 
code (mainly JIT support).


The upcoming WPE 2.42 should be the last stable version to include 
platform-specific optimisation (such as JITs) for MIPS.


Beyond that, WebKit and JSC should keep working on MIPS using the CLOOP 
backend (though, if anyone depends on JSC on MIPS, they should test that 
it does). However, there will be no JIT support and the code will not 
even be build-tested.


If anyone has an interest in keeping WebKit working well on MIPS, please 
step up or contact us about it directly.


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

Re: [webkit-dev] Smart Pointers Usage Guidelines

[Ryosuke Niwa via webkit-dev]

> On Aug 21, 2023, at 4:51 PM, Ryosuke Niwa via webkit-dev 
>  wrote:
> 
>> On Aug 21, 2023, at 4:50 PM, Tim Horton  wrote:
>> 
>>> On Aug 21, 2023, at 4:42 PM, Ryosuke Niwa  wrote:
>>> 
>>>> On Aug 21, 2023, at 4:41 PM, Darin Adler  wrote:
>>>> 
>>>>> On Aug 21, 2023, at 4:39 PM, Ryosuke Niwa  wrote:
>>>>> 
>>>>> Alternatively, we could add a new member function which returns 
>>>>> CheckedPtr like `pageChecked()`.
>>>> 
>>>> Yes, I think that would be a good approach that would complement the 
>>>> static checker.
>>> 
>>> Okay, let’s go with this solution since others have expressed concerns for 
>>> ref churns in the past.
>> 
>> So, to be clear, this example:
>> 
>>> page()->document()->foo()
>> 
>> 
>> would become:
>> 
>>> page()->documentChecked()->foo()?
>> 
>> (only `checked` for the deepest getter before the complex call)?
> 
> Yes.

Now that I’m thinking about this more, we should probably call this 
checkedDocument() to be aligned with protectedX pattern.

- R. Niwa

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

Re: [webkit-dev] Smart Pointers Usage Guidelines

[Ryosuke Niwa via webkit-dev]

> On Aug 21, 2023, at 4:50 PM, Tim Horton  wrote:
> 
> 
> 
>> On Aug 21, 2023, at 4:42 PM, Ryosuke Niwa  wrote:
>> 
>> 
>> 
>>> On Aug 21, 2023, at 4:41 PM, Darin Adler  wrote:
>>> 
>>>> On Aug 21, 2023, at 4:39 PM, Ryosuke Niwa  wrote:
>>>> 
>>>> Alternatively, we could add a new member function which returns CheckedPtr 
>>>> like `pageChecked()`.
>>> 
>>> Yes, I think that would be a good approach that would complement the static 
>>> checker.
>> 
>> Okay, let’s go with this solution since others have expressed concerns for 
>> ref churns in the past.
> 
> So, to be clear, this example:
> 
>> page()->document()->foo()
> 
> 
> would become:
> 
>> page()->documentChecked()->foo()?
> 
> (only `checked` for the deepest getter before the complex call)?

Yes.

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

Re: [webkit-dev] Smart Pointers Usage Guidelines

[Ryosuke Niwa via webkit-dev]

> On Aug 21, 2023, at 4:41 PM, Darin Adler  wrote:
> 
>> On Aug 21, 2023, at 4:39 PM, Ryosuke Niwa  wrote:
>> 
>> Alternatively, we could add a new member function which returns CheckedPtr 
>> like `pageChecked()`.
> 
> Yes, I think that would be a good approach that would complement the static 
> checker.

Okay, let’s go with this solution since others have expressed concerns for ref 
churns in the past.

- R. Niwa

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

Re: [webkit-dev] Smart Pointers Usage Guidelines

[Darin Adler via webkit-dev]

> On Aug 21, 2023, at 4:39 PM, Ryosuke Niwa  wrote:
> 
> Alternatively, we could add a new member function which returns CheckedPtr 
> like `pageChecked()`.

Yes, I think that would be a good approach that would complement the static 
checker.

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

Re: [webkit-dev] Smart Pointers Usage Guidelines

[Tim Horton via webkit-dev]

> On Aug 21, 2023, at 4:39 PM, Ryosuke Niwa  wrote:
> 
> 
>> On Aug 21, 2023, at 4:34 PM, Darin Adler  wrote:
>> 
>> 
>>> On Aug 21, 2023, at 4:31 PM, Tim Horton via webkit-dev 
>>>  wrote:
>>> 
>>>> One subtle thing is that even when a member variable is already Ref / 
>>>> RefPtr / CheckedRef / CheckedPtr, we must create another one in stack as 
>>>> seen here:
>>>> https://commits.webkit.org/267108@main
>>> 
>>> (I asked rniwa to send this mail because this patch surprised me, so I hope 
>>> now we can chat about it).
>>> 
>>> The scope of this rule, and the … lack of elegance … at so many callsites 
>>> worries me a bit. If it’s possible to automate enforcement, that might help 
>>> with part of the problem, but it’s also just really not very pretty, and I 
>>> wonder if someone can come up with some clever alternative solution before 
>>> we go too far down this path (not me!).
>>> 
>>> Alternatively, it’s possible other people OK with this syntax/requirement 
>>> and I should just get over it. What do you all think?
>> 
>> I hope we can make this better by using a getter function that returns a 
>> CheckedPtr so instead of writing CheckedPtr { _page }, we would write page().
> 
> One drawback making a member function return CheckedPtr is that then code 
> like this: `page()->document()->foo()` would cause a ref churn.
> 
> Maybe we don’t care about such ref churns?

How can we tell!

> But then a simpler rule to deploy will be that every function must return 
> CheckedRef/CheckedPtr/Ref/RefPtr.

+1 to that rule instead of the one in Wenson’s patch.

> Alternatively, we could add a new member function which returns CheckedPtr 
> like `pageChecked()`.

Would rather Darin’s plan. I don’t want to have to think about CheckedPtr every 
5 seconds.

> - R. Niwa
> 

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

Re: [webkit-dev] Smart Pointers Usage Guidelines

[Ryosuke Niwa via webkit-dev]

> On Aug 21, 2023, at 4:34 PM, Darin Adler  wrote:
> 
> 
>> On Aug 21, 2023, at 4:31 PM, Tim Horton via webkit-dev 
>>  wrote:
>> 
>>> One subtle thing is that even when a member variable is already Ref / 
>>> RefPtr / CheckedRef / CheckedPtr, we must create another one in stack as 
>>> seen here:
>>> https://commits.webkit.org/267108@main
>> 
>> (I asked rniwa to send this mail because this patch surprised me, so I hope 
>> now we can chat about it).
>> 
>> The scope of this rule, and the … lack of elegance … at so many callsites 
>> worries me a bit. If it’s possible to automate enforcement, that might help 
>> with part of the problem, but it’s also just really not very pretty, and I 
>> wonder if someone can come up with some clever alternative solution before 
>> we go too far down this path (not me!).
>> 
>> Alternatively, it’s possible other people OK with this syntax/requirement 
>> and I should just get over it. What do you all think?
> 
> I hope we can make this better by using a getter function that returns a 
> CheckedPtr so instead of writing CheckedPtr { _page }, we would write page().

One drawback making a member function return CheckedPtr is that then code like 
this: `page()->document()->foo()` would cause a ref churn.

Maybe we don’t care about such ref churns? But then a simpler rule to deploy 
will be that every function must return CheckedRef/CheckedPtr/Ref/RefPtr.

Alternatively, we could add a new member function which returns CheckedPtr like 
`pageChecked()`.

- R. Niwa

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

Re: [webkit-dev] Smart Pointers Usage Guidelines

[Tim Horton via webkit-dev]

> On Aug 21, 2023, at 4:34 PM, Darin Adler  wrote:
> 
> 
>> On Aug 21, 2023, at 4:31 PM, Tim Horton via webkit-dev 
>>  wrote:
>> 
>>> One subtle thing is that even when a member variable is already Ref / 
>>> RefPtr / CheckedRef / CheckedPtr, we must create another one in stack as 
>>> seen here:
>>> https://commits.webkit.org/267108@main
>> 
>> (I asked rniwa to send this mail because this patch surprised me, so I hope 
>> now we can chat about it).
>> 
>> The scope of this rule, and the … lack of elegance … at so many callsites 
>> worries me a bit. If it’s possible to automate enforcement, that might help 
>> with part of the problem, but it’s also just really not very pretty, and I 
>> wonder if someone can come up with some clever alternative solution before 
>> we go too far down this path (not me!).
>> 
>> Alternatively, it’s possible other people OK with this syntax/requirement 
>> and I should just get over it. What do you all think?
> 
> I hope we can make this better by using a getter function that returns a 
> CheckedPtr so instead of writing CheckedPtr { _page }, we would write page().

That, for example, seems wildly preferable.

> — Darin

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

Re: [webkit-dev] Smart Pointers Usage Guidelines

[Darin Adler via webkit-dev]

> On Aug 21, 2023, at 4:31 PM, Tim Horton via webkit-dev 
>  wrote:
> 
>> One subtle thing is that even when a member variable is already Ref / RefPtr 
>> / CheckedRef / CheckedPtr, we must create another one in stack as seen here:
>> https://commits.webkit.org/267108@main
> 
> (I asked rniwa to send this mail because this patch surprised me, so I hope 
> now we can chat about it).
> 
> The scope of this rule, and the … lack of elegance … at so many callsites 
> worries me a bit. If it’s possible to automate enforcement, that might help 
> with part of the problem, but it’s also just really not very pretty, and I 
> wonder if someone can come up with some clever alternative solution before we 
> go too far down this path (not me!).
> 
> Alternatively, it’s possible other people OK with this syntax/requirement and 
> I should just get over it. What do you all think?

I hope we can make this better by using a getter function that returns a 
CheckedPtr so instead of writing CheckedPtr { _page }, we would write page().

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

Re: [webkit-dev] Smart Pointers Usage Guidelines

[Tim Horton via webkit-dev]

> On Aug 21, 2023, at 4:25 PM, Ryosuke Niwa via webkit-dev 
>  wrote:
> 
> Hi all,
> 
> It has been a while since I last announced the plan to adopt smart pointers 
> using clang static analyzer:
> https://lists.webkit.org/pipermail/webkit-dev/2020-September/031386.html
> 
> Here are some updates.
> 
> 
> 1. We’ve made a progress in implementing all the rules including rules for 
> local variables in clang static analyzer:
> https://github.com/WebKit/WebKit/wiki/Smart-Pointer-Usage-Guidelines#rules-for-using-ref-counted-objects
> 
> 
> 2. We also have a new kind of smart pointers: CheckedRef 
> <https://github.com/WebKit/WebKit/blob/main/Source/WTF/wtf/CheckedRef.h> / 
> CheckedPtr 
> <https://github.com/WebKit/WebKit/blob/main/Source/WTF/wtf/CheckedPtr.h>. 
> These behave like Ref and RefPtr in that they increment & decrement a counter 
> in an object but unlike them don’t extend the lifetime of the object. 
> Instead, the destructor of the base object release asserts that there are no 
> live CheckedRef / CheckedPtr left.
> 
> I added a new section in the guide describing when to use each smart pointer 
> type:
> https://github.com/WebKit/WebKit/wiki/Smart-Pointer-Usage-Guidelines#when-to-use-which-smart-pointer
> 
> 
> 3. I wanted to describe what applying these smart pointer rules mean. A lot 
> of code changes needed for this work involves creating Ref / RefPtr / 
> CheckedRef / CheckedPtr in stack:
> https://commits.webkit.org/267082@main
> 
> One subtle thing is that even when a member variable is already Ref / RefPtr 
> / CheckedRef / CheckedPtr, we must create another one in stack as seen here:
> https://commits.webkit.org/267108@main

(I asked rniwa to send this mail because this patch surprised me, so I hope now 
we can chat about it).

The scope of this rule, and the … lack of elegance … at so many callsites 
worries me a bit. If it’s possible to automate enforcement, that might help 
with part of the problem, but it’s also just really not very pretty, and I 
wonder if someone can come up with some clever alternative solution before we 
go too far down this path (not me!).

Alternatively, it’s possible other people OK with this syntax/requirement and I 
should just get over it. What do you all think?

> This is because these member variables can be cleared during the course of 
> invoking a non-trivial function; or put it another way, it’s not immediately 
> obvious from the code inspection that the object pointed to stays alive over 
> the course of a non-trivial function call.
> 
> - 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] Smart Pointers Usage Guidelines

[Ryosuke Niwa via webkit-dev]

Hi all,

It has been a while since I last announced the plan to adopt smart pointers 
using clang static analyzer:
https://lists.webkit.org/pipermail/webkit-dev/2020-September/031386.html

Here are some updates.


1. We’ve made a progress in implementing all the rules including rules for 
local variables in clang static analyzer:
https://github.com/WebKit/WebKit/wiki/Smart-Pointer-Usage-Guidelines#rules-for-using-ref-counted-objects


2. We also have a new kind of smart pointers: CheckedRef 
<https://github.com/WebKit/WebKit/blob/main/Source/WTF/wtf/CheckedRef.h> / 
CheckedPtr 
<https://github.com/WebKit/WebKit/blob/main/Source/WTF/wtf/CheckedPtr.h>. These 
behave like Ref and RefPtr in that they increment & decrement a counter in an 
object but unlike them don’t extend the lifetime of the object. Instead, the 
destructor of the base object release asserts that there are no live CheckedRef 
/ CheckedPtr left.

I added a new section in the guide describing when to use each smart pointer 
type:
https://github.com/WebKit/WebKit/wiki/Smart-Pointer-Usage-Guidelines#when-to-use-which-smart-pointer


3. I wanted to describe what applying these smart pointer rules mean. A lot of 
code changes needed for this work involves creating Ref / RefPtr / CheckedRef / 
CheckedPtr in stack:
https://commits.webkit.org/267082@main

One subtle thing is that even when a member variable is already Ref / RefPtr / 
CheckedRef / CheckedPtr, we must create another one in stack as seen here:
https://commits.webkit.org/267108@main

This is because these member variables can be cleared during the course of 
invoking a non-trivial function; or put it another way, it’s not immediately 
obvious from the code inspection that the object pointed to stays alive over 
the course of a non-trivial function call.

- R. Niwa

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

Re: [webkit-dev] ENABLE macro placement between includes

[Kirsling, Ross via webkit-dev]

I would support specifying the common pattern in our styleguide.

Ross

From: Alex Christensen via webkit-dev 
Reply-To: Alex Christensen 
Date: Thursday, August 3, 2023 at 2:52 PM
To: Webkit Development List 
Subject: [webkit-dev] ENABLE macro placement between includes

Our coding style says to include config.h, then the primary header, then other 
headers.  It does not say where to put any ENABLE macros in that list.

We have about 1700 places where we follow this pattern:

#include "config.h"
#include "RemoteSampler.h"

#if ENABLE(GPU_PROCESS)
…
#endif

We have about 350 places where we follow this pattern:

#include "config.h"

#if ENABLE(WEBGL)

#include "WebGLUniformLocation.h"
…
#endif

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

[webkit-dev] constinit: C++20 tip about constexpr initialization for global variables

[Yusuke Suzuki via webkit-dev]

Hello WebKittens,

Now, our baseline is GCC 10, so I would like to introduce useful C++20 feature 
here, constinit.
https://en.cppreference.com/w/cpp/language/constinit

You can annotate the global variables etc. with `constinit`, like,

```
static constinit StaticStringImpl aboutBlankString { "about:blank" };
```

Tthe benefit is that, compiler knows the strong requirement that this variable 
must be initialized at compile-time (constexpr constructors).

Our global constructor warning is just a warning, so compilers typically allow 
compiling and at the very end, it emits a warning as an error.
So, at that time, we don't know what is breaking constexpr condition. For 
example,

```
/Volumes/WebKit/macOS/OpenSource/Source/WTF/wtf/URL.cpp:932:25: error: 
declaration requires a global constructor [-Werror,-Wglobal-constructors]
static StaticStringImpl aboutBlankString { "about:blank" };
```

You can see that *something* in StaticStringImpl breaks `constexpr`, but we 
cannot see what is breaking it, because, when emitting this warning, compiler 
already lost that information (and compiler just already compiled it via non 
constexpr, and at the very end, it emits warnings like this).

But if you annotate this variable with `constinit`, then compiler knows this 
requirement a-priori, thus,

```
/Users/yusukesuzuki/dev/OpenSource/Source/WTF/wtf/URL.cpp:932:35: error: 
variable does not have a constant initializer
static constinit StaticStringImpl aboutBlankString { "about:blank" };
/Users/yusukesuzuki/dev/OpenSource/Source/WTF/wtf/URL.cpp:932:8: note: required 
by 'constinit' specifier here
static constinit StaticStringImpl aboutBlankString { "about:blank" };
In file included from 
/Users/yusukesuzuki/dev/OpenSource/Source/WTF/wtf/URL.cpp:28:
In file included from 
/Users/yusukesuzuki/dev/OpenSource/Source/WTF/wtf/URL.h:28:
In file included from 
/Users/yusukesuzuki/dev/OpenSource/WebKitBuild/Release/usr/local/include/wtf/text/WTFString.h:28:
In file included from 
/Users/yusukesuzuki/dev/OpenSource/WebKitBuild/Release/usr/local/include/wtf/text/StringImpl.h:43:
/Users/yusukesuzuki/dev/OpenSource/WebKitBuild/Release/usr/local/include/wtf/text/WYHasher.h:248:28:
 note: cast that performs the conversions of a reinterpret_cast is not allowed 
in a constant expression
const uint8_t* p = (const uint8_t*)characters;
/Users/yusukesuzuki/dev/OpenSource/WebKitBuild/Release/usr/local/include/wtf/text/WYHasher.h:64:40:
 note: in call to 'computeHashImpl(&"about:blank"[0], 11, 0)'
return finalizeAndMaskTop8Bits(computeHashImpl(data, 
characterCount, 0));
/Users/yusukesuzuki/dev/OpenSource/WebKitBuild/Release/usr/local/include/wtf/text/WYHasher.h:76:16:
 note: in call to 'computeHashAndMaskTop8Bits(&"about:blank"[0], 11)'
return computeHashAndMaskTop8Bits(characters, 
charactersCount - 1);
In file included from 
/Users/yusukesuzuki/dev/OpenSource/Source/WTF/wtf/URL.cpp:28:
In file included from 
/Users/yusukesuzuki/dev/OpenSource/Source/WTF/wtf/URL.h:28:
In file included from 
/Users/yusukesuzuki/dev/OpenSource/WebKitBuild/Release/usr/local/include/wtf/text/WTFString.h:28:
/Users/yusukesuzuki/dev/OpenSource/WebKitBuild/Release/usr/local/include/wtf/text/StringImpl.h:1251:89:
 note: in call to 'computeLiteralHashAndMaskTop8Bits("about:blank")'
s_hashFlag8BitBuffer | s_hashFlagDidReportCost | stringKind | 
BufferInternal | (WYHasher::computeLiteralHashAndMaskTop8Bits(characters) << 
s_flagCount), ConstructWithConstExpr)
```

The compiler can tell directly what is breaking `constexpr` condition.

`constinit` is available from GCC 10, so it is now supported in all 
WebKit-supporting compilers.

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

[webkit-dev] ENABLE macro placement between includes

[Alex Christensen via webkit-dev]

Our coding style says to include config.h, then the primary header, then other 
headers.  It does not say where to put any ENABLE macros in that list.

We have about 1700 places where we follow this pattern:

#include "config.h"
#include "RemoteSampler.h"

#if ENABLE(GPU_PROCESS)
…
#endif

We have about 350 places where we follow this pattern:

#include "config.h"

#if ENABLE(WEBGL)

#include "WebGLUniformLocation.h"
…
#endif

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

[webkit-dev] Richard Robinson is now a WebKit reviewer

[Aditya Keerthi via webkit-dev]

Hello!

I’m pleased to announce that Richard Robinson is now a WebKit reviewer.

Richard has expertise in keyboard scrolling, printing, and editing. He is very 
eager to review WebKit code, so feel free to reach out to him for reviews.

Congratulations, Richard! 

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

[webkit-dev] Sammy Gill is now a WebKit Reviewer

[Brent Fulgham via webkit-dev]

Hi Folks!

I’m pleased to report that Sammy Gill is now a WebKit reviewer.

Sammy is well-versed in the Grid and Flex aspects of our rendering code, and is 
a great person to speak with about many of our new Interop and CSS features.

For now, he will be restricting his reviews to those bits of the layout and 
rendering stack he has the most experience.

Congratulations, Sammy!

Thanks,

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

Re: [webkit-dev] Finding when a platform was dropped

[Elliott Williams via webkit-dev]

On Apple platforms, we do not specifically “turn off” support for older OSes. 
WebKit’s build is configured to deploy to whichever SDK version you have 
installed.

That said, you can see when we stop building for a specific OS version in our 
continuous integration, which is a good indicator of when we drop support for 
it. Two ways to do this are:

1. Check the history of Tools/CISupport/ews-build/config.json. For example, 
https://github.com/WebKit/WebKit/commit/eb60908303ab4874a8926527756e19b6ae6e4cdb
 is when CI stopped building Big Sur.

2. On https://webkit.org/build-archives/, look at the latest commit for a macOS 
version. This shows that the last commit our infrastructure built for Big Sur 
was `261428@main`.

Every year, some time after removing CI support for an OS release, we actually 
strip out the conditional code for that version, at which point the build would 
truly break.

Hope this helps!
Elliott

> On Jul 8, 2023, at 09:55, Ben Huntsman via webkit-dev 
>  wrote:
> 
> Hi there-
>Not sure if this is the right place to ask, so please forgive me if this 
> is the wrong forum.
> 
>How would one go about determining what the last build of WebKit that 
> would compile on a given platform is?  For example, if I wanted to see when 
> support for MacOS 10.14, or 10.15, etc was dropped?
> 
>Thank you so much!
> 
> -Ben
> 
> _______________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


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

[webkit-dev] Finding when a platform was dropped

[Ben Huntsman via webkit-dev]

Hi there-
   Not sure if this is the right place to ask, so please forgive me if this is 
the wrong forum.

   How would one go about determining what the last build of WebKit that would 
compile on a given platform is?  For example, if I wanted to see when support 
for MacOS 10.14, or 10.15, etc was dropped?

   Thank you so much!

-Ben

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