Re: [webkit-dev] Site isolation platform code
On Wed, May 8 2024 at 02:32:46 PM -07:00:00, Alex Christensen via webkit-dev wrote: 1. createNewPage in WebKitUIClient.cpp needs some hooking up of the API::PageConfiguration in a way I couldn’t figure out in the few minutes I looked at it. This should be pretty straightforward to someone who knows the glib code better than I do. Created https://bugs.webkit.org/show_bug.cgi?id=273975 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Lost docs!
On Wed, Apr 3 2024 at 09:47:05 PM -05:00:00, Brandon Stewart wrote: I did copy the documentation over a year ago, but anything added there since then would be missing on docs.webkit.org. Perhaps we should just turn off the wiki to prevent more stuff from being added by mistake? Anybody still need the GitHub wiki? It's really best to have just one place for our docs. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] ASSERT vs. RELEASE_ASSERT
Hi, Just brainstorming, but I generally think it's worth enabling way more assertions in production builds to the extent we can do so without unacceptable performance impact. My ideal would be to rename ASSERT() to SLOW_ASSERT() and then rename RELEASE_ASSERT() to ASSERT(), to make release asserts the "default" type of assert. But I'm not ambitious enough to attempt that. Notably, this would in many cases downgrade the severity of security bugs, since hitting a RELEASE_ASSERT() is at worst a denial of service issue. Curious what other WebKit developers think about this. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Lost docs!
Hi, I've noticed we have a bunch of documentation on https://github.com/WebKit/WebKit/wiki that has not been migrated to https://docs.webkit.org/index.html. Some of the documentation looks pretty important, e.g. [1]. In the case of this specific page, we can probably just copy/paste it onto the bottom of [2] or similiar; it's easy to move since it's Markdown in either place. We should think about what to do with the other pages, though. Michael [1] https://github.com/WebKit/WebKit/wiki/Smart-Pointer-Usage-Guidelines [2] https://docs.webkit.org/Deep%20Dive/MemoryManagement.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] webkit-unassigned
On Mon, Dec 18 2023 at 09:58:14 PM +00:00:00, Alexey Proskuryakov wrote: Are you thinking of scraping Bugzilla? No plans to further limit public access at all (we do have some rate limiting already though, to protect service availability). I don't think that "it's in principle possible to notice a misplaced comment" is equivalent to "let's maintain a way to have every misplaced comment delivered to the mailbox of anyone who cares to collect those". Not me personally. Or if there is a similar way to follow all public activity that irreversibly emails everything out, then I don't know about it. Hm, maybe not. I assumed there was, but can't find settings for it in Bugzilla. Maybe I was wrong. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] webkit-unassigned
On Mon, Dec 18 2023 at 09:16:21 PM +00:00:00, Alexey Proskuryakov wrote: Same thing - limiting the ability to trivially watch for security bugs that are initially filed in a wrong component, You can currently follow all public activity on the Bugzilla. Are you planning to limit that too? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] webkit-unassigned
On Mon, Dec 18 2023 at 06:07:48 PM +00:00:00, Alexey Proskuryakov via webkit-dev wrote: I'm still inclined to break the scenario of watching webkit-unassigned. What do others think? I don't think there's any need to disable the ability to watch the Bugzilla account? It shouldn't give anybody access to anything they don't already have permission to see, so what's the point? Turning off the public mailing list seems good. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Approving / Rejects PRs on GitHub when not a reviewer?
On Tue, Nov 28 2023 at 01:23:12 PM -0800, Chris Dumez via webkit-dev wrote: I’m on board if it also cancels PR rejections from non-reviewers, not just approvals. I don’t see how approvals differ from rejections. Sure. It doesn't really matter whether rejections are canceled or not, because the important part of the rejection is the comments that were added, not the rejection status itself. A rejection from a non-reviewer is not effective anyway, so it's fine to have a bot clarify that. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Web Authn support for webkitgtk
Hi, We've hired a contractor to work on this as part of: https://foundation.gnome.org/2023/11/09/gnome-recognized-as-public-interest-infrastructure/ However no work has started yet. The first step will be to get a working portal: https://github.com/flatpak/xdg-desktop-portal/issues/989 (Without a portal, WebKit would have to use libfido2 directly, which will be blocked by WebKit's bubblewrap sandbox or the flatpak sandbox. So there is no point to attempting that approach; it has to go via a portal.) The portal might be a good place to start helping since it doesn't require modifying WebKit and we don't have a clear sense of direction regarding the portal yet. We need to figure out what the D-Bus API for the portal should look like. There is a "downstream" or experimental project xdg-credentials-portal that we might want to use as a basis, but we don't know exactly how. So commenting in that issue and trying to build consensus on what the API should look like could be a good way to push this forward. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Removal of trailing whitespace
On Thu, Apr 13 2023 at 08:15:00 AM +0900, Tetsuharu Ohzeki via webkit-dev wrote: To digress a little, why does webkit now use a style checker based on python script instead of clang-format? In today, I feel it's more reasonable to use such a formetter. We've tried clang-format in several GNOME projects with not great results. I'd recommend uncrustify instead. Still, I'm not sure it's a good idea for WebKit. I'm sure we could make either tool work, but we'd have to be very lax with any configuration we use, or it could get pretty annoying. And the existing style checker works decently enough. ___ 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 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
