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
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
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:
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
___
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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,
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
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
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
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
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
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'.
Thanks very much Ken!
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
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
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
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
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.
*
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
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
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
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
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
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
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
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?
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
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
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
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. :)
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
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.
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
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.
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
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:
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.
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
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
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
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?
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
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
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
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
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
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
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
90 matches
Mail list logo
