Re: [webkit-dev] Initializing member variables
+1 for { } as well, for all the mentioned good reasons.
But just to be complete, there's one exception that should probably be noted
if/when we document this:
For classes that have a constructor taking `std::initializer_list` and other
constructors that take `T` (+ conversions), using braced-initialization will
*always* call the initializer_list one! In this case, we'd need to use
parentheses if another constructor was wanted. E.g.: `std::vector vb { 3,
2 }` -> [ 3 2 ], vs `std::vector vp(3, 2);` -> [ 2 2 2 ] (3 copies of
value 2)!
At a glance, I haven't found WK classes that have both types of competing
constructors together, so hopefully this should be a rare issue. May be worth
another guideline, like "If you define a constructor taking
std::initializer_list, avoid defining other constructors for similar
types"?
Cheers,
Gerald
> On 24 Sep 2024, at 02:35, Geoff Garen via webkit-dev
> wrote:
>
> +1 for { } because I like catching bugs.
>
> But also: If Chris is right that { } is the only way to handle types without
> constructors, and the goal is to pick one syntax, then { } is the only
> possible solution, because standardizing on = would require exceptions for
> types without constructors.
>
> Thanks,
> Geoff
>
>> On Sep 20, 2024, at 2:29 PM, Yusuke Suzuki via webkit-dev
>> wrote:
>>
>> I prefer { } style.
>> It can catch implicit narrowing bugs, which does not work with = style.
>>
>> Best regards,
>> - Yusuke
>>
>>> On Sep 19, 2024, at 4:13 PM, Jean-Yves Avenard via webkit-dev
>>> wrote:
>>>
>>>
>>>
>>>> On 20 Sep 2024, at 7:55 AM, Ryosuke Niwa via webkit-dev
>>>> wrote:
>>>>
>>>>
>>>> Should we do:
>>>>
>>>> struct Foo {
>>>> int bar = 0;
>>>> }
>>>>
>>>> Or
>>>>
>>>> struct Foo {
>>>> int bar { 0 };
>>>> }
>>>>
>>>> We do both at the moment.
>>>>
>>>> - R. Niwa
>>>
>>> I think `int bar = 0` reads better.
>>>
>>> I only ever see (and use) { } and I thought that was the proper coding
>>> style.
>>>
>>> I’m surprised it’s not in our guidelines.
>>>
>>> Jean-Yves
>>> _______
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.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] Initializing member variables
Looks like the majority opinion is to use { ~ }?
- R. Niwa
> On Sep 23, 2024, at 9:35 AM, Geoff Garen via webkit-dev
> wrote:
>
> +1 for { } because I like catching bugs.
>
> But also: If Chris is right that { } is the only way to handle types without
> constructors, and the goal is to pick one syntax, then { } is the only
> possible solution, because standardizing on = would require exceptions for
> types without constructors.
>
> Thanks,
> Geoff
>
>> On Sep 20, 2024, at 2:29 PM, Yusuke Suzuki via webkit-dev
>> wrote:
>>
>> I prefer { } style.
>> It can catch implicit narrowing bugs, which does not work with = style.
>>
>> Best regards,
>> - Yusuke
>>
>>> On Sep 19, 2024, at 4:13 PM, Jean-Yves Avenard via webkit-dev
>>> wrote:
>>>
>>>
>>>
>>>> On 20 Sep 2024, at 7:55 AM, Ryosuke Niwa via webkit-dev
>>>> wrote:
>>>>
>>>>
>>>> Should we do:
>>>>
>>>> struct Foo {
>>>> int bar = 0;
>>>> }
>>>>
>>>> Or
>>>>
>>>> struct Foo {
>>>> int bar { 0 };
>>>> }
>>>>
>>>> We do both at the moment.
>>>>
>>>> - R. Niwa
>>>
>>> I think `int bar = 0` reads better.
>>>
>>> I only ever see (and use) { } and I thought that was the proper coding
>>> style.
>>>
>>> I’m surprised it’s not in our guidelines.
>>>
>>> Jean-Yves
>>> ___________
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.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] Initializing member variables
+1 for { } because I like catching bugs.
But also: If Chris is right that { } is the only way to handle types without
constructors, and the goal is to pick one syntax, then { } is the only possible
solution, because standardizing on = would require exceptions for types without
constructors.
Thanks,
Geoff
> On Sep 20, 2024, at 2:29 PM, Yusuke Suzuki via webkit-dev
> wrote:
>
> I prefer { } style.
> It can catch implicit narrowing bugs, which does not work with = style.
>
> Best regards,
> - Yusuke
>
>> On Sep 19, 2024, at 4:13 PM, Jean-Yves Avenard via webkit-dev
>> wrote:
>>
>>
>>
>>> On 20 Sep 2024, at 7:55 AM, Ryosuke Niwa via webkit-dev
>>> wrote:
>>>
>>>
>>> Should we do:
>>>
>>> struct Foo {
>>> int bar = 0;
>>> }
>>>
>>> Or
>>>
>>> struct Foo {
>>> int bar { 0 };
>>> }
>>>
>>> We do both at the moment.
>>>
>>> - R. Niwa
>>
>> I think `int bar = 0` reads better.
>>
>> I only ever see (and use) { } and I thought that was the proper coding style.
>>
>> I’m surprised it’s not in our guidelines.
>>
>> Jean-Yves
>> ___________
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> _______
> webkit-dev mailing list
> webkit-dev@lists.webkit.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] Initializing member variables
I prefer { } style.
It can catch implicit narrowing bugs, which does not work with = style.
Best regards,
- Yusuke
> On Sep 19, 2024, at 4:13 PM, Jean-Yves Avenard via webkit-dev
> wrote:
>
>
>
>> On 20 Sep 2024, at 7:55 AM, Ryosuke Niwa via webkit-dev
>> wrote:
>>
>>
>> Should we do:
>>
>> struct Foo {
>> int bar = 0;
>> }
>>
>> Or
>>
>> struct Foo {
>> int bar { 0 };
>> }
>>
>> We do both at the moment.
>>
>> - R. Niwa
>
> I think `int bar = 0` reads better.
>
> I only ever see (and use) { } and I thought that was the proper coding style.
>
> I’m surprised it’s not in our guidelines.
>
> Jean-Yves
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Initializing member variables
> On 20 Sep 2024, at 7:55 AM, Ryosuke Niwa via webkit-dev
> wrote:
>
>
> Should we do:
>
> struct Foo {
> int bar = 0;
> }
>
> Or
>
> struct Foo {
> int bar { 0 };
> }
>
> We do both at the moment.
>
> - R. Niwa
I think `int bar = 0` reads better.
I only ever see (and use) { } and I thought that was the proper coding style.
I’m surprised it’s not in our guidelines.
Jean-Yves___________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Initializing member variables
+1 for { }.
— Timothy Hatcher
> On Sep 19, 2024, at 2:55 PM, Ryosuke Niwa via webkit-dev
> wrote:
>
>
> Should we do:
>
> struct Foo {
> int bar = 0;
> }
>
> Or
>
> struct Foo {
> int bar { 0 };
> }
>
> We do both at the moment.
>
> - R. Niwa
>
> _______
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
smime.p7s
Description: S/MIME cryptographic signature
_______
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Initializing member variables
No strong feelings but I have a slight preference for `{ }` initialization
since it disallows narrowing conversions and works with types that do not have
a declared constructor.
So if we have to align in one direction, it would be my preference.
Chris.
> On Sep 19, 2024, at 2:55 PM, Ryosuke Niwa via webkit-dev
> wrote:
>
>
> Should we do:
>
> struct Foo {
> int bar = 0;
> }
>
> Or
>
> struct Foo {
> int bar { 0 };
> }
>
> We do both at the moment.
>
> - 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] Initializing member variables
Should we do:
struct Foo {
int bar = 0;
}
Or
struct Foo {
int bar { 0 };
}
We do both at the moment.
- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Naming singletons
Happens to match our coding style already: https://webkit.org/code-style-guidelines/#singleton-static-member > On Sep 13, 2024, at 2:41 PM, Ryosuke Niwa via webkit-dev > wrote: > > Hi all, > > TL; DR: Add “Singleton” suffix to a function which returns a singleton to > help aid WebKit static analyzers. > > It’s fairly common for some classes to provide a static member function which > returns a singleton. Such a function typically holds NeverDestroyed instance > of an object and it’s safe to call any mutating member functions on it > without locally storing Ref/RefPtr/CheckedRef/CheckedPtr. > > Unfortunately, this poses a challenge for WebKit static analyzers which > enforces safe smart pointer usage because the static analyzers can’t > differentiate a static function which returns a singleton and a static > function which returns a non-singleton instance of an object. For this > reason, I suggest we start suffixing the name of each function which returns > a singleton with “Singleton” e.g. IOSurfacePool::sharedPoolSingleton instead > of IOSurfacePool::sharedPool. This will help aid static analyzers to identify > a function which returns a singleton and not generate superfluous warnings > for it. > > - 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] Naming singletons
Hi all, TL; DR: Add “Singleton” suffix to a function which returns a singleton to help aid WebKit static analyzers. It’s fairly common for some classes to provide a static member function which returns a singleton. Such a function typically holds NeverDestroyed instance of an object and it’s safe to call any mutating member functions on it without locally storing Ref/RefPtr/CheckedRef/CheckedPtr. Unfortunately, this poses a challenge for WebKit static analyzers which enforces safe smart pointer usage because the static analyzers can’t differentiate a static function which returns a singleton and a static function which returns a non-singleton instance of an object. For this reason, I suggest we start suffixing the name of each function which returns a singleton with “Singleton” e.g. IOSurfacePool::sharedPoolSingleton instead of IOSurfacePool::sharedPool. This will help aid static analyzers to identify a function which returns a singleton and not generate superfluous warnings for it. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Obtaining backtraces
On Sat, Sep 7 2024 at 03:59:30 PM -04:00:00, Michael Orlitzky via webkit-dev wrote: On the https://webkitgtk.org/ homepage, the links to these mailing list still use plain http, but the server responds only to https. As of today, the server is redirecting. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Obtaining backtraces
В Sat, 07 Sep 2024 15:49:09 -0400 Michael Orlitzky via webkit-dev пишет: > On Sat, 2024-09-07 at 07:39 -0500, Michael Catanzaro wrote: > > > > You've simply got no sandbox. You'll be fine unless the website > > you're debugging is malicious. > > > > I tested it today and it does work for obtaining core dumps in the > absence of systemd. Problem solved, thank you. > > A final note: I actually have three processes crashing in a row, and > in that case it's necessary to e.g. sysctl > "kernel.core_pattern=core.%P" to get them all. I suggest you also include %e (or even %E if you have several installations of same program in different places) into core_pattern to see easily which executable crashed. _______ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Obtaining backtraces
A final final note: On the https://webkitgtk.org/ homepage, the links to these mailing list still use plain http, but the server responds only to https. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Obtaining backtraces
On Sat, 2024-09-07 at 07:39 -0500, Michael Catanzaro wrote: > > You've simply got no sandbox. You'll be fine unless the website you're > debugging is malicious. > I tested it today and it does work for obtaining core dumps in the absence of systemd. Problem solved, thank you. A final note: I actually have three processes crashing in a row, and in that case it's necessary to e.g. sysctl "kernel.core_pattern=core.%P" to get them all. ___________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Obtaining backtraces
On Fri, Sep 6 2024 at 08:20:07 PM -04:00:00, Michael Orlitzky via webkit-dev wrote: Is it dangerous in some new and exciting way, or is it simply that the sandbox is not in effect? If it's the latter, capturing the dump as a new unprivileged user would make it "safe" once again (so long as your filesystem permissions aren't messed up). You've simply got no sandbox. You'll be fine unless the website you're debugging is malicious. _______________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Obtaining backtraces
On Fri, 2024-09-06 at 17:28 -0500, Michael Catanzaro wrote: > Hey, sorry you had a bad time. Unfortunately everything on > https://trac.webkit.org is obsolete. All documentation is on > https://docs.webkit.org/ nowadays. But we don't yet have any warning > banner to tell you of this. I have created an issue report: > https://github.com/WebKit/Documentation/issues/99 > > Anyway, that documentation has not actually been migrated to the new > docs website, so there is no newer documentation to point you to. :( > I figured. It's OK, that's why I brought it up. > > * Core dumps don't happen any more because of bubblewrap > > Hm, I guess the "without systemd" instructions from that wiki page will > not work anymore, since the core dump is probably created inside the > sandbox now instead of on your host system? I had never considered this. Right. I was pretty close to editing bubblewrap.c and doing a sudo mv bwrap /usr/bin. > I strongly recommend using systemd-coredump. Manual handling of core > dumps is primitive and, as you've discovered, a waste of your time. I > wrote a blog post on how to enable this if you haven't already: I too am primitive. None of these systems have systemd :) > Use the environment variable > WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1. (But certainly don't use > this just to take a backtrace!) I left the problem machine at the office overnight, but this sounds like exactly what I needed. I'm familiar enough with getting core dumps the old-fashioned way outside of bwrap. Is it dangerous in some new and exciting way, or is it simply that the sandbox is not in effect? If it's the latter, capturing the dump as a new unprivileged user would make it "safe" once again (so long as your filesystem permissions aren't messed up). _______ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Obtaining backtraces
Hey, sorry you had a bad time. Unfortunately everything on https://trac.webkit.org is obsolete. All documentation is on https://docs.webkit.org/ nowadays. But we don't yet have any warning banner to tell you of this. I have created an issue report: https://github.com/WebKit/Documentation/issues/99 Anyway, that documentation has not actually been migrated to the new docs website, so there is no newer documentation to point you to. :( * Core dumps don't happen any more because of bubblewrap Hm, I guess the "without systemd" instructions from that wiki page will not work anymore, since the core dump is probably created inside the sandbox now instead of on your host system? I had never considered this. I strongly recommend using systemd-coredump. Manual handling of core dumps is primitive and, as you've discovered, a waste of your time. I wrote a blog post on how to enable this if you haven't already: https://blogs.gnome.org/mcatanzaro/2021/09/18/creating-quality-backtraces-for-crash-reports/ There is just one trick with WebKit: you have to raise the core size limit to prevent systemd from discarding the core dump. Both the trac wiki page and my blog post contain instructions for how to do this. We really ought to document that somewhere on https://docs.webkit.org. * WEBKIT2_PAUSE_WEB_PROCESS_ON_LAUNCH quietly does nothing unless you happen to have built with DEVELOPER_MODE (won't be the case on a linux distro) I agree that limiting this to developer mode only makes debugging unnecessarily difficult. We should probably change that; I can't think of any good reason for limiting it. (But don't use this just to take a backtrace, since it's too much effort and a waste of your time.) One idea: how hard would it be to skip bubblewrap in a release build if some environment variable is set? Use the environment variable WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1. (But certainly don't use this just to take a backtrace!) Michael ___________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Obtaining backtraces
I spent the entire day today figuring out how to get a backtrace from the installed copy of webkit-gtk. But I don't _just_ want to complain. I'd like to figure out a way to do this easily, and to update the documentation. The existing docs, https://trac.webkit.org/wiki/WebKitGTK/Debugging are pretty misleading: * Core dumps don't happen any more because of bubblewrap * WEBKIT2_PAUSE_WEB_PROCESS_ON_LAUNCH quietly does nothing unless you happen to have built with DEVELOPER_MODE (won't be the case on a linux distro) * The minibrowser isn't going to be available on a distro, and if you aren't using the minibrowser, gdb won't follow the right children... * And you can't reliably guess the right PID of a running process quick enough to attach to it in e.g. epiphany. Rebuilding from a git checkout and hacking on the webkit source to enable DEVELOPER_MODE or the minibrowser is not always feasible. (Or desirable -- I want to debug the code that is actually crashing, and not spend three days guessing!) I've been dealing with crashes on my laptop for years because it has very little RAM -- it simply doesn't have the resources to build a development copy of webkit-gtk. Even now, on a system with 64 low-power cores, it still takes more than a day, and that's after spending half the day figuring out how to configure the build exactly like the distro does, so that you can reproduce the crash. So for starters: is there something I missed? Some easy way to get a traceback from a modern, system copy of webkit-gtk? One idea: how hard would it be to skip bubblewrap in a release build if some environment variable is set? ___________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] 2024 WebKit Contributors Meeting - Registration is Open!
It is in fact Wednesday, October 23rd that follows Tuesday, October 22nd: ## Tentative Schedule ## *Tuesday, October 22nd* 9 AM Pacific to midday — Birds of a feather (self-organized, in-person) LUNCH Midday – 5pm Pacific — Formal presentations (in-person and online) *Thursday, October 23rd* 9 AM Pacific to midday — Formal presentations (in-person and online) LUNCH Midday – 5pm Pacific — Birds of a feather (in-person) --- Jon Davis, on behalf of the WebKit Contributors Meeting Organizers > On Sep 3, 2024, at 5:20 PM, Jonathan Davis wrote: > > Correction: the tentative schedule should be: > > ## Tentative Schedule ## > > *Tuesday, October 22nd* > 9 AM Pacific to midday — Birds of a feather (self-organized, in-person) > LUNCH > Midday – 5pm Pacific — Formal presentations (in-person and online) > > *Thursday, October 23rd* > 9 AM Pacific to midday — Formal presentations (in-person and online) > LUNCH > Midday – 5pm Pacific — Birds of a feather (in-person) > > Apologies for any confusion. You can always find the latest up-to-date > details on the WebKit Contributors Meeting page: > https://www.webkit.org/meeting/ > > --- > Jon Davis, on behalf of the WebKit Contributors Meeting Organizers 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] 2024 WebKit Contributors Meeting - Registration is Open!
Correction: the tentative schedule should be: ## Tentative Schedule ## *Tuesday, October 22nd* 9 AM Pacific to midday — Birds of a feather (self-organized, in-person) LUNCH Midday – 5pm Pacific — Formal presentations (in-person and online) *Thursday, October 23rd* 9 AM Pacific to midday — Formal presentations (in-person and online) LUNCH Midday – 5pm Pacific — Birds of a feather (in-person) Apologies for any confusion. You can always find the latest up-to-date details on the WebKit Contributors Meeting page: https://www.webkit.org/meeting/ --- Jon Davis, on behalf of the WebKit Contributors Meeting Organizers smime.p7s Description: S/MIME cryptographic signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] 2024 WebKit Contributors Meeting - Registration is Open!
Hello WebKit Contributors, You are invited to participate in the 2024 WebKit Contributors Meeting at the Hyatt House San Jose/Cupertino or online via WebEx on Tuesday, October 22nd and Wednesday, October 23rd. ## Registration ## To attend, you must be an active contributor to the WebKit open-source project. The meeting will be free of charge and registration is now open! Registration is required whether you are attending in-person or virtually. You can find more details about the event and register at the WebKit Contributors Meeting page: https://webkit.org/meeting/ ## Format ## As in past years, the event will feature presentation-led discussions of 10-40 minutes long, followed by Q&A discussions and significant breaks for discussions. There will also be a lightning talk segment if you have a topic to present that is 10 minutes or less. Please reach out to Jon Davis via email or WebKit Slack to reserve a spot for your presentation. ## Tentative Schedule ## *Tuesday, October 22nd* 9 AM Pacific to midday — Birds of a feather (self-organized, in-person) LUNCH Midday – 5pm Pacific — Formal presentations (in-person and online) *Thursday, October 17th* 9 AM Pacific to midday — Formal presentations (in-person and online) LUNCH Midday – 5pm Pacific — Birds of a feather (in-person) This schedule will be finalized to accommodate the presentations pitched. ## Health & Safety ## For the safety of everyone attending the meeting, in-person attendees will be required to wear a mask indoors except while actively 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. Feel free to submit ideas or questions about this year’s online event in the #contributors-meeting channel on WebKit Slack. We’re looking forward to seeing you there! --- Jon Davis, on behalf of the WebKit Contributors Meeting Organizers 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] Problems with injecting js-code on first load
On Thu, Aug 29 2024 at 06:41:45 AM +00:00:00, Erik Lundin via webkit-dev wrote: I’m trying to inject javascript code on each page load but it fails on the first load every time. If I reload the page it works. How do I fix this? Is there something I’ve missed in the code below? You're injecting the script after the load has already finished, so it's too late. Try injecting it when creating the web view instead. _______ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Problems with injecting js-code on first load
on_run (G_APPLICATION (app),
argc, argv);
g_object_unref (app);
return status;
}
Regards, Erik
_______
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] macOS Intel WK2 Tests on EWS
Hi all, macOS Intel WK2 tests are live on EWS! The mac-intel-wk2 status bubble will appear for any changes uploaded after 1:15pm PT. Earlier this year, we replaced older Intel-based Mac Pro hardware with M1 and M2 Apple Silicon devices. With the exception of the JSC stress test queue, this upgrade meant that we had no Intel coverage for Apple platforms on EWS even though it remains a supported configuration post-commit. We have now added a mac-intel-wk2 queue that will run release WK2 layout tests on Ventura. Cheers, Brianna F ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Runtime guarding IPC receivers / messages by [EnabledBy=X] in messages.in
Hi all, I’ve recently added a mechanism to filter IPC messages based on which features are enabled at runtime. By adding `[EnabledBy=X]` either to a whole message receiver or on an individual IPC message, we can enable IPC messages only when feature X is enabled at runtime. Note that to use this feature, a new entry `sharedPreferenceForWebProcess: true` needs to be added to UnifiedWebPreferences.yaml. Why do we want to do that you may ask? It’s to protect UI, Network, and GPU processes from a compromised WebContent process. By restricting IPC messages/receivers at runtime, we dramatically reduce the attack surface available to the malicious code in WebContent process. So if you’re adding a new IPC message receiver or a new IPC message, please runtime guard each IPC receiver / message with `[EnabledBy=X]` when possible. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Deprecate webkit_web_page_get_main_frame?
El mar, 23-07-2024 a las 12:51 -0600, Alex Christensen escribió: > We definitely have a lot of work to do, but the plan is to make UI > process driven replacements for all uses of the injected bundle. > It’s a large problem without a currently completely known solution, > but we’re working on it and welcome collaboration from people working > on webkit-based browsers on other platforms. I’m pushing to > deprecate things to discourage further adoption of things we are > planning to remove, even before we have a complete replacement plan. > Ok, sounds good to me. We are of course happy to collaborate on this, so count on us for whatever we can do to help. > > On Jul 22, 2024, at 4:31 AM, Carlos Garcia Campos via webkit-dev > > wrote: > > > > Hi Alex, > > > > sorry for the delay to reply, I was on vacation last week. > > > > So, we mainly use the frame object to get its javascript context, > > so > > what's the plan for that? I mean, it's only the api to get the main > > frame what's going to be deprecated or the frame object entirely? > > In > > most of the cases we get the frame from the script world on the > > window- > > object-cleared event, so we can probably deprecate > > get_main_frame(). I > > think it's only used in epiphany and evolution, but I would need to > > check how it's used there. > > > > El vie, 12-07-2024 a las 16:19 -0600, Alex Christensen via webkit- > > dev > > escribió: > > > In https://github.com/WebKit/WebKit/pull/30763 I’m deprecating > > > injected bundle frame access interfaces as part of the site > > > isolation > > > development. Would glib API maintainers be willing to deprecate > > > webkit_web_page_get_main_frame to discourage its adoption and > > > indicate plans to remove it at some point in the future? I’ve > > > kept > > > the functionality for now because we are still moving off it, but > > > at > > > some point that will be complete and it would be nice to remove > > > bundle frame access together. > > > _______ > > > webkit-dev mailing list > > > webkit-dev@lists.webkit.org > > > https://lists.webkit.org/mailman/listinfo/webkit-dev > > > > -- > > Carlos Garcia Campos > > _______ > > webkit-dev mailing list > > webkit-dev@lists.webkit.org > > https://lists.webkit.org/mailman/listinfo/webkit-dev > > -- 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] Deprecate webkit_web_page_get_main_frame?
On Tue, Jul 23 2024 at 12:51:36 PM -06:00:00, Alex Christensen via webkit-dev wrote: We definitely have a lot of work to do Yes, this seems tough. I wonder if we could introduce something like WebKitWebPageProxy and WebKitFrameProxy to replace WebKitWebPage and WebKitFrame ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Deprecate webkit_web_page_get_main_frame?
We definitely have a lot of work to do, but the plan is to make UI process driven replacements for all uses of the injected bundle. It’s a large problem without a currently completely known solution, but we’re working on it and welcome collaboration from people working on webkit-based browsers on other platforms. I’m pushing to deprecate things to discourage further adoption of things we are planning to remove, even before we have a complete replacement plan. > On Jul 22, 2024, at 4:31 AM, Carlos Garcia Campos via webkit-dev > wrote: > > Hi Alex, > > sorry for the delay to reply, I was on vacation last week. > > So, we mainly use the frame object to get its javascript context, so > what's the plan for that? I mean, it's only the api to get the main > frame what's going to be deprecated or the frame object entirely? In > most of the cases we get the frame from the script world on the window- > object-cleared event, so we can probably deprecate get_main_frame(). I > think it's only used in epiphany and evolution, but I would need to > check how it's used there. > > El vie, 12-07-2024 a las 16:19 -0600, Alex Christensen via webkit-dev > escribió: >> In https://github.com/WebKit/WebKit/pull/30763 I’m deprecating >> injected bundle frame access interfaces as part of the site isolation >> development. Would glib API maintainers be willing to deprecate >> webkit_web_page_get_main_frame to discourage its adoption and >> indicate plans to remove it at some point in the future? I’ve kept >> the functionality for now because we are still moving off it, but at >> some point that will be complete and it would be nice to remove >> bundle frame access together. >> _______ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> https://lists.webkit.org/mailman/listinfo/webkit-dev > > -- > Carlos Garcia Campos > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Deprecate webkit_web_page_get_main_frame?
Hi Alex, sorry for the delay to reply, I was on vacation last week. So, we mainly use the frame object to get its javascript context, so what's the plan for that? I mean, it's only the api to get the main frame what's going to be deprecated or the frame object entirely? In most of the cases we get the frame from the script world on the window- object-cleared event, so we can probably deprecate get_main_frame(). I think it's only used in epiphany and evolution, but I would need to check how it's used there. El vie, 12-07-2024 a las 16:19 -0600, Alex Christensen via webkit-dev escribió: > In https://github.com/WebKit/WebKit/pull/30763 I’m deprecating > injected bundle frame access interfaces as part of the site isolation > development. Would glib API maintainers be willing to deprecate > webkit_web_page_get_main_frame to discourage its adoption and > indicate plans to remove it at some point in the future? I’ve kept > the functionality for now because we are still moving off it, but at > some point that will be complete and it would be nice to remove > bundle frame access together. > ___________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev -- Carlos Garcia Campos 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
[webkit-dev] Deprecate webkit_web_page_get_main_frame?
In https://github.com/WebKit/WebKit/pull/30763 I’m deprecating injected bundle frame access interfaces as part of the site isolation development. Would glib API maintainers be willing to deprecate webkit_web_page_get_main_frame to discourage its adoption and indicate plans to remove it at some point in the future? I’ve kept the functionality for now because we are still moving off it, but at some point that will be complete and it would be nice to remove bundle frame access together.___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] merge-queue / commit-queue downtime starting Friday July 5, 2024 @ 7:00 PM PDT
Due to underlying infrastructure maintenance, merge-queue / commit-queue will be taken offline between Friday July 5, 2024 @ 7:00 PM through Saturday July 6, 2024 @ 12:00 PM PDT. EWS will remain operational during this time, and anything labeled for merge-queue will be processed as soon as the service comes back online. Thank you, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] DO NOT USE JSC::Strong in WebCore
Please don’t use `JSC::Strong` in WebCore. Such a code often leads to memory leaks, and it’s almost always wrong. Often times, the correct solution is to use `JSC::Weak` and either visit children or opaque roots to keep it alive: https://docs.webkit.org/Deep%20Dive/Architecture/JSWrappers.html#opaque-roots If you’re not sure or don’t know how to use them correctly, come talk to me or anyone else familiar with JS DOM bindings. Reviewers, please don’t r+ a patch which uses JSC::Strong unless you’re absolutely confident that it does not lead to a memory leak. The vast majority of PRs that use JSC::Strong should be outright r-'ed. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Code Style Guideline entry about a space in empty braces
Thanks Michael and Abrar.
Yeah I agree with what Abrar said. For clang-format, which has specific WebKit
style, needs to care about the coding style so updating benefits for
maintaining it.
I’ll appreciate other comments about this on
PR<https://github.com/WebKit/WebKit/pull/29668>. If there are no other
opinions, could anyone merge this PR? Thanks!
Kohei
差出人: Abrar Protyasha
送信日時: 2024年6月15日 0:00
宛先: Asano, Kohei (SIE)
CC: webkit-dev@lists.webkit.org
件名: Re: [webkit-dev] Code Style Guideline entry about a space in empty braces
There is one section in the style guide about spacing around brace
initialization<https://webkit.org/code-style-guidelines/#spacing-braced-init:~:text=href="#-,spacing-braced-init,-";
name=>, which is a little informative and certainly applies for one class of
empty braces. check-webkit-style helps satisfy said rule, but I think it’s
overzealous in its identification of missing spaces inside an empty brace since
the style guide doesn’t prescribe anything about this in general.
Having said that, I think we should converge to unconditionally placing spaces
inside empty braces, for which we would want to update the coding style guide.
Conveniently, check-webkit-style has already been checking for that, so we must
not have committed too many violations! (some grepping indicates 30141
instances of { } vs 626 instances of {} under Source/)
On Jun 14, 2024, at 00:37, Kohei.Asano--- via webkit-dev
wrote:
Hi. I'm now working on clang-format refinement for WebKit style. Although
pre-set for WebKit is unused on WebKit/WebKit itself as we
seehttps://github.com/WebKit/WebKit/blob/e91b9416d35d02968ccb1554d14e94568c762be5/.clang-format#L2<https://github.com/WebKit/WebKit/blob/e91b9416d35d02968ccb1554d14e94568c762be5/.clang-format#L2>,
I'll add missing features of clang-format itself to make consistent with
WebKit code style.
A maintainer catches that we should take care about WebKit Code Style
Guideline, in the patch that adds a missed
featurehttps://github.com/llvm/llvm-project/pull/93634#discussion_r1632439352<https://github.com/llvm/llvm-project/pull/93634#discussion_r1632439352>.
So I wouldn't update WebKit pre-set on clang-format.
I found Code Style Guideline misses an entry about empty braces, while
check-webkit-style catches. I also created bugzilla
tickethttps://bugs.webkit.org/show_bug.cgi?id=275309<https://bugs.webkit.org/show_bug.cgi?id=275309>
and candidate doc update patch
https://github.com/WebKit/WebKit/pull/29668<https://github.com/WebKit/WebKit/pull/29668>
Which is better to update Code Style Guideline or check-webkit-style?
Thanks in advance.
Kohei
___________
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] Code Style Guideline entry about a space in empty braces
There is one section in the style guide about spacing around brace
initialization
<https://webkit.org/code-style-guidelines/#spacing-braced-init:~:text=href=%22%23-,spacing-braced-init,-%22%20name=>,
which is a little informative and certainly applies for one class of empty
braces. check-webkit-style helps satisfy said rule, but I think it’s
overzealous in its identification of missing spaces inside an empty brace since
the style guide doesn’t prescribe anything about this in general.
Having said that, I think we should converge to unconditionally placing spaces
inside empty braces, for which we would want to update the coding style guide.
Conveniently, check-webkit-style has already been checking for that, so we must
not have committed too many violations! (some grepping indicates 30141
instances of { } vs 626 instances of {} under Source/)
> On Jun 14, 2024, at 00:37, Kohei.Asano--- via webkit-dev
> wrote:
>
> Hi. I'm now working on clang-format refinement for WebKit style. Although
> pre-set for WebKit is unused on WebKit/WebKit itself as we
> seehttps://github.com/WebKit/WebKit/blob/e91b9416d35d02968ccb1554d14e94568c762be5/.clang-format#L2,
> I'll add missing features of clang-format itself to make consistent with
> WebKit code style.
>
> A maintainer catches that we should take care about WebKit Code Style
> Guideline, in the patch that adds a missed
> featurehttps://github.com/llvm/llvm-project/pull/93634#discussion_r1632439352.
> So I wouldn't update WebKit pre-set on clang-format.
>
> I found Code Style Guideline misses an entry about empty braces, while
> check-webkit-style catches. I also created bugzilla
> tickethttps://bugs.webkit.org/show_bug.cgi?id=275309 and candidate doc update
> patch https://github.com/WebKit/WebKit/pull/29668
>
> Which is better to update Code Style Guideline or check-webkit-style?
>
> Thanks in advance.
>
> Kohei
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Code Style Guideline entry about a space in empty braces
On Fri, Jun 14 2024 at 07:37:36 AM +00:00:00, Kohei.Asano--- via webkit-dev wrote: I found Code Style Guideline misses an entry about empty braces, while check-webkit-style catches. I also created bugzilla ticket https://bugs.webkit.org/show_bug.cgi?id=275309 and candidate doc update patch https://github.com/WebKit/WebKit/pull/29668 Which is better to update Code Style Guideline or check-webkit-style? Hi, The style guidelines should be updated; thanks for handling that. We already consistently follow this rule, since (as you've noticed) it's enforced by the script. _______ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Code Style Guideline entry about a space in empty braces
Hi. I'm now working on clang-format refinement for WebKit style. Although pre-set for WebKit is unused on WebKit/WebKit itself as we see https://github.com/WebKit/WebKit/blob/e91b9416d35d02968ccb1554d14e94568c762be5/.clang-format#L2, I'll add missing features of clang-format itself to make consistent with WebKit code style. A maintainer catches that we should take care about WebKit Code Style Guideline, in the patch that adds a missed feature https://github.com/llvm/llvm-project/pull/93634#discussion_r1632439352. So I wouldn't update WebKit pre-set on clang-format. I found Code Style Guideline misses an entry about empty braces, while check-webkit-style catches. I also created bugzilla ticket https://bugs.webkit.org/show_bug.cgi?id=275309 and candidate doc update patch https://github.com/WebKit/WebKit/pull/29668 Which is better to update Code Style Guideline or check-webkit-style? Thanks in advance. Kohei _______ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] PSA: some WebKit project “pulse” activity metrics
Some links with data and charts showing project commit/PR activity metrics: - https://flagged.apple.com:443/proxy?t2=Dj5H9Z5Kj7&o=aHR0cHM6Ly9naXQtcHVsc2UuZ2l0aHViLmlvL3NuYXBzaG90cy8/cHJvamVjdD1XZWJLaXRfV2ViS2l0&emid=68194e83-fac4-4a41-8a1a-dcc8889dabe5&c=11 - https://flagged.apple.com:443/proxy?t2=Dn8r7N4Mi7&o=aHR0cHM6Ly9naXQtcHVsc2UuZ2l0aHViLmlvL3NuYXBzaG90cy9XZWJLaXQtV2ViS2l0LTIwMjQtMDUtMjYtcHVsc2UuaHRtbA==&emid=68194e83-fac4-4a41-8a1a-dcc8889dabe5&c=11 From those, some “good” metrics for the project that particularly stand out: - 1123 PRs merged per month (3rd highest) - 1224 commits per month (6th highest) - 130 unique committers per month (9th highest) - 9.42 commits per committer (on average) per month (9th highest) Those are averages over the last 12 months. And the rankings are relative to the 78 other extremely-high-activity projects tracked by this tool. The only two projects that have more PRs merged per month are the Homebrew project repos — but their PR numbers are so ridiculously higher than all other projects that they’re essentially in a class by themselves. https://flagged.apple.com:443/proxy?t2=Dn8r7N4Mi7&o=aHR0cHM6Ly9naXQtcHVsc2UuZ2l0aHViLmlvL3NuYXBzaG90cy9XZWJLaXQtV2ViS2l0LTIwMjQtMDUtMjYtcHVsc2UuaHRtbA==&emid=68194e83-fac4-4a41-8a1a-dcc8889dabe5&c=11 is a report that has the specific per-month numbers (rather than just averages) for the project — along with some charts of the data. --- Caveat: I created the tool used for generating all this stuff, and you can find the source at https://github.com/git-pulse/tools — and if you want to, you can run it yourself locally in your WebKit repo, like this: curl -fsSLO https://flagged.apple.com:443/proxy?t2=Dr0E2z4Bg4&o=aHR0cHM6Ly9naXQtcHVsc2UuZ2l0aHViLmlvL3Rvb2xzL2dpdC1wdWxzZQ==&emid=68194e83-fac4-4a41-8a1a-dcc8889dabe5&c=11 && bash ./git-pulse (That generates output to the shell/terminal while it’s running, and then generates HTML output when it’s done. And due to GitHub API throttling, it takes a while — maybe 5 minutes or more — to run to completion.) Caveat: In general the numbers this tool ends up generating seem accurate — but I’m not a statistician and there may be some bugs in calculations I have it using to generate its numbers. --- And finally, some maybe-not-as-good metrics that stand out: - open PRs: 946 (2nd highest) - rate at which number of open PRs is increasing: 33 per month (#1 highest) The only other project with more open PRs is the Web Platform Tests (WPT) project — and statistically speaking, it’s almost the same: 957. And beyond the fact that the rate at which the number of open PRs for the WebKit project is highest among all 78 projects tracked by this tool — it’s also increasing at nearly _twice_ the rate as the project with the next-highest rate of increase (which is “only” 17 per month). Among all the projects tracked, the _average_ rate of increase in open PRs each month is zero — and almost 20 of the other projects actually have a _decrease_ in the number of open PRs per month. The WPT project — which has the highest number of open PRs — actually also has the highest decrease in open PRs per month: It’s closing 15 more PRs per month than are being opened each month — vs the WebKit project gaining 33 new PRs per month (and over the last year, gaining 429 unclosed PRs in total). I’m not stating those numbers as any kind of criticism or sign of anything that necessarily needs fixing — I’m just noting how much those numbers stand out relative to those of some other projects. And again, see the caveat above: I’m not a statistician — and to the degree that any of these numbers actually mean anything at all, I’m anyway personally not qualified to offer any useful analysis on them from any kind of actually-informed point of view. -- https://flagged.apple.com:443/proxy?t2=DU2A5t8QM4&o=aHR0cHM6Ly9zaWRlc2hvd2Jhcmtlci5uZXQ=&emid=68194e83-fac4-4a41-8a1a-dcc8889dabe5&c=11/ _______ webkit-dev mailing list webkit-dev@lists.webkit.org https://flagged.apple.com:443/proxy?t2=Dp8a6v3PP3&o=aHR0cHM6Ly9saXN0cy53ZWJraXQub3JnL21haWxtYW4vbGlzdGluZm8vd2Via2l0LWRldg==&emid=68194e83-fac4-4a41-8a1a
[webkit-dev] Removing webkit-tools-completion.sh
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?
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
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
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
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://searchf
[webkit-dev] RFC: Improving “RefPtr inside destructor” checking
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
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
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
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
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
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
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
+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
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
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 0x00019359b
[webkit-dev] Sam Sneddon is now a WebKit Reviewer
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
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-82682F8AA
Re: [webkit-dev] jsc bus error EXC_BAD_ACCESS with jsc-only build on Mac
+ 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
Re: [webkit-dev] jsc bus error EXC_BAD_ACCESS with jsc-only build on Mac
frame #12: 0x000108eb4ce0 JavaScriptCore`void > std::__1::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: 0x0001987c 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!
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&data=05%7C02%7Cmax.schmitt%40microsoft.com%7C5374fe722fe24095285708dc54a554ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638478316310746385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=KjAC7J55jvRKpS2U9uXdHhZ2zAx5fNTL0TtSMhgWhTc%3D&reserved=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!
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!
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
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
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!
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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!
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<>()
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
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
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
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
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
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
> 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
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
> 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
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
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&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&chfieldfrom=1d&chfieldto=Now&f1=assigned_to&o1=substring&query_format=advanced&v1=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
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
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
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
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
