Re: [webkit-dev] Stop Using Raw Pointers & References in New Code
On Fri, Jan 27 2023 at 10:52:52 AM -0600, Michael Catanzaro wrote: There is probably a relatively high cost compared to WTF::WeakPtr, so I'd say it should be used only when it provides valuable safety (e.g. in member variables) rather than spammed (e.g. in local variables). Another good use for GWeakPtr: callbacks ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Stop Using Raw Pointers & References in New Code
On Tue, Jan 24 2023 at 02:53:42 PM -0600, Michael Catanzaro wrote: E.g. for GObjects, we could write GWeakPtr, but this would not be very ergonomic, and it won't work for arbitrary types. So Carlos Garcia added this in https://commits.webkit.org/259482@main. There is a downside to GWeakPtr: global locking. Even though GWeakPtr is not threadsafe and each GObject keeps its own list of weak locations, all GObjects nonetheless share the same global lock for weak pointer locations. There is probably a relatively high cost compared to WTF::WeakPtr, so I'd say it should be used only when it provides valuable safety (e.g. in member variables) rather than spammed (e.g. in local variables). Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Unsigned to avoid negative values
On Thu, Jan 26 2023 at 12:31:25 AM -0800, Myles Maxfield via webkit-dev wrote: Okay, sounds like we’re all pretty much in agreement. How about I add a rule to our style guide that says “use unsigned types to represent values which cannot be negative.” Good idea? This is pretty strict. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Stop Using Raw Pointers & References in New Code
On Tue, Jan 24 2023 at 11:33:45 AM -0800, Ryosuke Niwa via webkit-dev
wrote:
That’s also the semantics of Ref/RefPtr in WebKit. But we’re
expanding the use of Ref/RefPtr to be beyond just owners for memory
safety. I don’t see how the situation is any different with
GRefPtr/GUniquePtr. If an explicit ownership isn’t appropriate,
then CheckedPtr/CheckedRef should be used instead.
The difference is we can modify WebKit C++ types to inherit from
CanMakeCheckedPtr or CanMakeThreadSafeCheckedPtr, but we cannot modify
types we don't control or types that are not even written in C++, so
the smart pointer would have to do all the work of tracking ownership
itself. std::shared_ptr and std::weak_ptr can do this for types that
don't implement their own refcounting already. For types that *do* have
their own refcounting, then I guess it's only doable if the type
supports weak pointers. E.g. for GObjects, we could write GWeakPtr, but
this would not be very ergonomic, and it won't work for arbitrary types.
Thinking about this more, I'm not sure this plan works for WeakPtrs?
Say we have:
WeakPtr f = /* initialized somehow */;
if (Foo* f = f.get())
{
// do something
}
Then we already broke the rule against using a raw pointer in a local
variable. That's the only way to use a WeakPtr, so we kind of have to,
but as long as you have it stored in a raw pointer, then we gain no
additional safety from the WeakPtr. CheckedPtr would work better in
local variables, but again that's not an option for types we don't
control.
Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Unsigned to avoid negative values
On Tue, Jan 24 2023 at 02:00:11 AM -0800, Myles Maxfield via webkit-dev wrote: What do you think? This has been a best practice for a long time now. It's a good rule to reduce bugs if adopted consistently, but I also fear that if we were to try to adapt existing WebKit code to follow these guidelines, we might accidentally introduce a lot of new bugs, especially regarding container types like Vector. So I don't know what to think! ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Stop Using Raw Pointers & References in New Code
Hm, I see you're right because CheckedRef/CheckedPtr are intrusive pointers that require modification of the type to be pointed to, so they are not going to work in general as they cannot be used for types that do not inherit from CanMakeCheckedRef/CanMakeCheckedPtr. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Stop Using Raw Pointers & References in New Code
On Fri, Jan 20 2023 at 06:15:38 PM -0800, Ryosuke Niwa via webkit-dev wrote: Here’s a PR to make the style checker look for raw pointers & references in data members: https://github.com/WebKit/WebKit/pull/8907 I suggest we land this PR in 5 business days from now on unless someone objects. I'm not sure how this would work as a style check rule since there's always going to be exceptions. E.g. we probably don't want to convert GObject priv pointers to use CheckedRef: that would be silly. I think we can follow this rule in most of WebCore and maybe most of WebKit and WTF as well. Probably not going to work for bmalloc. Not sure about JSC. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Compile times and class-scoped enums
On Fri, Jan 20 2023 at 09:50:05 AM -0800, Jer Noble via webkit-dev wrote: However, this requires a significant coding style change, both to existing code and new code, and as such, it should probably be discussed here. So, what do people think? Is the change in coding style (moving class-scoped enums out into namespace scope) worth doing if it means a significant increases in compile speeds? My $0.02: it's awful but worth it. That's a ridiculous speedup. Nice. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Stop Using Raw Pointers & References in New Code
On Thu, Jan 12 2023 at 12:35:09 PM -0800, Ryosuke Niwa via webkit-dev
wrote:
So… instead of:
foo(bar());
do:
foo(RefPtr { bar() }.get());
What's the value of creating a temporary RefPtr just to get at the
underlying raw pointer? Isn't this overkill?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New status field required for feature flags
On Mon, Jan 9 2023 at 02:11:37 PM -0800, Elliott Williams via webkit-dev wrote: - allow each port to decide whether a feature is on or off by default (regardless of its status) Different default values for different ports is unavoidable; there are many many other examples besides PDF.js where ports just need to be different. But I think it's OK for the status field to be the same on all platforms. Just set the status value to whatever works best for Apple. The status field could control the *default* default value, which you can feature on https://webkit.org/status/, but ports should still be able to override it if needed. Sound good? By the way, while this seems like a good cleanup to me, I see there are really a *lot* of statuses defined. I don't think I'd be able to understand which one is correct to use for a feature unless I have that table explaining what each one does in front of me. I wonder if they're all truly required. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Update commit log template to make GNU changelog optional
Hi, I'd like to remove the GNU changelog from the bottom of the commit messages by default. With "by default" I mean people who prefer to use the GNU changelog for formatting their commit messages would have to change git-webkit configuration to keep using it, and it would go away for everyone else's commit messages. I don't see any reason to prohibit the changelogs if really desired, but these were designed for an era before version control existed, to explain what is being changed rather than why. The freeform commit message that we add above the changelogs is usually a better way to explain commits. (Another disadvantage is it is really easy for the changelog to become stale by mistake. When amending commits, you have to look closely at the bottom of the commit message template prepared by git-webkit to notice the updated changelog, then manually replace the original commit message's changelog. I'm sure we commit inaccurate changelogs all the time because we forget to do this.) Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Update commit log template to add placeholder for explanation of why a patch fixes a bug
On Thu, Nov 17 2022 at 02:48:04 PM -0800, Ryosuke Niwa wrote: But every change in WebKit comes with a Bugzilla bug. Certainly most do, but some counterexamples: * Unreviewed build fixes sometimes do not reference a bug * When fixing a new compiler warning or build failure, I often reference the bug that introduced the problem, rather than reporting a new one just to have a new hyperlink for the commit message * We probably don't need a bug report for stuff like "update my email address in contributors.json" or "fix typo in comment" Anyway, it doesn't matter terribly much what wording we use. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Update commit log template to add placeholder for explanation of why a patch fixes a bug
On Thu, Nov 17 2022 at 02:41:35 PM -0800, Ryosuke Niwa wrote: We don’t want a description of what PR is; that’s obvious from diff. We want a description of why that PR fixes the bug. Problem is, that is not very useful when the change is anything other than a change that fixes a bug. :) ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Update commit log template to add placeholder for explanation of why a patch fixes a bug
On Thu, Nov 17 2022 at 12:23:54 PM -0800, David Kilzer via webkit-dev wrote: Any feedback on this change? We could alternatively say "Explanation of this change (OOPS!)" or "Explanation of this commit (OOPS!)" to be a little more general. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] GPU Process on all platforms eventually?
This sounds like a desirable goal. Having fewer configurations to test is good. (I'm not sure how close the various WebKit ports are to getting GPU process working, though.) Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] CMake EWS now use -Werror
Hi developers, The Apple EWS bots have long used -Werror to make warnings fatal, discouraging inadvertently introducing new build warnings. But CMake EWS bots did not, until now. The new CMake behavior after https://commits.webkit.org/255961@main is: * By default, warnings are not fatal. * Warnings become fatal if you use the -DDEVELOPER_MODE=ON CMake flag. The build-webkit script always enables this. * An off switch exists, -DDEVELOPER_MODE_FATAL_WARNINGS=OFF, with a corresponding --no-fatal-warnings flag for build-webkit. Use this whenever you're bisecting, or when you're in a hurry and don't have time to deal with particular warnings. * All post-commit bots now build with --no-fatal-warnings to avoid losing test results to a compiler warning. The EWS does not, to discourage introduction of new warnings. Some common warnings to avoid: * -Wreturn-type is by far the most common GCC warning introduced into WebKit. This occurs when you expect a switch statement to always return, but forget to ensure that it really does when passed an invalid enum value. Clang does not complain about these, so only the bots using GCC will notice it. The normal solution is to add RELEASE_ASSERT_NOT_REACHED() to the bottom of the function. In especially hot functions, that might have performance impact, and you might need to write the code in an alternative way or use IGNORE_RETURN_TYPE_WARNINGS_BEGIN/END from Compiler.h. (I've considered disabling this warning due to how frequently we introduce code that trips it, but have left it because returning bogus data is very bad.) * -Wunused-parameter and -Wunused-variable warnings often occur around ENABLE() or USE() build guards. Use UNUSED_PARAM() and UNUSED_VARIABLE(), respectively, to suppress these. Note that Source/WebKit builds with -Wno-unused-parameter, but most of the rest of WebKit does not. * -Wredundant-move occurs when you write "return WTFMove(foo)" and the solution is to remove the WTFMove(). Clang only warns when the move blocks return value optimization, but GCC warns always. Of course there are plenty more warnings you might encounter, but those are the most common ones. If you find something you don't know how to deal with, don't hesitate to ask for help. False positives can be suppressed using IGNORE_WARNINGS_BEGIN() and IGNORE_WARNINGS_END() or one of the similar macros from Compiler.h. I believe the --no-fatal-warnings flag is not currently hooked up to anything on Apple ports. This would be good to improve. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Remove the version labels in GitHub
On Sat, Oct 22 2022 at 07:31:06 AM -0700, Darin Adler via webkit-dev wrote: Can we just get rid of all this? That would be nice. These labels are not useful for pull requests. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Documentation
On Tue, Sep 20 2022 at 08:03:12 PM -0700, Ryosuke Niwa via webkit-dev wrote: (2) is particularly important because many people who are new to WebKit often don’t know what they don’t know. This is why, for example, memory management section appears towards the beginning of the document and the information about adding IDL files is immediately followed by the discussion of JS wrapper lifecycles. With these information now split across multiple files, it’s easy for people to miss out on critical information. In the ideal world, people won’t be adding or editing IDL files before they understood how JS wrappers are managed because not knowing the latter is a sure way of introducing subtle GC bugs. I didn't know any of this info about JS wrapper lifecycle until I read about it in Introduction.md a couple months ago. It really does need to be very prominent or developers won't find it. That said, I think we can find a way to do this without keeping it all in one single page. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Documentation
On Tue, Sep 20 2022 at 01:16:53 AM -0700, Ryosuke Niwa via webkit-dev wrote: I’ve been working on https://github.com/WebKit/WebKit/blob/main/Introduction.md for the past couple of years, and I’d would have preferred to have a collaboration rather than a competition here. This Introduction.md is great work (I've learned a lot from it), but it's also getting pretty long for a single document. At least, it significantly exceeds my attention span. We could present this same info better if we split it into multiple pages. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Documentation
Why not double-down on the GitHub wiki? It's very easy to learn to use, and there are edit buttons everywhere so there is no "distance" between the docs and the ability to edit them. The easier it is to edit docs, the better we'll do at keeping them up to date. I like Markdown, and am OK with editing Markdown files wherever they live, but it's not very likely that I would install Swift and figure out how to build a new project to to see what the result looks like. With GitHub, we can easily preview results live to ensure we're not messing anything up. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Deployment of new EWS Non-Unified builder
On Thu, Sep 8 2022 at 03:00:00 PM +0300, Adrian Perez de Castro wrote: My laptop has 20 GiB of memory and a debug build in non-unified mode links just fine with either LLD or Mold (I haven't used the GNU linker for months). Something smells fishy with your setup. I haven't changed the default linker, so it's using ld.bfd. We used to prefer ld.gold by default, but don't anymore. That's probably why the RAM required has ballooned. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Deployment of new EWS Non-Unified builder
At this point I would just go ahead and create the EWS bot. Even if it's not going to be a default build configuration, we're still wasting a bunch of time and effort to keep it working, and the EWS would help fix that. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Deployment of new EWS Non-Unified builder
On Sat, May 21 2022 at 09:43:06 AM -0500, Michael Catanzaro wrote: I would go even further and consider enabling unified builds only in DEVELOPER_MODE (for CMake ports). For non-developer builds, compilation time is much less important than limiting RAM usage to reasonable levels. Using ninja's default parallelization level, I recently started hitting OOM failures even on a machine with 64 GB RAM! We have many people complaining that they cannot build on more normal machines with 16 GB RAM. If we have an EWS to ensure the non-unified build actually works, then it should be safe enough to make it the normal supported path for non-developers, rather than just a "best effort, let's hope it works today" thing. I withdraw this proposal. I thought that non-unified builds would significantly reduce peak RAM usage, but I was wrong. In fact, non-unified builds seem to require substantially more RAM at link time, perhaps because there are more object files to link together. On a desktop with 64 GB of RAM, I'm not able to link a non-unified build successfully without running out of RAM, but using a unified build it works fine. So my proposal was just totally off base. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] InjectedBundle deprecation
That sounds like the ideal way to handle this. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] InjectedBundle deprecation
On Fri, Aug 12 2022 at 01:40:02 PM -0700, Alex Christensen via webkit-dev wrote: Would the maintainers of the GTK and WPE APIs be willing to assist in migrating from those APIs and designing replacements in the UI process? Sigh... we'll need to discuss what to do. Unfortunately, these are public APIs and this will be extremely disruptive. If it's needed for site isolation, I don't see that we have much choice. But if we remove these APIs, Linux distros will get stranded on the last version of WebKit that still supports them and will be unable to take our further updates. Deprecation is a lot easier than removal. If we can keep deprecated APIs working and just disable site isolation when they're used, that would be much less disruptive. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Move CODEOWNERS file?
Hi devs, any opinions on moving CODEOWNERS from its current location, .github/CODEOWNERS, up one level to the root directory? This will make it easier to see and hopefully encourage more use and updates. The more accurate and comprehensive this file, the easier it will be to get our pull requests reviewed, so it's good for everyone to make it more visible IMO, rather than keep it in a hidden directory. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit is now on GitHub
On Thu, Jun 23 2022 at 03:21:59 PM -0700, Jonathan Bedard wrote: I’m aware of the WebKitGTK branches, please reach out about the WPE ones, I’m not sure which ones those are. The WPE releases actually use the WebKitGTK branches! They are shared branches. I suppose that is pretty confusing, but naming things is hard. Sounds like you already have this under control. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit is now on GitHub
On Thu, Jun 23 2022 at 10:29:55 AM -0700, Jonathan Bedard via webkit-dev wrote: Let me know if there is any fallout, As far as I know, WebKitGTK and WPE WebKit stable branches have not yet been migrated and are now read-only? Let's make sure not to delete SVN until we're certain they have migrated. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Mandatory Commit and Merge Queue
On Thu, Jun 2 2022 at 04:06:42 PM -0700, Chris Dumez via webkit-dev wrote: I am concerned by this proposal given how slow EWS and the merge queue are these days. Hopefully Jonathan's three proposed blockers will address this: - run-webkit-tests consulting results.webkit.org to avoid retrying known flakey or failing tests - Another MergeQueue bot - Xcode workspace builds to speed up incremental builds Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Deployment of new EWS Non-Unified builder
On Sat, May 21 2022 at 09:43:06 AM -0500, Michael Catanzaro wrote: I would go even further and consider enabling unified builds only in DEVELOPER_MODE (for CMake ports). For non-developer builds, compilation time is much less important than limiting RAM usage to reasonable levels. Using ninja's default parallelization level, I recently started hitting OOM failures even on a machine with 64 GB RAM! We have many people complaining that they cannot build on more normal machines with 16 GB RAM. If we have an EWS to ensure the non-unified build actually works, then it should be safe enough to make it the normal supported path for non-developers, rather than just a "best effort, let's hope it works today" thing. Any objections to this proposal? I would additionally request that the non-unified EWS also disable DEVELOPER_MODE, so we can additionally make sure we don't break the build when experimental features tied to that (e.g. WebRTC or LFC) are disabled. All the other EWS have DEVELOPER_MODE enabled, and this has been a regular problem in the past. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Deployment of new EWS Non-Unified builder
On Sat, May 21 2022 at 07:10:30 AM +, "Kirsling, Ross via webkit-dev" wrote: This is wonderful news—thanks Diego! Agreed. I would go even further and consider enabling unified builds only in DEVELOPER_MODE (for CMake ports). For non-developer builds, compilation time is much less important than limiting RAM usage to reasonable levels. Using ninja's default parallelization level, I recently started hitting OOM failures even on a machine with 64 GB RAM! We have many people complaining that they cannot build on more normal machines with 16 GB RAM. If we have an EWS to ensure the non-unified build actually works, then it should be safe enough to make it the normal supported path for non-developers, rather than just a "best effort, let's hope it works today" thing. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Immediate Deprecation of ChangeLogs
On Wed, May 11 2022 at 12:16:46 AM -0700, Ryosuke Niwa via webkit-dev wrote: No, I'm using Github clones to write patches then using Subversion checkout to commit those patches. If you use the old git repo via git-svn, not the GitHub repo, then you can use 'git svn dcommit'. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] accounts.google.com is blocking WebKitGTK
Thanks very much Ken! ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] accounts.google.com is blocking WebKitGTK
Hi, see: https://bugs.webkit.org/show_bug.cgi?id=240041 It is a little finicky, in that it *sometimes* works, and I don't know why. But usually Google blocks us. See screenshot: https://bugs.webkit.org/attachment.cgi?id=458768 I was hoping that it could be avoided by a user agent quirk, but sadly they are doing some deeper level of fingerprinting. Can anybody who is able to get attention from Google help get this reverted *urgently*? This is beyond unacceptable. I doubt we'll have any luck via the ask nicely approach, but it's worth a try. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] JSC broken on s390x
On Tue, Apr 19 2022 at 11:42:31 AM -0700, Yusuke Suzuki wrote: Do you have a s390x machine which can be accessible to JSC developers? Nope. :( I think, probably, only someone having this machine access can fix the problem. I agree. I've raised this as an issue. Anyway, we did manage to fix this issue today thanks to your help, also thanks to Daniel Kolesa for some pointers that helped me get you the info you needed to resolve the crash. Thank you! Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] JSC broken on s390x
Hi, I want to call attention to: https://bugs.webkit.org/show_bug.cgi?id=238956 It breaks JSC on s390x. If anybody is interested in this architecture, or cares about WebKitGTK updates in Fedora (this issue will be a blocker), any help would be much appreciated. :) I've also informed Red Hat that this architecture needs more help. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] ChangeLog Deprecation Plans
On Mon, Apr 18 2022 at 02:55:08 PM -0700, Yusuke Suzuki wrote: I think this is important. We are using commit message / ChangeLog as a document tied to the change, and we are writing very detailed description to make the intention / design of the change clear and making it as a good document when we read the change via git-blame, bisect, using that header, investigating how it works etc. To make / keep this commit message / ChangeLog helpful, we need review, and I think reviewing of these messages is critical to keep usefulness of them. I agree with all of the above. Actually, I'd suggest that the transition to git is a good opportunity to become a little stricter with commit message format than we historically have been. Except for trivial/obvious changes, more detail is better. However, we don't need ChangeLog files in the repo or inline review comments to do this. I'm sure we can make do with the normal GitHub review UI. I think COMMIT_MESSAGE proposal has various good benefits. 1. We can review commit mesasges. 2. In local development, we can commit expected COMMIT_MESSAGE file directly in our tree. We can eventually add more and more detailed information to this file while local development continues, and we can also revert COMMIT_MESSAGE change since it can be commited in the local branch. This has few advantages over using 'git commit --amend' or 'git rebase -i'. It would also be a custom, WebKit-specific part of our workflow. This is a good opportunity to remove as many WebKit-isms from our contribution process as possible, to make it easier for people who are not familiar with the project to contribute more easily. I suggest we at least try to do things like most other open source projects first, and only implement custom solutions if that fails. Commit message is tied to a commit, so editing commit without breaking commit-message is hard (how to revert one change from one commit without rewriting commit message? It requires some git hack). Separate independent COMMIT_MESSAGE file can solve this problem and makes local development easy. Developers who are used to git -- which nowadays is pretty much everyone except WebKit devs -- are also used to rewriting commit messages. Developers are NOT used to writing commit messages in a file named COMMIT_MESSAGE. 3. This solves the problem how to squash multiple commits in one PR. Merge-queue can just look at this file and use this as a commit message when squashing and landing. This means that, in a PR, we can push multiple small commits in our PR branch. What is the advantage to doing this, though? It's best if the commits in your PR match what you intend to land. The structure of commits is subject to review in most open source projects. If the commit history is messy, we should not approve the PR. For now, we've agreed that for now each PR should land as one commit. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] ChangeLog Deprecation Plans
On Mon, Apr 18 2022 at 08:30:04 AM -0700, Jonathan Bedard via webkit-dev wrote: 2) We need a way to comment on commit messages in review Current tooling sets the pull request description as the commit message, “Quote Reply” kind of provides a way to inline comment, although it’s not the formal review UI Proposal: Tooling should support a “COMMIT_MESSAGE” file in each pull request commit that becomes COMMIT_MESSAGE when a pull request is landed Although it's inconvenient that we won't be able to leave inline comments on commit messages anymore, is that really so serious a loss that it requires a strange workaround? It just doesn't seem like a very big deal? We can copy and paste and quote when we suggest changes in commit messages. Proposal: Have Tools/Scripts/git-webkit setup configure hooks in contributors local git repositories to lay down CommitMessages.history files on merge, checkout and commit which contain the last 5000 commit messages. We can put these in similar places to where ChangeLogs are today, although we would likely want them in fewer places because this will increase local compute time on many git operations. We could also make this a configurable setting so that engineers who are more comfortable with the raw command line tooling do not have to deal with slower git operations. What's wrong with `git log`? There are GUI apps that can visualize your git history if so desired, e.g. GNOME has gitg. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit and GitHub Update
I guess I should create a feedback issue: https://bugs.webkit.org/show_bug.cgi?id=239124 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit and GitHub Update
On Mon, Apr 11 2022 at 03:55:36 PM -0700, Jonathan Bedard via webkit-dev wrote: start creating some pull requests! Hi, For pull requests to find interested reviewers, we need a way to subscribe to labels. E.g. I want to receive notifications for pull requests with a WebKitGTK or WPE label. Another developer might want to watch Network, Multimedia, JavaScriptCore, Web Inspector, etc. This is super easy to do with GitLab, but GitHub does not have this functionality at all. I believe when we previously discussed this problem, somebody suggested running a bot that would allow us to emulate this functionality by subscribing to notifications from the bot. Does anybody remember what this bot was, or have another concrete suggestion on how to make this work? (This will be a problem for issues as well, if we eventually move from Bugzilla to GitHub issues, but I imagine the solution would be the same.) Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal to update WebKitGTK dependency policy
On Tue, Mar 8 2022 at 03:01:04 PM +0100, Carlos Alberto Lopez Perez wrote: It turns out this above opinion of mine doesn't reflect a consensus opinion inside Igalia. After sending the above e-mail, I talked with my colleagues at Igalia (my failure for not doing that before) and it seems that we are not happy with committing to support the libraries for such long amount of time. Ah, alas. Well it's ultimately Igalia's choice, of course. - Which port(s) is RedHat interested in supporting? Only the GTK port, or both GTK and WPE? We ship WebKitGTK, libwpe, and wpebackend-fdo, but not WPE WebKit. - Is RedHat willing to devote development time to work upstream on the goal of keeping WebKit working with older libraries? Um, yes, of course nobody except me is likely to spend time to keep WebKit building on RHEL. The difference is I would be able to commit my changes upstream in the future, instead of keeping them downstream and rebasing them when they break. E.g. it looks like https://bugs.webkit.org/show_bug.cgi?id=235367 will have to live downstream. If we had this policy, I would be able to land stuff like that upstream too. The main impact on other developers would be an increased wait before you can remove preprocessor guards that support older library versions. That could be annoying, but I don't think it will require too much time commitment. - Will buildbots be provided for RHEL, in the same way Igalia maintains Ubuntu LTS and Debian stable builders to catch issues? I'm not personally very concerned about whether we have upstream builders for RHEL, since fixing problems when they reach tarball releases is good enough for me. But yes, since you requested it, we can probably add upstream bots. (They would probably actually run CentOS Stream, not RHEL.) That will take some time, though, because I'm not currently working on it. In my previous mail, I said I would defer this proposal until we are ready with the requested bots. I do very much want to add more JSC cloop EWS, and I bet Red Hat infrastructure folks might find time to help with those. We can probably add some builders at the same time. But to keep timeline in perspective: I've been planning this for years, but have not yet started on it. :P In any case, we think that 3+2 of support is too much. We can maybe agree on 3+1 (support each RHEL version until one year after the next one, like we do with Debian/Ubuntu) or on just 3 (no extra year of support), depending on how much RH is willing to help upstream. Hm, I guess I'd better gratefully accept whatever I can get. I'll attempt to keep it working downstream for the full 3+2 years regardless. Regarding resources from Red Hat to help upstream: that's going to remain just me. Certainly I would handle any changes needed to keep WebKit working on RHEL. Beyond that, I'll continue to help out a bit here and there. I wouldn't expect to see major changes in my contribution habits. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal to update WebKitGTK dependency policy
On Thu, Feb 17 2022 at 01:20:50 PM -0600, Michael Catanzaro via
webkit-dev wrote:
That seems like a reasonable request. I'll delay modifying the policy
until I'm able to provide an answer regarding the requested bots.
This could take a while, so the proposed policy change is dead for now.
But hypothetically, if I did have some bots ready, would Igalia be OK
with the proposed change? You seemed skeptical ("I think this may cause
tension in the future regarding supporting the usual GNOME libraries
that move fast: GTK, GStreamer, etc") and I'm sensitive to the fact
that proposing additional burden on other devs is not exactly a super
nice thing to do. I wonder what other devs think.
Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal to update WebKitGTK dependency policy
On Thu, Feb 17 2022 at 05:41:34 PM +, Carlos Alberto Lopez Perez via webkit-dev wrote: If I understand this correctly, that would mean that we would have to support the libraries that we rely on, up to a version that may be quite old. Right now we are supporting a cycle of 2+1=3 (both debian and ubuntu release each 2 years). And this change would mean that we would have to extend the period up to 3+2=5 which is quite more. Yes. I think this may cause tension in the future regarding supporting the usual GNOME libraries that move fast: GTK, GStreamer, etc Possibly, yes. In practice, I think we're already in the habit of keeping #ifs for older dependencies around for longer than is required by our policy, so I suspect it will probably not be *too* annoying compared to our current practice. I wish this would benefit Ubuntu as well, but in practice it won't, since they cannot keep up with our toolchain requirements, and Apple doesn't want to support older toolchains. That's tough to square. :/ To give some data, the last version of RHEL is 9 (released on Nov 2021) Nov 2021 was RHEL 9 beta. We are planning to release RHEL 9.0 this coming spring. which means that we would support RHEL 8 up to Nov 2023. And RHEL 8 was released on May 2019 and includes this versions of libraries we use: gstreamer = 1.16 gtk = 3.22 glib = 2.56 libsoup = 2.62 cairo = 1.15 icu = 60.3 Yes, though keep in mind I'm proposing to match the latest minor release (currently RHEL 8.5), not the earliest minor release (RHEL 8.0). We used to update desktop package versions fairly aggressively in RHEL 7 (so long as they don't break API/ABI), but in RHEL 8 we have been more conservative and have mostly stopped doing so. So in practice, yes, most of those versions are indeed unlikely to change. Also if we are going to do this, and we are serious about it, then we would need at least two new buildbots at build.webkit.org for testing the build on the last two versions of RHEL. Is RedHat going to provide the resources for the bots and is going to help taking care of things when they broke there? That seems like a reasonable request. I'll delay modifying the policy until I'm able to provide an answer regarding the requested bots. We'd probably have them run CentOS Stream rather than actual RHEL. I suppose that's what we should target with the dependencies policy, as well, since it's simpler than having to know the difference between different RHEL minor releases. What we *really* want most of all is JSC EWS for aarch64, ppc64le, and s390x. Adding a couple x86_64 buildbots should be comparatively easy Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal to update WebKitGTK dependency policy
Hi, Since nobody objected to this proposal, I will update our policy soon. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] How to make changes to website?
On Wed, Feb 16 2022 at 02:05:40 PM -0800, Chris Dumez wrote: Jon Davis is probably the right contact for Webkit.org. Um... yeah, of course he is. I knew this. Brain fart, sorry. My suggested change is to add a warning sentence to the https://webkit.org/contributing-code/#choose-a-bug-report section: "You can also create a new report. Be sure to search the database before creating new reports to avoid duplication, and select the most accurate component possible to maximize the chance that your contribution will be noticed by the right maintainers and reviewed." ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] How to make changes to website?
Hi, I want to make a modification to: https://webkit.org/contributing-code/ Suggested here: https://bugs.webkit.org/show_bug.cgi?id=232935#c6 It looks like this page is not part of WebKit/Websites/webkit.org. Anyone know who can edit it? Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposed changes to Bugzilla 'Resolution' categories
On Thu, Feb 10 2022 at 11:55:56 AM -0800, Brent Fulgham via webkit-dev
wrote:
(1) Add a new “Behaves As Designed” option:
This will represent bugs that were filed when the reporter
misunderstands a feature, or wants behavior that we have considered,
but chosen not to allow.
This would be used instead of the somewhat offensive “WONTFIX”
or mildly offensive “INVALID” resolutions we currently use.
I'm surprised we don't already have an appropriate status for this,
considering how common it is. Calling this NOTABUG would match at least
one other major Bugzilla instance, and is nice and short.
Alternatively, we could call it EXPECTED BEHAVIOR. BEHAVES AS DESIGNED
seems a bit long.
(2) Add a new “Platform To Resolve” option:
Like Simon, I currently use the existing MOVED status to indicate this
("Moved" to external tracker), although it's not a perfect fit if I
simply tell the reporter to report elsewhere (in that case, it really
means "needs to be moved"). If we want to add another status for this,
we should look for a simpler name.
Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Proposal to update WebKitGTK dependency policy
Hi, I'd like to selfishly propose updating our dependencies policy https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy in order to accommodate RHEL in addition to Debian and Ubuntu. My goal is to provide WebKitGTK updates for the first five years (the "full support" period) of a RHEL major release, not just three years. However, we have some magic I don't understand allows use of newer toolchains, including newer libstdc++. We can actually somehow link newer libstdc++ into the same process as system libstdc++, so we can exempt the entire build toolchain (including CMake) from this policy, so this won't have any effect on discussions like "when can we use C++20 features" or "what version of CMake can we depend on." The primary impact would be on dependencies like ICU, GStreamer, etc. ICU is particularly important because this library bumps its ABI with every major release, so updating ICU to newer major versions is not possible. This would lock us into supporting ICU 67 until spring 2027. If we decide to land https://bugs.webkit.org/show_bug.cgi?id=235367 -- which currently looks unlikely -- then it would additionally lock us into ICU 60 until spring 2024. I think five years' support would benefit Ubuntu as well -- this matches the primary support lifetime of an Ubuntu LTS -- except Ubuntu doesn't seem to have the capability to build with newer toolchains, which means that, in practice, they will stop updating WebKit whenever we require a newer build toolchain. And although I think it would be a good idea to support Ubuntu for longer, I'm not brave enough to propose that we freeze our build toolchain dependencies for five years. So I will not suggest extending the support period for Ubuntu. Specifically, I propose adding the following text to our policy: * "We support the latest minor release of each major version of RHEL until two years after the release of the next major version." (Note: we currently have a three-year time-based release cycle, so that's five years total. If that were to unexpectedly change in the future, then adjusting the text of the policy would be needed.) And: * "For RHEL, WebKit is not expected to remain buildable using the default system libstdc++. The requirement for WebKit to remain buildable may be satisfied using GCC and LLVM toolsets from Application Streams." Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Request for position: Cookie Expires/Max-Age attribute upper limit
On Wed, Jan 19 2022 at 08:12:07 AM -0800, Ari Chivukula via webkit-dev wrote: The limit MUST NOT be greater than 400 days (3456 seconds) in duration. I don't see any super great reason to prevent browsers from choosing a larger max age if desired. That said, 400 days sounds like a good choice. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] [PSA] WebKitGTK layout testers available on the Bugzilla EWS bubbles
On Fri, Dec 24 2021 at 12:44:49 AM +, Carlos Alberto Lopez Perez via webkit-dev wrote: So we ended deploying a different version of the EWS that has a much higher tolerance to pre-existent failures (up to 500 before exiting early) and also that tries hard to discard pre-existent failures and flakies by repeating each failure 10 times with patch and 10 times without it. [1] Mixed thoughts on this: (1) Good job. Having layout tests on EWS is a great improvement. We've been talking about this for a long time, and you finally made it happen! (2) That you needed to use such a big hammer to make the EWS work reliably suggests either that either WebKitGTK quality or WebKit test quality is quite low. I'm sure it's a mix of both, but mostly the former, because test flakiness is not this severe for Apple ports. This is not encouraging. (3) Any plans for WPE? Anyway, I agree this was the best approach given the current situation. Happy holidays, Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Objective-C++ style, pointer and reference placement
On Tue, Dec 21 2021 at 02:08:42 PM +0200, Kimmo Kinnunen via webkit-dev wrote: * All C and Objective-C code should be formatted with rules consistent to the C++ rules Unfortunately all of the WPE/GTK C code intentionally uses a space between the type and the asterisk * (for example, WebKit/Tools/MiniBrowser/gtk/BrowserWindow.c). I guess we could just omit all these files from style checker, or reformat them all, but it's going to be annoying to change either way. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Review request time limit
On Mon, Nov 1 2021 at 01:30:28 PM -0700, Alex Christensen via webkit-dev wrote: I just removed r? on all the bugs in http://webkit.org/pending-review that had requested review in 2018 or before and had been untouched since then. I imagine that did not interrupt anyone’s work. I was thinking of removing review requests on bugs that hadn’t been updated in one full year to maintain the usefulness of the review queue. Does anyone have any strong opinions that that is too much time or too little time? Most reviews are done in a few days or weeks, but occasionally something useful sits in the review queue for a few months. $0.02: Removing the flag acts as a nice reminder: "hey, you need to find a reviewer for this patch!" So the sooner the better IMO. If we were to automate this, I would do a warning comment after one month, then strip r? after two months. Something like that. /$0.02 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] -Wreturn-type and -Wredundant-move reminders
On Fri, Oct 29 2021 at 03:06:17 PM -0700, Myles Maxfield wrote: Will GTK/WPE EWS catch these errors? Currently no, but they will once we solve https://bugs.webkit.org/show_bug.cgi?id=155047. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal to enable logging under non-systemd linux distros
On Wed, Oct 20 2021 at 02:07:56 AM +0200, Pablo Correa Gomez via webkit-dev wrote: - Rename USE_SYSTEMD to USE_JOURNALD and have a conditional check which looks for elogind if libsystemd is not found, similar to the hack I used for proof-testing. This one! Do this one! We don't need two different build options for systemd vs. elogind, when all we really care about is whether the journald API is available. Michael P.S. (We might also consider adding an environment variable to redirect all log messages to stderr. This is *almost* possible now after https://trac.webkit.org/changeset/283469/webkit, but requires more playing with the #if guards. Don't worry about this if you're not interested in working on it. I just mention it in case that sounds like your idea of an exciting project. ;) ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] -Wreturn-type and -Wredundant-move reminders
On Tue, Oct 19 2021 at 01:43:19 PM -0700, Ryosuke Niwa wrote: Can we add a style checker rule to detect at least simple cases? I think detecting this pattern without false positives would be pretty tough. Requires too much knowledge of the semantics of the code. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] -Wreturn-type and -Wredundant-move reminders
Hi devs,
A reminder about this common idiom:
switch (...) {
case Foo:
return ...;
case Bar:
return ...;
}
RELEASE_ASSERT_NOT_REACHED();
When it's intended that the code always returns inside the switch
statement, the RELEASE_ASSERT_NOT_REACHED() is required to avoid
tripping GCC's -Wreturn-type. If you forget it, I or somebody else will
wind up adding it later to avoid the warning. Clang does not warn here,
and this is the most common type of warning I clean up, so please don't
forget! :) This warning is useful in other situations, and it seems
nicer to placate GCC than to disable it.
I'll sneak in another reminder: "return WTFMove()" is almost always not
needed. Clang warns only if the move prevents return value
optimization, but GCC will always warn if it detects the move is
unneeded.
Have a nice day,
Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Network Information API reboot: request for early feedback
OK, so you are using the existing OS-level network interface settings. At least on Linux, that is a heuristic-based per-interface setting with a manual override. None of this happens without the user voluntarily revealing the information. How would that possibly work? A new type of permission prompt? It's easy for users to decide whether a website should have geolocation or microphone access, but the risk here is just extra entropy, which is going to be real hard to explain to users. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Network Information API reboot: request for early feedback
On Mon, Aug 30 2021 at 10:16:54 AM +0200, Thomas Steiner via webkit-dev wrote: Thanks for the reply, Ryosuke! Just to clarify, the `metered` attribute would be a manual user setting, not a browser heuristic. This means you could easily mark your all-data included WiFi at home as metered if you wanted to, or, on the opposite end, mark your roaming data plan you purchased for a ton of money at the airport as unmetered. None of this happens without the user voluntarily revealing the information. Why would it be implemented as a manual setting in the browser, rather than a per-connection setting controlled by the OS? On Linux, NetworkManager already knows whether each network interface is metered or not. Users can override the choice in the unlikely event it guesses wrong. Why should a web browser offer a second level of override in addition to existing system settings? Are you planning to offer a browser-level override for every network interface separately, or just one single toggle that doesn't consider which network interface is in use? Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] [Help] WebProcess CRASHED
On Fri, Aug 20 2021 at 06:30:16 PM -0600, Alemar wrote: Okay that makes sense. How do I install debuginfo for webkit though? Looking into apt, all I can find is this: Hi, there are distro-specific instructions here: https://wiki.gnome.org/GettingInTouch/Bugzilla/GettingTraces/DistroSpecificInstructions debuginfod is not going to help you because no distros use it yet. Fedora 35 will be the first to ship with debuginfod enabled, which will eliminate the need for debuginfo packages for Fedora users. It's pretty cool. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] [Help] WebProcess CRASHED
On Fri, Aug 20 2021 at 11:27:17 AM -0600, Alemar wrote: #2 0x7fcfd172ff2b in () at /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37 #3 0x7fcfd37e0622 in () at /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37 #4 0x7fcfd37efef6 in () at /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37 #5 0x7fcfd31529a6 in () at /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37 #6 0x7fcfd315321a in () at /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37 #7 0x7fcfd2c5b9fd in () at /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37 #8 0x7fcfd2c5cf0f in () at /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37 #9 0x7fcfd3095412 in () at /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37 #10 0x7fcfd30954e6 in () at /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37 #11 0x7fcfd30c00b4 in () at /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37 #12 0x7fcfd073d025 in () at /lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18 #13 0x7fcfd073d2a3 in () at /lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18 Hi, it looks like you're missing debuginfo for WebKit. When you install debuginfo and take the backtrace again, then you'll see function names, variables, and even line numbers that will point to exactly what's wrong. All we know from that is it crashes somewhere in WebKit, which could be anywhere. :) ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] [Help] WebProcess CRASHED
Hi, you need to get a backtrace with gdb. There are some instructions here: https://wiki.gnome.org/GettingInTouch/Bugzilla/GettingTraces Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Position on font-family: emoji (and -webkit-pictograph)
On Fri, Aug 13 2021 at 01:54:39 PM +0200, Frédéric Wang via webkit-dev wrote: I understand there is backward compat concerns about removing features but do we agree to add "emoji" as an alias for "-webkit-pictograph", similar to what we did in [3] for "system-ui"? This sounds pretty uncontroversial. ;) ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Removing the ENABLE(CSS_SCROLL_SNAP) flag
Hi Martin! My $0.02: when all ports have the feature enabled and the code is cross-platform, it's usually best to remove the build flag unless there's a particular strong reason to keep it around. We have more than enough build flags, and if you get to delete old code that just makes it even better! Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Let's use -Werror on EWS?
On Tue, May 25 2021 at 06:22:41 AM -0500, Michael Catanzaro via webkit-dev wrote: I'm hoping there are not very many warnings, since I've been cleaning warnings I see for several years now. There will probably be a few, though, which could be caused by (a) EWS using non-default build options like -DENABLE_EXPERIMENTAL_FEATURES=ON, which notably enables building WebRTC, and (b) using older GCC versions or other older dependencies than I do. So a few extra warnings are likely simply because my personal build environment is not identical to EWS. I forgot about builds on 32-bit architectures, which are filled with pointer aliasing warning spam reminding us how unsafe our code is. We don't have any EWS for those platforms, though, only regular bots (which, again, should definitely not use -Werror, because we don't want to lose a night of test results to a silly build warning). ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Let's use -Werror on EWS?
On Mon, May 24 2021 at 07:36:03 PM -0700, Darin Adler via webkit-dev wrote: I do not know why we do not already use -Werror on GTK and WPE and I support using it there after fixing all the warnings. I'd be willing to enable it at the CMake level if it was conditional on -DENABLE_DEVELOPER_MODE=ON. I tried proposing that previously in https://bugs.webkit.org/show_bug.cgi?id=155047 but it was not approved at the time. Of course we can't enable -Werror by default, though, since it would be offensive to distributors and non-WebKit developers trying to build WebKit. And it would make bisecting pretty hard for ourselves too. We don't want non-EWS builds to fail just because you're using a newer compiler or a different optimization level that causes warnings to be more sensitive. So it should only be used on EWS or in DEVELOPER_MODE. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Let's use -Werror on EWS?
On Mon, May 24 2021 at 06:32:03 PM -0700, Darin Adler via webkit-dev wrote: But we can’t just turn on -Werror until after we fix all the warnings! Who will do that project. I'm hoping there are not very many warnings, since I've been cleaning warnings I see for several years now. There will probably be a few, though, which could be caused by (a) EWS using non-default build options like -DENABLE_EXPERIMENTAL_FEATURES=ON, which notably enables building WebRTC, and (b) using older GCC versions or other older dependencies than I do. So a few extra warnings are likely simply because my personal build environment is not identical to EWS. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Let's use -Werror on EWS?
On Mon, May 24 2021 at 05:42:37 PM -0500, Michael Catanzaro wrote: But really, rather than cherry-picking particular warning flags, using -Werror seems simplest to me. Problematic warnings should be disabled or suppressed. We might want to globally suppress -Warray-bounds and -Wnonnull when compiling with GCC (not with Clang) since GCC has frankly become pretty bad with these and they're almost always false-positives. It's a shame, because these warnings sometimes do catch serious bugs, but relying on Clang developers to notice these might be sufficient. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Let's use -Werror on EWS?
Hi, I'd like to suggest turning on -Werror on at least the GTK and WPE EWS, to reduce the amount of time I spend cleaning up newly-introduced build warnings. ;) If we're worried about too many spurious build failures, let's at least build with a few flags to prevent the most common GCC warnings that developers using Clang will never notice: -Werror=return-type, -Werror=class-memaccess, and -Werror=pessimizing-move. These are simple to avoid if you see the warning from GCC, but very easy to miss if you develop with Clang. I guess these account for more than half of new GCC warnings introduced into WebKit. I'd also like to see -Werror=unused, since it's easy to introduce these warnings for other ports when doing anything involving conditional compilation. That might require some CMake changes, though (as we don't want to break -Wno-unused-parameter, which we use when building Source/WebKit and several directories under Tools). But really, rather than cherry-picking particular warning flags, using -Werror seems simplest to me. Problematic warnings should be disabled or suppressed. I do *not* suggest using -Werror on any non-EWS bots, since that will make gardening harder for almost no benefit. We do not want to lose test results due to a missing UNUSED_PARAM() or RELEASE_ASSERT_NOT_REACHED() somewhere. I also certainly do not suggest using it by default in CMake, which would really annoy our distributors. I would only use it in the EWS bot config. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] JPEG XL support?
Hi Sami, I don't have any strong opinion on JPEG XL, asides from the general observation that adding more image decoders written in memory-unsafe languages is a generally sad thing to do. (I'm still not happy about how we were forced to support JPEG 2000 a couple years back due to websites using Akamai Image Manager.) In particular, I notice that libjxl is quite a lot of C++ code. On the other hand, given that WebKit is itself all C++, you could reasonably say something about "people in glass houses should not throw stones." :) So even though image decoders are quite sensitive, that shouldn't be a blocker IMO. The most important point you need to know is that Safari doesn't use WebKit's image decoders at all, so if you want JPEG XL to work in Safari, contributing JPEG XL support to WebKit is not likely going to achieve your goal. Even if Safari did use our image decoders, which it doesn't, we don't copy third-party projects into the WebKit source without a *very* exceptional reason to do so (as for ANGLE or libwebrtc), so OS support for JPEG XL is going to be key. There are two cases: (1) Non-Apple platforms use image decoders under Source/WebCore/platform/image-decoders. Depending on libjxl if it is installed as a system library, and using it to implement a JPEG XL image decoder under Source/WebCore/platform/images-decoders/jpegxl, seems OK to me. (Whereas copying libjxl into the WebKit source repo would certainly not be OK. That's way too much code.) There would need to be a CMake build option to disable the dependency for systems where libjxl is not available as a system library. It would only make sense to do this if somebody makes an effort to package libjxl for at least a few major Linux distros, otherwise it won't be used in practice. PlayStation and Windows ports can then build libjxl themselves if they so choose. (2) Apple platforms use CoreGraphics for image decoding, see Source/WebCore/platform/graphics/cg/ImageDecoderCG.[cpp,h]. I don't know much about this, but I don't think it's open source, so I would guess that contributions are probably not possible. I'm not sure what to tell you here. Hopefully somebody from Apple will comment. Good luck, Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New EWS Non-Unified builder
On Mon, May 3 2021 at 12:21:57 PM -0700, Sam Weinig via webkit-dev wrote: So, does anyone have any recent measurements of clean build times with and without unified sources enabled? If so, what is the current delta? That would be painful to check, because you would first have to fix all the current non-unified build failures. If somebody wants to spend all day chasing the current round of build failures, I would be interested to see the measurements ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Detecting and handling unresponsive web processes
On Wed, Apr 28 2021 at 04:14:16 PM +0200, Miguel Gomez via webkit-dev wrote: But if we give the option to disable this behavior, then we need to provide a way for the apps to handle the situation, don't you think? And this means adding new API (being it the one to retrieve the process ID or the one to kill the web content process directly). Would an application ever want to do something to handle the situation other than load a new page? Perhaps you would want to use webkit_web_view_load_alternate_html() to display an error page, for example. An API to allow killing the process is only needed if the application wants to do something when the process is killed *without* loading a new page, yes? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Request for position: Removing 3DES from TLS
Looks like this change is clearly safe. I doubt Safari controls its own TLS ciphersuite settings. In WebKitGTK, they're controlled by the operating system's TLS backend and crypto policy. 3DES has been disabled for a while now on modern systems, and users have not reported any compat issues, which is not surprising given your finding of 0.00%. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Detecting and handling unresponsive web processes
On Tue, Apr 27 2021 at 10:18:04 AM +0200, Miguel Gomez via webkit-dev wrote: * Have some API method that allows to kill the problematic web process, and let the browser call it when needed. The next load will create a new web process. We only need this API if we are unable to fix the existing webkit_web_view_load_* APIs to work when the web process is unresponsive, right? So we probably do not need it. * Modify some of the existent load/reload API calls so they check whether the web process is responsive or not. If it's unresponsive, kill the process before trying to do anything else, and a new web process will be created when the rest of the code is executed. This behavior is a better default for most client applications. Applications that want more control would just need a way to disable this behavior, right? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Any way to get a debugging symbols build without compiling?
On Thu, Apr 8 2021 at 08:38:55 AM -0600, Alemar via webkit-dev wrote: Oh also, sorry for the extra email, but I just noticed that my webkit2gtk build is like 3 GB of size (!) no wonder why it doesn't crash, with that size that's the least thing I'd expect haha. But I can't definitely distribute that. So yeah, does anyone know what is the build command line for a production build? The usual size is around 50 MB :) Debug symbols are huge, which is why non-Arch distros strip them into separate debug packages. 3 GB sounds normal for a build with embedded debug symbols. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Fwd: Any way to get a debugging symbols build without compiling?
On Thu, Apr 8 2021 at 08:21:43 AM -0600, Alemar via webkit-dev wrote: So, my question is: What CLI arguments are used for building the release version posted on the website? I'm assuming it's not just: cmake -DPORT=GTK -DCMAKE_BUILD_TYPE=RelWithDebInfo -DENABLE_GAMEPAD=NO -DENABLE_INTROSPECTION=NO -GNinja Hi, this is decided by Manjaro. I'm not source where to see their packaging, but the Arch packaging is here: https://github.com/archlinux/svntogit-packages/blob/packages/webkit2gtk/trunk/PKGBUILD And honestly it's relatively likely that Manjaro might not make any changes to it. You can see the build flags they are using: cmake -S webkitgtk-$pkgver -B build -G Ninja \ -DPORT=GTK \ -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_INSTALL_PREFIX=/usr \ -DCMAKE_INSTALL_LIBDIR=lib \ -DCMAKE_INSTALL_LIBEXECDIR=lib \ -DCMAKE_SKIP_RPATH=ON \ -DENABLE_GTKDOC=ON \ -DENABLE_MINIBROWSER=ON FYI your debugging experience today was about 13498x harder than it needed to be. Arch and its derivatives like Manjaro are the only distros that don't provide debug symbols for its packages. In any other distro you would just install the relevant debug packages, and then you wouldn't have to worry about not being able to reproduce the problem with your own custom build. It's impossible to know why one build crashes and another doesn't, but there could be many differences, e.g. Arch hopefully uses security hardening flags when building its packages (not sure about that, but I hope so ;) that are not used by default when you build yourself. FWIW I recommend using -DCMAKE_BUILD_TYPE=RelWithDebInfo rather than -DCMAKE_BUILD_TYPE=Debug to ensure you get a release build. Debug builds indeed have some different codepaths and very different performance characteristics. Normally debug builds crash more because assertions are enabled, but I suppose it's indeed possible that some crash might not occur in a debug build for whatever reason. But even if you use RelWithDebInfo, I'm afraid there's no guarantee you'll be able to reproduce the crash you're hunting. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Request for position on Schemeful Same-Site
On Mon, Nov 30, 2020 at 11:18 am, Steven Bingler via webkit-dev wrote: Pinging this thread again. Schemeful Same-Site is moving into the Intent to Ship phase in Blink. Hi Ryosuke, any update? Schemeful Sames-Site looks like a clear improvement to me. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Starting January 4, 2021, Google will block all sign-ins to Google accounts from embedded browser frameworks
On Tue, Nov 17, 2020 at 3:22 pm, Maciej Stachowiak wrote: This sounds obnoxious and potentially anti-competitive. But I think it’s restricted to OAuth flows, which would indeed only affect other sites that allow the user to sign in with their Google account. So that would be the thing to test. I tested oauth login this using my hacked-up ResourceRequestBase with gnome-online-accounts... and it still worked fine. So assuming the behavior on January 4 matches the behavior when we send this test header today, we should be OK... at least for now. I'm still rattled. The statement of intent is pretty clear: anything that's not a major browser is illegitimate and may be blocked. There's not really any significant technical reason to block CEF but not WebKit, after all. It's probably only a matter of time ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Starting January 4, 2021, Google will block all sign-ins to Google accounts from embedded browser frameworks
On Tue, Nov 17, 2020 at 12:50 pm, Michael Catanzaro
wrote:
Oh, I missed a very important point. There is a header we can use to
test: Google-Accounts-Check-OAuth-Login:true. I will try to figure
out how to hack up the libsoup backend to send that header with all
requests and see what happens
I tested this hack:
diff --git a/Source/WebCore/platform/network/HTTPHeaderNames.in
b/Source/WebCore/platform/network/HTTPHeaderNames.in
index cbc470412f9f..eb19ab00a054 100644
--- a/Source/WebCore/platform/network/HTTPHeaderNames.in
+++ b/Source/WebCore/platform/network/HTTPHeaderNames.in
@@ -109,3 +109,5 @@ X-Temp-Tablet
// These headers are specific to GStreamer.
Icy-MetaInt
Icy-Metadata
+
+Google-Accounts-Check-OAuth-Login
diff --git a/Source/WebCore/platform/network/ResourceRequestBase.h
b/Source/WebCore/platform/network/ResourceRequestBase.h
index 6c9ce5cccefe..db234c37271f 100644
--- a/Source/WebCore/platform/network/ResourceRequestBase.h
+++ b/Source/WebCore/platform/network/ResourceRequestBase.h
@@ -206,6 +206,7 @@ protected:
, m_hiddenFromInspector(false)
, m_isTopSite(false)
{
+ addHTTPHeaderField(HTTPHeaderName::GoogleAccountsCheckOAuthLogin,
"true");
}
ResourceRequestBase(const URL& url, ResourceRequestCachePolicy
policy)
@@ -221,6 +222,7 @@ protected:
, m_hiddenFromInspector(false)
, m_isTopSite(false)
{
+ addHTTPHeaderField(HTTPHeaderName::GoogleAccountsCheckOAuthLogin,
"true");
}
void updatePlatformRequest(HTTPBodyUpdatePolicy =
HTTPBodyUpdatePolicy::DoNotUpdateHTTPBody) const;
And confirmed in the web inspector to ensure the header is really sent.
Login still works. So... maybe we will be OK? I'm not sure. I tested
direct login via google.com. I'm confused as to how this change is in
any way related to OAuth. Maybe it will only break for third-party
websites that allow logging in with a Google account? I guess we'll
find out
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Starting January 4, 2021, Google will block all sign-ins to Google accounts from embedded browser frameworks
Oh, I missed a very important point. There is a header we can use to test: Google-Accounts-Check-OAuth-Login:true. I will try to figure out how to hack up the libsoup backend to send that header with all requests and see what happens ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Starting January 4, 2021, Google will block all sign-ins to Google accounts from embedded browser frameworks
Hi, Today I received a Google Developers email with subject "[Action Required] Starting January 4, 2021, we will block all sign-ins to Google accounts from embedded browser frameworks." It linked to this Google blog post: https://developers.googleblog.com/2020/08/guidance-for-our-effort-to-block-less-secure-browser-and-apps.html Summary: Google will attempt to block logins from "CEF-based apps and other non-supported browsers." Presumably "non-supported browsers" likely includes non-Safari WebKit, considering how much time I spend trying to develop user agent quirks to suppress Google's unsupported browser warnings on Gmail, Google Docs, etc. I guess we will find out on January 4. Google says: "The browser must identify itself clearly in the User-Agent. The browser must not try to impersonate another browser like Chrome or Firefox." We cannot comply with this because user agent spoofing is required for compatibility with various Google websites. I am continually fighting to maintain our user agent quirks for Google domains, see e.g. [1] or [2]. Even if we were to remove all user agent quirks, it would still be impossible for Google to distinguish between a desktop browser and an embedded browser framework, since the user agent header is going to be the same: Epiphany doesn't even append "Epiphany" anymore, in order to maximize the chances that websites will treat us like Safari. Even if we did, there are many other WebKit-based browsers that would be impacted (off the top of my head: eolie, surf, etc.) So we'll see what happens on January 4. If our users get locked out of google.com, I'll try to come up with new quirks if possible, but if Google is really determined to block non-Safari WebKit, it will win. E.g. it's easy to do JS feature detection (scary) or TLS handshake fingerprinting (extremely scary) and see we are not really the browser that our user agent quirk claims to be. We are largely toothless here, unfortunately. If Google continues to discriminate solely on the basis of the user agent header, and doesn't adopt any more advanced discrimination mechanisms, then we will survive, although it would help if Apple is willing to take a hard stance and adopt the same set of cross-platform quirks in Safari, which would "work" by causing Safari to break in the same way as non-Safari WebKit... probably not very palatable, but if adopted well in advance of this Jan 4 flag date, it would at least make it *harder* for Google to hurt non-Safari WebKit. (Adopting the quirks *after* the flag date would likely just immediately break Safari.) But if Google does this properly and uses more sophisticated browser fingerprinting techniques, Epiphany is done for. This could be an existential threat for non-Safari WebKit browsers. Nobody is going to be interested in using a browser that doesn't support Google websites. Google's expressly-stated goal is to block embedded browser frameworks and non-supported browsers from signing into Google accounts. The blog post says: "This block affects CEF-based apps and other non-supported browsers." It says: "We do not allow sign-in from browsers based on frameworks like CEF or Embedded Internet Explorer." Clearly CEF is the main target, but I guess WebKit (and likely also QtWebEngine) is at risk too; even if we're not mentioned directly, it seems pretty clear that WebKitGTK, WPE, PlayStation and WinCairo ports, etc. are all likely non-grata. So what should WebKit do about this? I don't know. Nothing has happened yet, so I guess we could wait and see what happens on January 4. Maybe this won't affect us at all. But my fear is that January 4 will arrive, we will be blocked, and more user agent quirks may or may not work. Even if WebKit is not blocked, we can be confident January 4 will be a sad day for browser diversity. I wonder if this is something that WebKit as a project could push back against... somehow. Maybe publish a statement supporting browsers based on embedded frameworks (WebKit, CEF, QtWebEngine)? Or some new WebKit project policy? Any suggestions? Michael [1] https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/platform/UserAgentQuirks.cpp?rev=269908 [2] https://bugs.webkit.org/show_bug.cgi?id=215845 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Embedding Identifiers in Commit Messages
On Wed, Nov 4, 2020 at 11:51 am, Jonathan Bedard wrote: We don’t have post commit hooks in SVN to do this sort of thing, and I don’t intend to add them now. We are going to have a system on GitHub to do this (not post commit hooks, but I won’t dive into the details here). There really aren’t a lot of people who land changes outside of webkit-patch, among things that would break if folks were regularly not using webkit-patch is trac.webkit.org, which relies on the commit message being set. Probably not often on trunk. But on stable branches, I assume 100% of changes are landed without webkit-patch? At least, I always used 'git svn dcommit' on stable branches. I also used this on trunk when I needed to fix an error in a ChangeLog (something webkit-patch is not good at doing). Lastly, this doesn’t add a race-condition that wasn’t already there. One of the downsides of SVN is that, unlike git, it is a centralized version control system, so clients must be synced to upstream before committing. This is true now, even if you haven’t noticed it. If we didn’t have this race condition, our changeling history would be full of weird conflicts. There should be no race condition because our GitHub repo should only allow fast-forward commits. A server hook can ensure the commit identifiers are sequential. Right? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Transition to Git
I suppose what I'm describing is Konstantin's Workflow 2, which is overwhelmingly popular. On Tue, Oct 13, 2020 at 2:19 pm, Ryosuke Niwa wrote: Not squashing only helps if each commit can stand on its own. At that point, I'd suggest such a sequence of commits be made into multiple PRs instead of multiple commits in a single PR, each of which requires a separate code review. Commits are certainly expected to stand on their own (not introduce defects). If they can't, then they should be combined into another commit! Hence, we should not approve MRs if the MR contains commits that fail to meet our usual standards. Such commits should just fail code review. (But if you aren't willing to review MRs commit-by-commit, then indeed you'll never notice when such problems exist.) If I have to open a separate MR for each change, though, I'm going to wind up combining multiple lightly-related changes into one big commit, because a new MR for every tiny cleanup I want to make requires effort. Such commits may be common in WebKit, but they would fail code review in most other open source projects. E.g. in https://trac.webkit.org/changeset/268394/webkit I snuck in a drive-by one-line fix that's unrelated to the rest of the commit. I would rarely dare to do that outside WebKit, knowing it would probably fail review, but we do it commonly in WebKit because we discourage multiple patches per bug and don't want to create new bugs for every small cleanup. This to me is a show stopper. When I'm trying to bisect an issue, etc..., the biggest obstacle I face is any intermediate revisions where builds are broken or otherwise non-functional. I don't think we should let anyone merge a commit into the main branch unless the commit meets the same standards as a regular Bugzilla patch we land today. I agree. But I would say that a MR with such history should fail review, and be rewritten to not suffer from these problems. I disagree. Detailed descriptions and function-level change logs are exactly what I use to dig up all the code history and figure out what's causing the bug and how to fix in numerous occasions. Not having that would be a massive regression. - R. Niwa Detailed descriptions are very important. I don't think function-level changelogs are; documenting changes in individual functions is generally busywork to say what you can plainly see by just looking at the diff. I'll submit https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1686/commits as an example of my preferred commit granularity and verbosity. (We can pretend it is not currently failing CI. ;) Here the commits are lightly-related and could perhaps be split into multiple MRs, but honestly that becomes annoying and unwieldy, especially as some of the commits depend on each other and need to land in a particular order, and since creating new branches and MRs (or bugs on Bugzilla) for each commit becomes annoying. So it's nicer to do it all in one. One of these commits actually makes changes that are undone by a subsequent commit, and is primarily there just so that I could write a commit message about it and show the history in two steps rather than one! History like that would be lost in Konstantin's Workflow 1. I don't think ChangeLog-style function-level detail would be helpful in any of them; in WebKit, I usually ignore that anyway. But all of the commits do have a detailed commit message, except for "fix typo" and "fix whitespace" (can't expect an essay for those). Regarding line-by-line commit review... well, it would be nice to have, of course. But I don't think it's as important as you suggest. Problems with commit messages are usually general problems with the entire commit message rather than problems with a specific line of the commit message. An exception is typos. It is harder to point out typos without a line-by-line review tool. But still, it's not too hard to tell somebody to fix a typo without being able to highlight the right line. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Transition to Git
On Tue, Oct 13, 2020 at 12:32 pm, Maciej Stachowiak wrote: I’m assuming your objection is to regular merges, but how do you feel about squash merges? Or do you think all PRs should be landed by rebasing? If we want a linear history (we do), all PRs ultimately have to land as fast-forward merges, one way or the other. I think rebasing is the simplest way to accomplish that, but squashes work too if all your changes are sufficiently self-contained to land as one commit. I suggest leaving this up to the discretion of the developer and reviewer rather than mandating one way or the other, because there are advantages and disadvantages to both approaches. If your local commit history is a mess, sometimes squashing it all into one commit is an easy way to make it acceptable for upstream. If you hate rewriting history to make it look good, and your MR isn't too huge, a squash might be appropriate. But more often than not, I'd say that would result in a worse commit history. My own preference would be to require squash merge, because it keeps the history simple for the main branch, but does not risk putting intermediate revisions which may work or even build on the main branch. The disadvantage is that if you squash before merging, you encourage fewer, bigger commits that might be harder to read and potentially much less fun to discover at the end of a bisect. E.g. consider a very common case: developer wants to fix a handful of separate but related bugs in a particular section of code. We could land all the fixes in one huge commit, but that's inevitably going to be harder to read, harder to deal with if it introduces a regression, and will certainly have a more confusing commit message (either because it gives less detail about the changes, or because it's very long describing multiple related changes that could have been separate commits). We could split it up into different MRs for the different commits, but that becomes annoying when the commits are related, and hard to keep the different MRs in order. So I don't normally squash (except when committing small fixup commits via the web UI), because the disadvantages generally outweigh the benefits. On the other hand, if you don't squash, it's indeed possible that your commit history might be messy, e.g. intermediate commits might break tests fixed by subsequent commits, or intermediate commits might not build at all. Squashing before merging does eliminate those risks, but I recommend code review instead: commit history and style is subject to review just like code changes are. Sometimes I see a merge request with a messy commit history that just begs for two or more commits to be squashed together. (This is common for students new to open source. WebKit does not have this problem currently.) Sometimes I see the opposite, where too many changes are bundled into one big commit. (This is more common in WebKit, since we normally try to have one patch per bug, and splitting changes into multiple bugs is inconvenient.) But usually the developer submitting a MR has found a good balance between the two extremes. Ultimately, what's most important is landing a clean commit history with reviewable commits. Again, the scope of commits is subject to review just like code changes are. I agree that we don't want to merge WIP commits of any form, and reviewers should complain if these appear in a MR. E.g. if making an API change that requires updates in 200 files, we surely want them all updated in one commit, because we don't want broken intermediate commits on master that would break bisections. So sometimes huge commits are unavoidable. Similarly, if an intermediate commit is known to break a test, that's not good either because it could mess up bisects. (I don't think we necessarily need to run tests on every intermediate commit -- that might be too much for our infrastructure -- but we could if desired.) What we don't want is to wind up merging low-quality stream-of-consciousness style commits that looks like they were committed in the order the code was written. I think that's what you're trying to avoid by suggesting squashes. Instead, I suggest developers should aggressively use 'git add -p' and 'git rebase -i' to selectively commit, rewrite, and reorder history to look good before opening the MR. This isn't optional for most open source projects: if you propose an MR with ugly commit history, it won't be merged until fixed. For a typical MR of moderate complexity, I'll use 'git rebase -i' at least a couple times before the history is clean enough for a MR, and to make fixup commits disappear into the most-appropriate commit in the sequence. Regarding commit messages, I don't understand why there's any expectation that they need to be checked into files in order to be detailed and complete. If a commit message doesn't adequately describe what it's fixing, then the reviewer should open a
Re: [webkit-dev] WebKit Transition to Git
On Wed, Oct 7, 2020 at 4:17 am, Konstantin Tokarev wrote: BTW, could you estimate how many of users which have provided meaningful bug reports were directed to bugs.webkit.org but never made it? A lot. I'd say maybe about half make it upstream. That's OK. We don't have time to fix everything, after all, and it doesn't make sense to focus on bug reports where we cannot easily interact with the reporter. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Transition to Git
On Wed, Oct 7, 2020 at 2:22 am, Tetsuharu OHZEKI wrote: If we move to GitHub Issue, compared to bugzilla, that does not have "component watching". (I don't know the case of GitLab's Issue) We only can watch all issues or not for the repository. Oh dear. I had assumed that you could easily subscribe to particular labels (as you can in GitLab) but, poking around in GitHub's UI, I indeed don't see any way to do that. :/ That's no good. E.g. multimedia developers expect to be able to subscribe only to multimedia bugs, WebKitGTK developers will want to watch only GTK bugs, etc. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Transition to Git
On Tue, Oct 6, 2020 at 3:13 am, Konstantin Tokarev wrote: 1. Sub-par support for linking issues to each other Traditional bug tracking systems (like Bugzilla or JIRA) have support of "related" or "linked" issues. Most important relations are * A depends on B (B blocks A) - blockers and umbrella issues * B is duplicate of A * A and B are related in other unspecified way GitHub does have duplicates btw, but the syntax is completely different from GitLab so I can never remember how it's done. It's not exposed in the UI. In GitLab it's easy: /duplicate #245 to mark a bug as duplicate of issue #245. (You can have cross-repo duplicates too, and I think even cross-*project* duplicates. This is very important for GNOME, but not for WebKit since WebKit is just one huge repo.) I found instructions for GitHub here: https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/about-duplicate-issues-and-pull-requests#marking-duplicates * There is no easily visible list of relations: if you are not closely following all activity on A, to find all issues related to it you have to browse through all its (pseudo-)comments, which in some cases might be long. * There is no *stateful* list of relations: if A was believed to have common source with B, but then it was discovered they are not related, you cannot delete relationship between A and B because there is no relationship, just a set of comments. In my experience, this isn't really a *huge* problem. Umbrella issues work well enough to track relationship between bugs, as do milestones, and you can use whichever you prefer. I admit it is not nearly as nice as Depends/Blocks from Bugzilla, though. But I think it should be good enough for us. * "#" is not a safe reference format. Sometimes users' comments may have other data in "#" format with a different meaning than references to GitHub issues. For example, may the force be with you if someone pastes gdb or lldb backtrace into comment without escaping it into markdown raw text block (```). Also, GitHub parses mentions in git commit messages, so care must be taken to avoid any occurrences of "#" with a meaning different from reference to issue number. Yeah this is unfortunate and also guaranteed to happen. The first several dozen issues are going to be spammed with references to other bugs all over the place. [2] For some reason they have shared numbering, which means sometimes you may not know what kind of reference is in front of you until you look up its URL or navigate This is silly too (and not a problem on GitLab, which uses # for issues and ! for merge requests). But although I agree it is a defect, is it really a huge problem? Probably not. Also, on test cases. You probably like this feature of Bugzilla when you can attach self-contained HTML file to the issue and then simply open it by URL in any browser including your build of WebKit to try it out. Forget this - GitHub simply forbids HTML or JS attachments (without wrapping them in archive): "We don’t support that file type. with a GIF, JPEG, JPG, PNG, DOCX, GZ, LOG, PDF, PPTX, TXT, XLSX or ZIP." And yes, take care not to use tar.xz or tar.bz2 or any other unapproved archive type. OK, now you've convinced me... this is bad. :P I forgot about this problem because GitLab does not have any such restrictions on attachments. It's very frustrating to have to say "I added a .txt file extension so I could upload this to GitHub. Please remove the file extension after you have downloaded the file before you use it." I would say this is strongest argument I've seen against GitHub. Silly problem to have tbh. I'll just add that GitLab has become *really* popular for Linux-related projects. I have to regularly work with GNOME GitLab, freedesktop GitLab, and gitlab.com. Fedora and CentOS are both switching to GitLab too, so soon that will be five different public GitLab instances that I have to switch between regularly, and that's limited to only the public instances. Then there are also many major communities I don't work with that are also using GitLab (KDE, Debian, Purism). It's reached the point where unless you only work on Linux kernel itself, you probably spend a lot of time on one GitLab or another. It should be considered alongside GitHub as an option, especially if we're concerned about GitHub-specific problems. And when issues are triaged, they can be resubmitted to WebKit tracker by qualified person if they are really relevant. In practice, I don't think it's a good idea because (a) moving bugs upstream takes a lot of time, (b) it's quite often important to have the original reporter CCed on the issue and able to comment. I receive tons of WebKit bugs in the Epiphany bugtracker, and while a few years ago I might have forwarded reports upstream myself, nowadays I only provide
Re: [webkit-dev] WebKit Transition to Git
On Mon, Oct 5, 2020 at 8:40 am, Jonathan Bedard wrote: That's one solution, but even that is somewhat insufficient because we don’t want to give someone access to every security issue just to give access to a single one. One of the solutions we’ve discussed is to migrate bugs component by component, the security component may stay on bugzilla indefinitely. Can you grant access to a single issue by CCing the desired user to the issue? I expect that would work (not tested). ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Transition to Git
On Sat, Oct 3, 2020 at 9:52 pm, Konstantin Tokarev wrote: If I understand correctly, there is no way in GitHub UI to see a difference between patches submitted at step 1 and step 3. It's still possible to see old version of patches if you navigate to old commit hash, but that's not for long as they can be garbage collected by GitHub because they don't belong to git branch anymore. If we are really seriously concerned about this... it's not a problem with GitLab. At least, I can still view diffs between different revisions of merge requests from two years ago, and the changes seem to be stored forever. At least I still can view diffs from years ago. E.g.: https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/62/diffs?diff_id=27669_sha=0c020384b602c9e1f0e8ec9e491d1951e8feadf7 Unfortunately it's sometimes less useful than I might have hoped, because rebases bring in a bunch of totally unrelated changes, e.g.: https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/62/diffs?diff_id=28036_sha=043b5fc32f4f9263d393c9de83e1b33123c5 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Transition to Git
On Sat, Oct 3, 2020 at 3:16 am, Ryosuke Niwa wrote: I've gotta say I'm very much concerned about getting rid of change logs when we move to Git. We put a lot of useful information about what was causing the bug, how we fixed it, and why we fixed the way we did in a change log. I've seen a few projects which transitioned to Git and somehow lost the rigor in maintaining an equally high quality commit message, partly because most code review tools don't let you add inline comments to commit messages. You may not be able to add inline comments on commit messages, but I've never been particularly concerned about that. You can still start a new discussion thread mentioning the problem with the commit message that you'd like to see resolved, blocking merge until the discussion thread is resolved. Although in GNOME we don't often have problems with low-quality commit messages, we do sometimes, and during review we treat that as we would any problem with the code. Having a set of guidelines for writing commit messages, like [1], might help. But yes, we do lose the ability to do inline comments during code review. (Anyway, this is only a tangent, since of course we can switch to GitHub but still keep ChangeLog files if we decided to do that.) [1] https://wiki.gnome.org/Git/CommitMessages ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Transition to Git
On Fri, Oct 2, 2020 at 09:43, Jonathan Bedard wrote: The biggest blocker we are aware of is managing security bugs, since the security advisory system used by GitHub is essentially the opposite of how WebKit security bugs work. Moving to GitHub Issues, if it happens, will be the last part of this transition, and we are interested in soliciting feedback from our contributors on what the WebKit project’s integration with GitHub Issues should look like. I don't think we need much integration to use the issue tracker? Once we migrate existing bugs from WebKit Bugzilla, we can use it as we would any other issue tracker? Why would it require integration? We might need to use a separate repository with more limited permissions to handle security reports. At least in GitLab, all project developers (committers) have access to all confidential issues. I'm not sure about GitHub, but I assume it would be the same. What will require integration is pull request merges. If we want to maintain linear version history, we will want a merge bot. On GNOME GitLab, we have a large number of smaller projects and it's we don't need them, but for a one huge project like WebKit there will be too many conflicts otherwise, because every commit going into the main branch will require all other pull requests to be rebased. A merge bot -- e.g. [1] -- will handle that for us. (Not sure what merge bots are common on GitHub. ) Michael [1] https://gitlab.com/fsdk-marge-bot ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Transition to Git
On Fri, Oct 2, 2020 at 13:48, Ken Russell wrote: Github's code review UI has a couple of feature gaps in my opinion. It's difficult to look at earlier versions of the pull request, in particular to verify that issues found during code review have been fixed. I remember it also being difficult to figure out whether all comments on earlier versions have been addressed. I'm not familiar with reviews on GitHub. I just want to add that GitLab reviews are great and have none of these problems. It's very easy to view older versions of merge requests and compare the differences between arbitrary revisions of the merge request. (That's often important when reviewing small changes to a large merge request.) Every discussion thread is clearly marked as either resolved (green!) or unresolved, and you can (and should) configure GitLab to block merges until all discussions are resolved. (I would be disappointed if GitHub doesn't have the same convenience features, as this helps prevent mistakes from being forgotten.) I realize that Gerrit might not integrate at all with hosting the repo on Github, but has any thought been given to this aspect of the transition? That sounds like it would be a significant barrier to contribution, and frankly defeat the point of switching. If we have serious concerns with GitHub's code review functionality (which, again, I'm not familiar with), then we should just use GitLab and have everything in one place. (GitLab accepts GitHub logins via OAuth, both on gitlab.com and self-hosted instances, so the barrier to contributing remains low either way.) Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Issue reports, merge requests, etc. (was: WebKit Transition to Git)
On Fri, Oct 2, 2020 at 11:51 am, Ryosuke Niwa wrote: Since Igalia has a lot more experience working with other open source projects, do you have some suggestions in how to approach that? Sorry for a long-ish mail. I didn't mean for this to turn into an essay. Too late. :P I actually moved to Red Hat, but anyway, I would say first step is to ensure every incoming issue is triaged, at least once when initially reported, and every merge request given at least cursory review within a reasonable amount of time. That's how open source projects attract and retain community contributors, and it's been a weakness for WebKit for a while (we're not the worst at this, but certainly not good at it either). One possible answer for this is to have a "project manager" or similar role to triage and prioritize issues, but of course it can also be done by developers working together (possibly according to some rotation). WebKit is such a big project that I suspect almost nobody has enough expertise to triage all incoming bugs, but most of us have enough expertise to figure out which issue labels to apply to an incoming bug to pass the issue off to more specialized experts. On GNOME GitLab we label incoming issues with Bug, Crash, Enhancement, or Feature (the difference between Enhancement and Feature is hazy) and have a variety of global and per-project labels that can also be applied to issues [1]. The list of current components in WebKit Bugzilla would be a good starting point to use here. Every new issue gets reviewed and either gets closed or else gets a label applied to indicate it has been triaged, usually within one business day. If an issue is open and doesn't have any labels, we know it has not been triaged. A lot of bugs can be closed immediately because they're reported in the wrong place, for instance. Most crashes are reported without a backtrace; to those, we attach a Needs Information label and point the reporter to instructions for getting a backtrace with gdb, and close after a few days if not provided. The details don't matter so much as the fact that the issue has received minimal human attention. In the rare cases where a bug report is perfect and all I need to do is add issue labels, I give the issue an upvote to indicate I've seen it, so the reporter knows it hasn't been *completely* ignored, even if nobody fixes it. The details don't matter so much as that contributors and issue reporters feel like they've received at least some attention and aren't shouting into a bug wasteland. Then developers subscribe to project-specific labels in accordance with their expertise and tolerance for mail. E.g. I watch all issues for some projects, but for GLib I'm only subscribed to networking-related labels, since problems in the network-related code often impact WebKit. Some developers will want to watch only for CSS bugs, only layout bugs, only JSC bugs, only WebKitGTK bugs, etc. Of course, triaging issues doesn't mean they actually get fixed, but it's a necessary first step. (And once isn't really enough, either. Most of our bugs from 2008 are probably no longer valid, but it takes time to review old bugs, and not many people have enough specialized technical expertise to triage outside their area of expertise. Anyway, once is a starting point.) Responding to merge requests (or patch reviews) in a timely manner is also important (otherwise, contributors disappear). Merge requests take longer than issues, but it's good to get to each one within a couple days; otherwise, they really start to pile up. We currently have patches awaiting review from 2017 [2], and that's just the last time somebody decided to mass-deny old review requests. And a lot of these are from Apple/Igalia/Sony, who all know who to CC for reviews; imagine how much harder it is for someone not familiar with the WebKit community to get a patch reviewed. ;) GitHub will probably help with this because it puts merge requests front-and-center in its UI, instead of requiring us to first discover then take the time to sort through the request queue. It's hard to use GitHub without habitually reviewing pending requests. ;) The number of open issues and MRs is even clearly displayed as a sort of challenge to reduce the number. But we'd need some workflow for directing merge requests to appropriate reviewers. When we move to GitHub, you can expect to start receiving merge requests from people who would not take the time and effort to create a WebKit Bugzilla account and learn how to use our arcane ChangeLog and patch creation scripts. Epiphany has twice as many active contributors and probably 3-4x more activity today on GNOME GitLab than it did when we used GNOME Bugzilla, and I'm pretty sure that's mainly due to GitLab rather than other factors. I wouldn't expect that dramatic a change for WebKit, since most WebKit contributors are professional rather than volunteer
Re: [webkit-dev] WebKit Transition to Git
On Fri, Oct 2, 2020 at 6:36 pm, Philippe Normand wrote: Would you also consider preventing merge commits in order to keep a clean mainline branch? Big +1 to blocking merge commits. Merge commits in a huge project like WebKit would make commit archaeology very frustrating. (I assume this is implied by the monotonic commit identifiers proposal, but it doesn't exactly say that.) I'm sure transition to git and GitHub should go well. I would have selected GitLab myself -- it's nicer and also overwhelmingly popular -- but whatever. (Does GitHub have merge request approvals? Replicating our reviewer/owner permissions with GitLab merge request approvals would be easy.) One downside is that using github.com might actually make it *too* easy to spam us with low-quality issue reports and merge requests. We've historically been pretty bad at maintaining a clean issue tracker -- the quantity of untriaged issues on Bugzilla is very high -- and GitHub will make this worse. That's not an issue with the GitHub platform, though. Just something to stay on top of. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Question: referrerpolicy in Safari
On Wed, Sep 23, 2020 at 1:50 pm, Dominic Farolino wrote: I haven't dug too deep here, but just going to post this in case it answers your question and saves you some time. As documented here, it appears that Safari is starting to not honor the `referrerpolicy` attribute on HTML elements where it would override the referrer policy redaction that their cross-site tracking work has performed, or at least in cases where it would expose more information than what was intended by the cross-site tracking protection. That may be an oversimplification, (I trust someone from WebKit can clarify), but it may explain the behavior you are seeing. That probably explains case 1. There's some documentation of this at https://webkit.org/tracking-prevention/. The actual URLs matter here. With https://site-one.example/path/foo and https://site-two.example/, the top privately-controlled domains are different (site-one.example vs. site-two.example) so the referrer will be downgraded to its origin. But say you were instead testing https://site-one.example.com/path/foo and https://site-two.example.com/, then the top privately-controlled domain in both cases is example.com, and there's no forced downgrade. That doesn't explain what's going on in case 2 or case 3, though. Smells like bugs? Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Generating compile_commands.json when building WebKit on MacOS
On Wed, Jul 22, 2020 at 11:15 am, shriva...@firemail.cc wrote: DerivedSources/ForwardingHeaders/JavaScriptCore/JSContext.h:40:1: error: duplicate interface definition for class 'JSContext' @interface JSContext : NSObject ^ ../../Source/JavaScriptCore/API/JSContext.h:40:12: note: previous definition is here @interface JSContext : NSObject ^ Your assistance would be much appreciated. It might be time to simply remove support for building WebKitGTK on macOS. I imagine it's been many years since anyone has successfully built it. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Plugin process
On Mon, Jul 20, 2020 at 9:35 am, Michael Catanzaro wrote: For now, I'll submit a patch to deprecate these settings without changing behavior yet. Meh, I did this, but realized that it's easier to write deprecation messages when we remove support for the feature at the same time that it's deprecated. That is, if we wait until after branching to deprecate, we can write: Deprecated: 2.32: NPAPI browser plugins are insecure and no longer supported. Rather than: Deprecated: 2.30: NPAPI browser plugins are insecure and will no longer be supported in 2.32. And then later changing it to: Deprecated: 2.30: NPAPI browser plugins are insecure and no longer supported since 2.32. So let's wait until branching. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Plugin process
On Mon, Jul 20, 2020 at 11:47 am, Adrian Perez de Castro wrote: Our tentative plan for sunsetting the NPAPI support is to keep supporting the GTK3 plugin process in the next stable release series. This means that we could remove the support from trunk after creating the stable branch for the 2.30.x releases—that would be around September-October 2020. Well branching normally occurs in August... just a few weeks away now. Then we can make the plugin process specific to PLATFORM(COCOA), until Apple figures out if it can be removed, and we can delete the support for all other platforms. For now, I'll submit a patch to deprecate these settings without changing behavior yet. I think we would need to make the public API to toggle the support for plugins a no-op and log a warning to avoid breaking applications. Well a warning certainly doesn't hurt. I suspect no applications are using it, though. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Plugin process
Hi, Is anybody still using the plugin process? I understand that Safari does not allow plugins anymore. Epiphany doesn't either, nor does anything packaged in Linux distros (afaik). If nothing is using it, maybe we can delete a lot of code? Is it exposed in Apple system APIs? WebKitGTK still has an enable-plugins setting that is not yet deprecated. Probably long past time to at least deprecate it. There's also, incredibly, an enable-java setting, which I presume toggles the old Java browser plugin. I sense there must be some history behind that setting. :) ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] [webkit-changes] [264332] trunk/Source
On Thu, Jul 16, 2020 at 4:14 pm, Darin Adler wrote: Let’s stop doing it that way. Just compile the files and have #if inside the file. I removed all conditional source files from the Xcode build system. Let's do the same for the CMake build system. — Darin I agree we should do this. We've never been consistent between whether we guard files at the build system level or inside the files themselves. But with unified builds, the advantage of putting the guards inside the files is clear: we would ensure that the set of files compiled is always the same for a given port regardless of which options are used. I wouldn't use that as a reason to drop non-unified builds, though. E.g. Yusuke's argument regarding compile_commands.json seems pretty compelling. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Position on User-Agent Client Hints
My personal $0.02: I'm mildly supportive of this spec. It's certainly an improvement on existing HTTP user agent headers. I appreciate that you worked to incorporate feedback into the spec and considered the concerns of small browsers. Is it going to solve all the problems caused by user agent headers? No. If WebKit implements the spec, we're surely going to eventually need a quirks list for user agent client hints to decide which websites to lie to, just like we already have quirks for the user agent header. And as long as Chrome sends a user agent header that includes the string "Chrome", it's unlikely we'll be able to get rid of the existing quirks list. But I think client hints will probably reduce the amount of websites that *accidentally* break WebKit, by replacing wild west UA header parsing with well-defined APIs, and adding some GREASE for good measure. The promise of freezing Chrome's UA header sounds nice, as it makes quirks easier to maintain. And being able to ration entropy by revealing details about the platform on an active rather than passive basis is quite appealing. The spec attracted some misplaced concern about negative impact to small browsers, which I've rebutted in [1]. I'm not quite so enthusiastic about this spec as I was initially, especially after I was convinced that the GREASE is never going to be enough to remove our quirks list, but it's certainly not going to *hurt* small browsers. This spec has received some pretty harsh criticism from the user tracking industry (some call it the "ad industry"). Not historically a friend of WebKit, so sounds good to me. ;) One concern I haven't mentioned elsewhere is that frozen UA header might encourage deeper levels of fingerprinting than are currently used, e.g. for ad fraud prevention. caddy has started blocking WebKitGTK users based on TLS handshake fingerprint (yes, really!) [1]. If techniques like that take off as a result of this, that could potentially backfire on us quite badly. But websites could choose to do such things today anyway, client hints or no, and if so, the solution will be for us to just try even harder to look more like Chrome. Seems like a net positive overall. I don't work for Apple and can't say whether it might be implemented by WebKit. Michael [1] https://github.com/w3ctag/design-reviews/issues/467#issuecomment-583104002 [2] https://mitm.watch/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
