Re: [webkit-dev] Proposal to enable logging under non-systemd linux distros

2021-10-19 Thread Michael Catanzaro via webkit-dev
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

2021-10-19 Thread Michael Catanzaro via webkit-dev
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

2021-10-19 Thread Michael Catanzaro via webkit-dev

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

2021-08-30 Thread Michael Catanzaro via webkit-dev



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

2021-08-30 Thread Michael Catanzaro via webkit-dev



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

2021-08-20 Thread Michael Catanzaro via webkit-dev
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

2021-08-20 Thread Michael Catanzaro via webkit-dev
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

2021-08-14 Thread Michael Catanzaro via webkit-dev



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)

2021-08-13 Thread Michael Catanzaro via webkit-dev
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

2021-06-15 Thread Michael Catanzaro via webkit-dev



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?

2021-05-25 Thread Michael Catanzaro via webkit-dev
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?

2021-05-25 Thread Michael Catanzaro via webkit-dev
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?

2021-05-25 Thread Michael Catanzaro via webkit-dev
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?

2021-05-24 Thread Michael Catanzaro via webkit-dev
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?

2021-05-24 Thread Michael Catanzaro via webkit-dev

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?

2021-05-05 Thread Michael Catanzaro via webkit-dev



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

2021-05-04 Thread Michael Catanzaro via webkit-dev
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

2021-04-28 Thread Michael Catanzaro via webkit-dev
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

2021-04-28 Thread Michael Catanzaro via webkit-dev



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

2021-04-28 Thread Michael Catanzaro via webkit-dev
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?

2021-04-08 Thread Michael Catanzaro via webkit-dev
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?

2021-04-08 Thread Michael Catanzaro via webkit-dev
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

2020-11-30 Thread Michael Catanzaro via webkit-dev
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

2020-11-17 Thread Michael Catanzaro via webkit-dev
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

2020-11-17 Thread Michael Catanzaro via webkit-dev
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

2020-11-17 Thread Michael Catanzaro via webkit-dev



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

2020-11-17 Thread Michael Catanzaro via webkit-dev

Hi,

Today I received a Google Developers email with subject "[Action 
Required] Starting January 4, 2021, we will block all sign-ins to 
Google accounts from embedded browser frameworks." It linked to this 
Google blog post:


https://developers.googleblog.com/2020/08/guidance-for-our-effort-to-block-less-secure-browser-and-apps.html

Summary: Google will attempt to block logins from "CEF-based apps and 
other non-supported browsers." Presumably "non-supported browsers" 
likely includes non-Safari WebKit, considering how much time I spend 
trying to develop user agent quirks to suppress Google's unsupported 
browser warnings on Gmail, Google Docs, etc. I guess we will find out 
on January 4.


Google says: "The browser must identify itself clearly in the 
User-Agent. The browser must not try to impersonate another browser 
like Chrome or Firefox." We cannot comply with this because user agent 
spoofing is required for compatibility with various Google websites. I 
am continually fighting to maintain our user agent quirks for Google 
domains, see e.g. [1] or [2]. Even if we were to remove all user agent 
quirks, it would still be impossible for Google to distinguish between 
a desktop browser and an embedded browser framework, since the user 
agent header is going to be the same: Epiphany doesn't even append 
"Epiphany" anymore, in order to maximize the chances that websites will 
treat us like Safari. Even if we did, there are many other WebKit-based 
browsers that would be impacted (off the top of my head: eolie, surf, 
etc.)


So we'll see what happens on January 4. If our users get locked out of 
google.com, I'll try to come up with new quirks if possible, but if 
Google is really determined to block non-Safari WebKit, it will win. 
E.g. it's easy to do JS feature detection (scary) or TLS handshake 
fingerprinting (extremely scary) and see we are not really the browser 
that our user agent quirk claims to be. We are largely toothless here, 
unfortunately. If Google continues to discriminate solely on the basis 
of the user agent header, and doesn't adopt any more advanced 
discrimination mechanisms, then we will survive, although it would help 
if Apple is willing to take a hard stance and adopt the same set of 
cross-platform quirks in Safari, which would "work" by causing Safari 
to break in the same way as non-Safari WebKit... probably not very 
palatable, but if adopted well in advance of this Jan 4 flag date, it 
would at least make it *harder* for Google to hurt non-Safari WebKit. 
(Adopting the quirks *after* the flag date would likely just 
immediately break Safari.)


But if Google does this properly and uses more sophisticated browser 
fingerprinting techniques, Epiphany is done for. This could be an 
existential threat for non-Safari WebKit browsers. Nobody is going to 
be interested in using a browser that doesn't support Google websites. 
Google's expressly-stated goal is to block embedded browser frameworks 
and non-supported browsers from signing into Google accounts. The blog 
post says: "This block affects CEF-based apps and other non-supported 
browsers." It says: "We do not allow sign-in from browsers based on 
frameworks like CEF or Embedded Internet Explorer." Clearly CEF is the 
main target, but I guess WebKit (and likely also QtWebEngine) is at 
risk too; even if we're not mentioned directly, it seems pretty clear 
that WebKitGTK, WPE, PlayStation and WinCairo ports, etc. are all 
likely non-grata.


So what should WebKit do about this? I don't know. Nothing has happened 
yet, so I guess we could wait and see what happens on January 4. Maybe 
this won't affect us at all. But my fear is that January 4 will arrive, 
we will be blocked, and more user agent quirks may or may not work. 
Even if WebKit is not blocked, we can be confident January 4 will be a 
sad day for browser diversity. I wonder if this is something that 
WebKit as a project could push back against... somehow. Maybe publish a 
statement supporting browsers based on embedded frameworks (WebKit, 
CEF, QtWebEngine)? Or some new WebKit project policy? Any suggestions?


Michael

[1] 
https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/platform/UserAgentQuirks.cpp?rev=269908

[2] https://bugs.webkit.org/show_bug.cgi?id=215845


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


Re: [webkit-dev] Embedding Identifiers in Commit Messages

2020-11-11 Thread Michael Catanzaro
On Wed, Nov 4, 2020 at 11:51 am, Jonathan Bedard  
wrote:
We don’t have post commit hooks in SVN to do this sort of thing, 
and I don’t intend to add them now. We are going to have a system 
on GitHub to do this (not post commit hooks, but I won’t dive into 
the details here).


There really aren’t a lot of people who land changes outside of 
webkit-patch, among things that would break if folks were regularly 
not using webkit-patch is trac.webkit.org, which relies on the commit 
message being set.


Probably not often on trunk. But on stable branches, I assume 100% of 
changes are landed without webkit-patch? At least, I always used 'git 
svn dcommit' on stable branches. I also used this on trunk when I 
needed to fix an error in a ChangeLog (something webkit-patch is not 
good at doing).


Lastly, this doesn’t add a race-condition that wasn’t already 
there. One of the downsides of SVN is that, unlike git, it is a 
centralized version control system, so clients must be synced to 
upstream before committing. This is true now, even if you haven’t 
noticed it. If we didn’t have this race condition, our changeling 
history would be full of weird conflicts.


There should be no race condition because our GitHub repo should only 
allow fast-forward commits. A server hook can ensure the commit 
identifiers are sequential. Right?



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


Re: [webkit-dev] WebKit Transition to Git

2020-10-13 Thread Michael Catanzaro



I suppose what I'm describing is Konstantin's Workflow 2, which is 
overwhelmingly popular.


On Tue, Oct 13, 2020 at 2:19 pm, Ryosuke Niwa  wrote:

Not squashing only helps if each commit can stand on its own. At that
point, I'd suggest such a sequence of commits be made into multiple
PRs instead of multiple commits in a single PR, each of which requires
a separate code review.


Commits are certainly expected to stand on their own (not introduce 
defects). If they can't, then they should be combined into another 
commit! Hence, we should not approve MRs if the MR contains commits 
that fail to meet our usual standards. Such commits should just fail 
code review. (But if you aren't willing to review MRs commit-by-commit, 
then indeed you'll never notice when such problems exist.)


If I have to open a separate MR for each change, though, I'm going to 
wind up combining multiple lightly-related changes into one big commit, 
because a new MR for every tiny cleanup I want to make requires effort. 
Such commits may be common in WebKit, but they would fail code review 
in most other open source projects. E.g. in 
https://trac.webkit.org/changeset/268394/webkit I snuck in a drive-by 
one-line fix that's unrelated to the rest of the commit. I would rarely 
dare to do that outside WebKit, knowing it would probably fail review, 
but we do it commonly in WebKit because we discourage multiple patches 
per bug and don't want to create new bugs for every small cleanup.



This to me is a show stopper. When I'm trying to bisect an issue,
etc..., the biggest obstacle I face is any intermediate revisions
where builds are broken or otherwise non-functional. I don't think we
should let anyone merge a commit into the main branch unless the
commit meets the same standards as a regular Bugzilla patch we land
today.


I agree. But I would say that a MR with such history should fail 
review, and be rewritten to not suffer from these problems.



I disagree. Detailed descriptions and function-level change logs are
exactly what I use to dig up all the code history and figure out
what's causing the bug and how to fix in numerous occasions. Not
having that would be a massive regression.

- R. Niwa


Detailed descriptions are very important. I don't think function-level 
changelogs are; documenting changes in individual functions is 
generally busywork to say what you can plainly see by just looking at 
the diff. I'll submit 
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1686/commits as an 
example of my preferred commit granularity and verbosity. (We can 
pretend it is not currently failing CI. ;) Here the commits are 
lightly-related and could perhaps be split into multiple MRs, but 
honestly that becomes annoying and unwieldy, especially as some of the 
commits depend on each other and need to land in a particular order, 
and since creating new branches and MRs (or bugs on Bugzilla) for each 
commit becomes annoying. So it's nicer to do it all in one. One of 
these commits actually makes changes that are undone by a subsequent 
commit, and is primarily there just so that I could write a commit 
message about it and show the history in two steps rather than one! 
History like that would be lost in Konstantin's Workflow 1. I don't 
think ChangeLog-style function-level detail would be helpful in any of 
them; in WebKit, I usually ignore that anyway. But all of the commits 
do have a detailed commit message, except for "fix typo" and "fix 
whitespace" (can't expect an essay for those).


Regarding line-by-line commit review... well, it would be nice to have, 
of course.  But I don't think it's as important as you suggest. 
Problems with commit messages are usually general problems with the 
entire commit message rather than problems with a specific line of the 
commit message. An exception is typos. It is harder to point out typos 
without a line-by-line review tool. But still, it's not too hard to 
tell somebody to fix a typo without being able to highlight the right 
line.


Michael


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


Re: [webkit-dev] WebKit Transition to Git

2020-10-13 Thread Michael Catanzaro
On Tue, Oct 13, 2020 at 12:32 pm, Maciej Stachowiak  
wrote:
I’m assuming your objection is to regular merges, but how do you 
feel about squash merges? Or do you think all PRs should be landed by 
rebasing?


If we want a linear history (we do), all PRs ultimately have to land as 
fast-forward merges, one way or the other. I think rebasing is the 
simplest way to accomplish that, but squashes work too if all your 
changes are sufficiently self-contained to land as one commit.


I suggest leaving this up to the discretion of the developer and 
reviewer rather than mandating one way or the other, because there are 
advantages and disadvantages to both approaches. If your local commit 
history is a mess, sometimes squashing it all into one commit is an 
easy way to make it acceptable for upstream. If you hate rewriting 
history to make it look good, and your MR isn't too huge, a squash 
might be appropriate. But more often than not, I'd say that would 
result in a worse commit history.


My own preference would be to require squash merge, because it keeps 
the history simple for the main branch, but does not risk putting 
intermediate revisions which may work or even build on the main 
branch.


The disadvantage is that if you squash before merging, you encourage 
fewer, bigger commits that might be harder to read and potentially much 
less fun to discover at the end of a bisect. E.g. consider a very 
common case: developer wants to fix a handful of separate but related 
bugs in a particular section of code. We could land all the fixes in 
one huge commit, but that's inevitably going to be harder to read, 
harder to deal with if it introduces a regression, and will certainly 
have a more confusing commit message (either because it gives less 
detail about the changes, or because it's very long describing multiple 
related changes that could have been separate commits). We could split 
it up into different MRs for the different commits, but that becomes 
annoying when the commits are related, and hard to keep the different 
MRs in order. So I don't normally squash (except when committing small 
fixup commits via the web UI), because the disadvantages generally 
outweigh the benefits.


On the other hand, if you don't squash, it's indeed possible that your 
commit history might be messy, e.g. intermediate commits might break 
tests fixed by subsequent commits, or intermediate commits might not 
build at all. Squashing before merging does eliminate those risks, but 
I recommend code review instead: commit history and style is subject to 
review just like code changes are. Sometimes I see a merge request with 
a messy commit history that just begs for two or more commits to be 
squashed together. (This is common for students new to open source. 
WebKit does not have this problem currently.) Sometimes I see the 
opposite, where too many changes are bundled into one big commit. (This 
is more common in WebKit, since we normally try to have one patch per 
bug, and splitting changes into multiple bugs is inconvenient.) But 
usually the developer submitting a MR has found a good balance between 
the two extremes. Ultimately, what's most important is landing a clean 
commit history with reviewable commits. Again, the scope of commits is 
subject to review just like code changes are.


I agree that we don't want to merge WIP commits of any form, and 
reviewers should complain if these appear in a MR. E.g. if making an 
API change that requires updates in 200 files, we surely want them all 
updated in one commit, because we don't want broken intermediate 
commits on master that would break bisections. So sometimes huge 
commits are unavoidable. Similarly, if an intermediate commit is known 
to break a test, that's not good either because it could mess up 
bisects. (I don't think we necessarily need to run tests on every 
intermediate commit -- that might be too much for our infrastructure -- 
but we could if desired.) What we don't want is to wind up merging 
low-quality stream-of-consciousness style commits that looks like they 
were committed in the order the code was written. I think that's what 
you're trying to avoid by suggesting squashes. Instead, I suggest 
developers should aggressively use 'git add -p' and 'git rebase -i' to 
selectively commit, rewrite, and reorder history to look good before 
opening the MR. This isn't optional for most open source projects: if 
you propose an MR with ugly commit history, it won't be merged until 
fixed. For a typical MR of moderate complexity, I'll use 'git rebase 
-i' at least a couple times before the history is clean enough for a 
MR, and to make fixup commits disappear into the most-appropriate 
commit in the sequence.


Regarding commit messages, I don't understand why there's any 
expectation that they need to be checked into files in order to be 
detailed and complete. If a commit message doesn't adequately describe 
what it's fixing, then the reviewer should open a 

Re: [webkit-dev] WebKit Transition to Git

2020-10-07 Thread Michael Catanzaro
On Wed, Oct 7, 2020 at 4:17 am, Konstantin Tokarev  
wrote:

BTW, could you estimate how many of users which have provided
meaningful bug reports were directed to bugs.webkit.org but never 
made it?


A lot. I'd say maybe about half make it upstream. That's OK. We don't 
have time to fix everything, after all, and it doesn't make sense to 
focus on bug reports where we cannot easily interact with the reporter.



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


Re: [webkit-dev] WebKit Transition to Git

2020-10-06 Thread Michael Catanzaro
On Wed, Oct 7, 2020 at 2:22 am, Tetsuharu OHZEKI 
 wrote:

If we move to GitHub Issue, compared to bugzilla, that does not have
"component watching".
(I don't know the case of GitLab's Issue)
We only can watch all issues or not for the repository.


Oh dear. I had assumed that you could easily subscribe to particular 
labels (as you can in GitLab) but, poking around in GitHub's UI, I 
indeed don't see any way to do that. :/


That's no good. E.g. multimedia developers expect to be able to 
subscribe only to multimedia bugs, WebKitGTK developers will want to 
watch only GTK bugs, etc.


Michael


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


Re: [webkit-dev] WebKit Transition to Git

2020-10-06 Thread Michael Catanzaro



On Tue, Oct 6, 2020 at 3:13 am, Konstantin Tokarev  
wrote:

1. Sub-par support for linking issues to each other


Traditional bug tracking systems (like Bugzilla or JIRA) have support 
of "related" or "linked" issues. Most important relations are


* A depends on B (B blocks A) - blockers and umbrella issues
* B is duplicate of A
* A and B are related in other unspecified way


GitHub does have duplicates btw, but the syntax is completely different 
from GitLab so I can never remember how it's done. It's not exposed in 
the UI. In GitLab it's easy: /duplicate #245 to mark a bug as duplicate 
of issue #245. (You can have cross-repo duplicates too, and I think 
even cross-*project* duplicates. This is very important for GNOME, but 
not for WebKit since WebKit is just one huge repo.)


I found instructions for GitHub here: 
https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/about-duplicate-issues-and-pull-requests#marking-duplicates


* There is no easily visible list of relations: if you are not 
closely following all activity on A, to find all issues related to it 
you have to browse through all its (pseudo-)comments, which in some 
cases might be long.
* There is no *stateful* list of relations: if A was believed to have 
common source with B, but then it was discovered they are not 
related, you cannot delete relationship between A and B because there 
is no relationship, just a set of comments.


In my experience, this isn't really a *huge* problem. Umbrella issues 
work well enough to track relationship between bugs, as do milestones, 
and you can use whichever you prefer. I admit it is not nearly as nice 
as Depends/Blocks from Bugzilla, though. But I think it should be good 
enough for us.


* "#" is not a safe reference format. Sometimes users' 
comments may have other data in "#" format with a different 
meaning than references to GitHub issues. For example, may the force 
be with you if someone pastes gdb or lldb backtrace into comment 
without escaping it into markdown raw text block (```). Also, GitHub 
parses mentions in git commit messages, so care must be taken to 
avoid any occurrences of "#" with a meaning different from 
reference to issue number.


Yeah this is unfortunate and also guaranteed to happen. The first 
several dozen issues are going to be spammed with references to other 
bugs all over the place.


[2] For some reason they have shared numbering, which means sometimes 
you may not know what kind of reference is in front of you until you 
look up its URL or navigate


This is silly too (and not a problem on GitLab, which uses # for issues 
and ! for merge requests). But although I agree it is a defect, is it 
really a huge problem? Probably not.


Also, on test cases. You probably like this feature of Bugzilla when 
you can attach self-contained HTML file to the issue and then simply 
open it by URL in any browser including your build of WebKit to try 
it out. Forget this - GitHub simply forbids HTML or JS attachments 
(without wrapping them in archive):


"We don’t support that file type. with a GIF, JPEG, JPG, PNG, 
DOCX, GZ, LOG, PDF, PPTX, TXT, XLSX or ZIP."


And yes, take care not to use tar.xz or tar.bz2 or any other 
unapproved archive type.


OK, now you've convinced me... this is bad. :P I forgot about this 
problem because GitLab does not have any such restrictions on 
attachments. It's very frustrating to have to say "I added a .txt file 
extension so I could upload this to GitHub. Please remove the file 
extension after you have downloaded the file before you use it." I 
would say this is strongest argument I've seen against GitHub. Silly 
problem to have tbh.


I'll just add that GitLab has become *really* popular for Linux-related 
projects. I have to regularly work with GNOME GitLab, freedesktop 
GitLab, and gitlab.com. Fedora and CentOS are both switching to GitLab 
too, so soon that will be five different public GitLab instances that I 
have to switch between regularly, and that's limited to only the public 
instances. Then there are also many major communities I don't work with 
that are also using GitLab (KDE, Debian, Purism). It's reached the 
point where unless you only work on Linux kernel itself, you probably 
spend a lot of time on one GitLab or another. It should be considered 
alongside GitHub as an option, especially if we're concerned about 
GitHub-specific problems.


And when issues are triaged, they can be resubmitted to WebKit 
tracker by qualified person if they are really relevant.


In practice, I don't think it's a good idea because (a) moving bugs 
upstream takes a lot of time, (b) it's quite often important to have 
the original reporter CCed on the issue and able to comment. I receive 
tons of WebKit bugs in the Epiphany bugtracker, and while a few years 
ago I might have forwarded reports upstream myself, nowadays I only 
provide 

Re: [webkit-dev] WebKit Transition to Git

2020-10-05 Thread Michael Catanzaro
On Mon, Oct 5, 2020 at 8:40 am, Jonathan Bedard  
wrote:
That's one solution, but even that is somewhat insufficient because 
we don’t want to give someone access to every security issue just 
to give access to a single one. One of the solutions we’ve 
discussed is to migrate bugs component by component, the security 
component may stay on bugzilla indefinitely.


Can you grant access to a single issue by CCing the desired user to the 
issue? I expect that would work (not tested).



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


Re: [webkit-dev] WebKit Transition to Git

2020-10-03 Thread Michael Catanzaro
On Sat, Oct 3, 2020 at 9:52 pm, Konstantin Tokarev  
wrote:
If I understand correctly, there is no way in GitHub UI to see a 
difference between
patches submitted at step 1 and step 3. It's still possible to see 
old version of patches
if you navigate to old commit hash, but that's not for long as they 
can be garbage

collected by GitHub because they don't belong to git branch anymore.


If we are really seriously concerned about this... it's not a problem 
with GitLab. At least, I can still view diffs between different 
revisions of merge requests from two years ago, and the changes seem to 
be stored forever. At least I still can view diffs from years ago. E.g.:


https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/62/diffs?diff_id=27669_sha=0c020384b602c9e1f0e8ec9e491d1951e8feadf7

Unfortunately it's sometimes less useful than I might have hoped, 
because rebases bring in a bunch of totally unrelated changes, e.g.:


https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/62/diffs?diff_id=28036_sha=043b5fc32f4f9263d393c9de83e1b33123c5



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


Re: [webkit-dev] WebKit Transition to Git

2020-10-03 Thread Michael Catanzaro

On Sat, Oct 3, 2020 at 3:16 am, Ryosuke Niwa  wrote:

I've gotta say I'm very much concerned about getting rid of change
logs when we move to Git. We put a lot of useful information about
what was causing the bug, how we fixed it, and why we fixed the way we
did in a change log. I've seen a few projects which transitioned to
Git and somehow lost the rigor in maintaining an equally high quality
commit message, partly because most code review tools don't let you
add inline comments to commit messages.


You may not be able to add inline comments on commit messages, but I've 
never been particularly concerned about that. You can still start a new 
discussion thread mentioning the problem with the commit message that 
you'd like to see resolved, blocking merge until the discussion thread 
is resolved. Although in GNOME we don't often have problems with 
low-quality commit messages, we do sometimes, and during review we 
treat that as we would any problem with the code. Having a set of 
guidelines for writing commit messages, like [1], might help. But yes, 
we do lose the ability to do inline comments during code review.


(Anyway, this is only a tangent, since of course we can switch to 
GitHub but still keep ChangeLog files if we decided to do that.)


[1] https://wiki.gnome.org/Git/CommitMessages


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


Re: [webkit-dev] WebKit Transition to Git

2020-10-02 Thread Michael Catanzaro

On Fri, Oct 2, 2020 at 09:43, Jonathan Bedard  wrote:
The biggest blocker we are aware of is managing security bugs, since 
the security advisory system used by GitHub is essentially the 
opposite of how WebKit security bugs work. Moving to GitHub Issues, 
if it happens, will be the last part of this transition, and we are 
interested in soliciting feedback from our contributors on what the 
WebKit project’s integration with GitHub Issues should look like.


I don't think we need much integration to use the issue tracker? Once 
we migrate existing bugs from WebKit Bugzilla, we can use it as we 
would any other issue tracker? Why would it require integration?


We might need to use a separate repository with more limited 
permissions to handle security reports. At least in GitLab, all project 
developers (committers) have access to all confidential issues. I'm not 
sure about GitHub, but I assume it would be the same.


What will require integration is pull request merges. If we want to 
maintain linear version history, we will want a merge bot. On GNOME 
GitLab, we have a large number of smaller projects and it's we don't 
need them, but for a one huge project like WebKit there will be too 
many conflicts otherwise, because every commit going into the main 
branch will require all other pull requests to be rebased. A merge bot 
-- e.g. [1] -- will handle that for us. (Not sure what merge bots are 
common on GitHub. )


Michael

[1] https://gitlab.com/fsdk-marge-bot


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


Re: [webkit-dev] WebKit Transition to Git

2020-10-02 Thread Michael Catanzaro

On Fri, Oct 2, 2020 at 13:48, Ken Russell  wrote:
Github's code review UI has a couple of feature gaps in my opinion. 
It's difficult to look at earlier versions of the pull request, in 
particular to verify that issues found during code review have been 
fixed. I remember it also being difficult to figure out whether all 
comments on earlier versions have been addressed.


I'm not familiar with reviews on GitHub. I just want to add that GitLab 
reviews are great and have none of these problems. It's very easy to 
view older versions of merge requests and compare the differences 
between arbitrary revisions of the merge request. (That's often 
important when reviewing small changes to a large merge request.) Every 
discussion thread is clearly marked as either resolved (green!) or 
unresolved, and you can (and should) configure GitLab to block merges 
until all discussions are resolved. (I would be disappointed if GitHub 
doesn't have the same convenience features, as this helps prevent 
mistakes from being forgotten.)


I realize that Gerrit might not integrate at all with hosting the 
repo on Github, but has any thought been given to this aspect of the 
transition?


That sounds like it would be a significant barrier to contribution, and 
frankly defeat the point of switching. If we have serious concerns with 
GitHub's code review functionality (which, again, I'm not familiar 
with), then we should just use GitLab and have everything in one place. 
(GitLab accepts GitHub logins via OAuth, both on gitlab.com and 
self-hosted instances, so the barrier to contributing remains low 
either way.)


Michael


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


[webkit-dev] Issue reports, merge requests, etc. (was: WebKit Transition to Git)

2020-10-02 Thread Michael Catanzaro

On Fri, Oct 2, 2020 at 11:51 am, Ryosuke Niwa  wrote:

Since Igalia has a lot
more experience working with other open source projects, do you have
some suggestions in how to approach that?


Sorry for a long-ish mail. I didn't mean for this to turn into an 
essay. Too late. :P


I actually moved to Red Hat, but anyway, I would say first step is to 
ensure every incoming issue is triaged, at least once when initially 
reported, and every merge request given at least cursory review within 
a reasonable amount of time. That's how open source projects attract 
and retain community contributors, and it's been a weakness for WebKit 
for a while (we're not the worst at this, but certainly not good at it 
either). One possible answer for this is to have a "project manager" or 
similar role to triage and prioritize issues, but of course it can also 
be done by developers working together (possibly according to some 
rotation).


WebKit is such a big project that I suspect almost nobody has enough 
expertise to triage all incoming bugs, but most of us have enough 
expertise to figure out which issue labels to apply to an incoming bug 
to pass the issue off to more specialized experts. On GNOME GitLab we 
label incoming issues with Bug, Crash, Enhancement, or Feature (the 
difference between Enhancement and Feature is hazy) and have a variety 
of global and per-project labels that can also be applied to issues 
[1]. The list of current components in WebKit Bugzilla would be a good 
starting point to use here. Every new issue gets reviewed and either 
gets closed or else gets a label applied to indicate it has been 
triaged, usually within one business day. If an issue is open and 
doesn't have any labels, we know it has not been triaged.


A lot of bugs can be closed immediately because they're reported in the 
wrong place, for instance. Most crashes are reported without a 
backtrace; to those, we attach a Needs Information label and point the 
reporter to instructions for getting a backtrace with gdb, and close 
after a few days if not provided. The details don't matter so much as 
the fact that the issue has received minimal human attention. In the 
rare cases where a bug report is perfect and all I need to do is add 
issue labels, I give the issue an upvote to indicate I've seen it, so 
the reporter knows it hasn't been *completely* ignored, even if nobody 
fixes it. The details don't matter so much as that contributors and 
issue reporters feel like they've received at least some attention and 
aren't shouting into a bug wasteland.


Then developers subscribe to project-specific labels in accordance with 
their expertise and tolerance for mail. E.g. I watch all issues for 
some projects, but for GLib I'm only subscribed to networking-related 
labels, since problems in the network-related code often impact WebKit. 
Some developers will want to watch only for CSS bugs, only layout bugs, 
only JSC bugs, only WebKitGTK bugs, etc.


Of course, triaging issues doesn't mean they actually get fixed, but 
it's a necessary first step. (And once isn't really enough, either. 
Most of our bugs from 2008 are probably no longer valid, but it takes 
time to review old bugs, and not many people have enough specialized 
technical expertise to triage outside their area of expertise. Anyway, 
once is a starting point.)


Responding to merge requests (or patch reviews) in a timely manner is 
also important (otherwise, contributors disappear). Merge requests take 
longer than issues, but it's good to get to each one within a couple 
days; otherwise, they really start to pile up. We currently have 
patches awaiting review from 2017 [2], and that's just the last time 
somebody decided to mass-deny old review requests. And a lot of these 
are from Apple/Igalia/Sony, who all know who to CC for reviews; imagine 
how much harder it is for someone not familiar with the WebKit 
community to get a patch reviewed. ;) GitHub will probably help with 
this because it puts merge requests front-and-center in its UI, instead 
of requiring us to first discover then take the time to sort through 
the request queue. It's hard to use GitHub without habitually reviewing 
pending requests. ;) The number of open issues and MRs is even clearly 
displayed as a sort of challenge to reduce the number. But we'd need 
some workflow for directing merge requests to appropriate reviewers.


When we move to GitHub, you can expect to start receiving merge 
requests from people who would not take the time and effort to create a 
WebKit Bugzilla account and learn how to use our arcane ChangeLog and 
patch creation scripts. Epiphany has twice as many active contributors 
and probably 3-4x more activity today on GNOME GitLab than it did when 
we used GNOME Bugzilla, and I'm pretty sure that's mainly due to GitLab 
rather than other factors. I wouldn't expect that dramatic a change for 
WebKit, since most WebKit contributors are professional rather than 
volunteer 

Re: [webkit-dev] WebKit Transition to Git

2020-10-02 Thread Michael Catanzaro
On Fri, Oct 2, 2020 at 6:36 pm, Philippe Normand  
wrote:

Would you also consider preventing merge commits in order to keep a
clean mainline branch?


Big +1 to blocking merge commits. Merge commits in a huge project like 
WebKit would make commit archaeology very frustrating. (I assume this 
is implied by the monotonic commit identifiers proposal, but it doesn't 
exactly say that.)


I'm sure transition to git and GitHub should go well. I would have 
selected GitLab myself -- it's nicer and also overwhelmingly popular -- 
but whatever. (Does GitHub have merge request approvals? Replicating 
our reviewer/owner permissions with GitLab merge request approvals 
would be easy.)


One downside is that using github.com might actually make it *too* easy 
to spam us with low-quality issue reports and merge requests. We've 
historically been pretty bad at maintaining a clean issue tracker -- 
the quantity of untriaged issues on Bugzilla is very high -- and GitHub 
will make this worse. That's not an issue with the GitHub platform, 
though. Just something to stay on top of.


Michael


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


Re: [webkit-dev] Question: referrerpolicy in Safari

2020-09-23 Thread Michael Catanzaro



On Wed, Sep 23, 2020 at 1:50 pm, Dominic Farolino 
 wrote:
I haven't dug too deep here, but just going to post this in case it 
answers your question and saves you some time. As documented here, it 
appears that Safari is starting to not honor the `referrerpolicy` 
attribute on HTML elements where it would override the referrer 
policy redaction that their cross-site tracking work has performed, 
or at least in cases where it would expose more information than what 
was intended by the cross-site tracking protection. That may be an 
oversimplification, (I trust someone from WebKit can clarify), but it 
may explain the behavior you are seeing.


That probably explains case 1. There's some documentation of this at 
https://webkit.org/tracking-prevention/. The actual URLs matter here. 
With https://site-one.example/path/foo and https://site-two.example/, 
the top privately-controlled domains are different (site-one.example 
vs. site-two.example) so the referrer will be downgraded to its origin. 
But say you were instead testing https://site-one.example.com/path/foo 
and https://site-two.example.com/, then the top privately-controlled 
domain in both cases is example.com, and there's no forced downgrade.


That doesn't explain what's going on in case 2 or case 3, though. 
Smells like bugs?


Michael


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


Re: [webkit-dev] Generating compile_commands.json when building WebKit on MacOS

2020-07-22 Thread Michael Catanzaro

On Wed, Jul 22, 2020 at 11:15 am, shriva...@firemail.cc wrote:
DerivedSources/ForwardingHeaders/JavaScriptCore/JSContext.h:40:1: 
error: duplicate interface definition for class 'JSContext'

@interface JSContext : NSObject
^
../../Source/JavaScriptCore/API/JSContext.h:40:12: note: previous 
definition is here

@interface JSContext : NSObject
   ^

Your assistance would be much appreciated.


It might be time to simply remove support for building WebKitGTK on 
macOS. I imagine it's been many years since anyone has successfully 
built it.



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


Re: [webkit-dev] Plugin process

2020-07-20 Thread Michael Catanzaro
On Mon, Jul 20, 2020 at 9:35 am, Michael Catanzaro 
 wrote:
For now, I'll submit a patch to deprecate these settings without 
changing behavior yet.


Meh, I did this, but realized that it's easier to write deprecation 
messages when we remove support for the feature at the same time that 
it's deprecated. That is, if we wait until after branching to 
deprecate, we can write:


Deprecated: 2.32: NPAPI browser plugins are insecure and no longer 
supported.


Rather than:

Deprecated: 2.30: NPAPI browser plugins are insecure and will no longer 
be supported in 2.32.


And then later changing it to:

Deprecated: 2.30: NPAPI browser plugins are insecure and no longer 
supported since 2.32.


So let's wait until branching.


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


Re: [webkit-dev] Plugin process

2020-07-20 Thread Michael Catanzaro
On Mon, Jul 20, 2020 at 11:47 am, Adrian Perez de Castro 
 wrote:
Our tentative plan for sunsetting the NPAPI support is to keep 
supporting
the GTK3 plugin process in the next stable release series. This means 
that
we could remove the support from trunk after creating the stable 
branch

for the 2.30.x releases—that would be around September-October 2020.


Well branching normally occurs in August... just a few weeks away now. 
Then we can make the plugin process specific to PLATFORM(COCOA), until 
Apple figures out if it can be removed, and we can delete the support 
for all other platforms.


For now, I'll submit a patch to deprecate these settings without 
changing behavior yet.


I think we would need to make the public API to toggle the support 
for plugins

a no-op and log a warning to avoid breaking applications.


Well a warning certainly doesn't hurt. I suspect no applications are 
using it, though.


Michael


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


[webkit-dev] Plugin process

2020-07-19 Thread Michael Catanzaro

Hi,

Is anybody still using the plugin process? I understand that Safari 
does not allow plugins anymore. Epiphany doesn't either, nor does 
anything packaged in Linux distros  (afaik). If nothing is using it, 
maybe we can delete a lot of code? Is it exposed in Apple system APIs?


WebKitGTK still has an enable-plugins setting that is not yet 
deprecated. Probably long past time to at least deprecate it. There's 
also, incredibly, an enable-java setting, which I presume toggles the 
old Java browser plugin. I sense there must be some history behind that 
setting. :)



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


Re: [webkit-dev] [webkit-changes] [264332] trunk/Source

2020-07-16 Thread Michael Catanzaro

On Thu, Jul 16, 2020 at 4:14 pm, Darin Adler  wrote:
Let’s stop doing it that way. Just compile the files and have #if 
inside the file.


I removed all conditional source files from the Xcode build system. 
Let's do the same for the CMake build system.


— Darin


I agree we should do this. We've never been consistent between whether 
we guard files at the build system level or inside the files 
themselves. But with unified builds, the advantage of putting the 
guards inside the files is clear: we would ensure that the set of files 
compiled is always the same for a given port regardless of which 
options are used.


I wouldn't use that as a reason to drop non-unified builds, though. 
E.g. Yusuke's argument regarding compile_commands.json seems pretty 
compelling.



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


Re: [webkit-dev] Position on User-Agent Client Hints

2020-05-07 Thread Michael Catanzaro
My personal $0.02: I'm mildly supportive of this spec. It's certainly 
an improvement on existing HTTP user agent headers. I appreciate that 
you worked to incorporate feedback into the spec and considered the 
concerns of small browsers.


Is it going to solve all the problems caused by user agent headers? No. 
If WebKit implements the spec, we're surely going to eventually need a 
quirks list for user agent client hints to decide which websites to lie 
to, just like we already have quirks for the user agent header. And as 
long as Chrome sends a user agent header that includes the string 
"Chrome", it's unlikely we'll be able to get rid of the existing quirks 
list. But I think client hints will probably reduce the amount of 
websites that *accidentally* break WebKit, by replacing wild west UA 
header parsing with well-defined APIs, and adding some GREASE for good 
measure. The promise of freezing Chrome's UA header sounds nice, as it 
makes quirks easier to maintain. And being able to ration entropy by 
revealing details about the platform on an active rather than passive 
basis is quite appealing.


The spec attracted some misplaced concern about negative impact to 
small browsers, which I've rebutted in [1]. I'm not quite so 
enthusiastic about this spec as I was initially, especially after I was 
convinced that the GREASE is never going to be enough to remove our 
quirks list, but it's certainly not going to *hurt* small browsers.


This spec has received some pretty harsh criticism from the user 
tracking industry (some call it the "ad industry"). Not historically a 
friend of WebKit, so sounds good to me. ;)


One concern I haven't mentioned elsewhere is that frozen UA header 
might encourage deeper levels of fingerprinting than are currently 
used, e.g. for ad fraud prevention. caddy has started blocking 
WebKitGTK users based on TLS handshake fingerprint (yes, really!) [1]. 
If techniques like that take off as a result of this, that could 
potentially backfire on us quite badly. But websites could choose to do 
such things today anyway, client hints or no, and if so, the solution 
will be for us to just try even harder to look more like Chrome.


Seems like a net positive overall. I don't work for Apple and can't say 
whether it might be implemented by WebKit.


Michael

[1] 
https://github.com/w3ctag/design-reviews/issues/467#issuecomment-583104002

[2] https://mitm.watch/


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


Re: [webkit-dev] webkitgtk and bubblewrap help needed

2020-04-28 Thread Michael Catanzaro
On Mon, Apr 27, 2020 at 11:22 pm, Jack Hill  
wrote:

Can this problem be worked-around in WebKitGTK?


Looks like WebKit should call realpath() for each path it passes to 
bwrap. Annoying, but certainly doable. Want to report a bug for it on 
WebKit Bugzilla?



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


Re: [webkit-dev] Introducing a minimum ICU version for WebKit

2020-04-09 Thread Michael Catanzaro
On Thu, Apr 9, 2020 at 2:48 pm, Michael Catanzaro 
 wrote:
Sometimes distros make exceptions (e.g. for WebKitGTK, which is 
special due to very high number of CVEs), but ICU does not warrant an 
exception. There are probably hundreds of applications using ICU in 
distros, if not more. Who knows what might break!


Also, sadly ICU does not maintain a stable API or ABI. So every 
application and library using ICU would need to be rebuilt and updated 
at the same time. Then the update would break any custom software that 
users have using the system ICU. Such an update would go badly... 
probably would wind up in tech news once people notice the breakage.


WebKitGTK can be updated because we maintain stable API/ABI.


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


Re: [webkit-dev] Introducing a minimum ICU version for WebKit

2020-04-09 Thread Michael Catanzaro




On Thu, Apr 9, 2020 at 7:08 pm, "Olmstead, Don"  
wrote:

Hi Michael,

There are a couple problems with checking in a version of ICU.

* Other libraries used by WebKit have dependencies on ICU. For our 
ports harfbuzz, libxml2, libxslt, libpsl and CFlite all require ICU.


You're right, it's a bad idea.

* ICU doesn't come with a CMake build system and its non-trivial to 
make one. We've largely used this 
https://github.com/LibCMaker/ICU_CMake_Files to handle building ICU 
but its use is also why ICU is the library we aren't able to update 
on a regular cadence.


Another good point. Hadn't thought that through far enough.

* We aren't terribly good with updating things in ThirdParty. 
Sometimes this is because there aren't releases, see gtest. Others 
because they don't actually have releases, see ANGLE. On top of that 
there might be local modifications to make things work within WebKit.


Of course, bundling things in ThirdParty is an absolute last resort. 
But when using system packages is no longer possible, what else to do? 
I have to support WebKit on RHEL 7, which has ICU 50. Mike from SUSE is 
trying to support SLE 12, which has ICU 52. You can see it doesn't add 
up. :)


But I didn't object to the ICU 60 proposal because (a) our dependency 
policy allows cutting off distros older than Ubuntu 18.04 and Debian 
Buster, and (b) I figured we would just bundle it. Instead, a better 
approach is probably to come up with downstream patches to revert all 
the changes that require ICU 60 and maintain them as long as we can. 
Same goes for CMake, but it's going to get a lot harder as WebKit usees 
more and more new CMake features. At some point we'll probably need to 
try bundling a custom CMake, since eventually that will be easier than 
patching WebKit to use ancient CMake.


Could you possibly give some overview of how WebKit is packaged by 
Linux distributions? I would have thought they would use 
flatpack/jhbuild to get the dependencies that the WPE/GTK ports are 
using especially if those dependencies have their own set of bug and 
security fixes. My experience with Linux is minimal so some context 
here would be appreciated.


No, distros build against their own system packages.

JHBuild is a developer tool. And flatpak is cool, but not used to build 
distro packages. Fedora is experimenting with distributing applications 
using flatpak, but you can't distribute system libraries that way.


For our ports we use vcpkg to build and manage dependencies. We host 
it at https://github.com/WebKitForWindows/WebKitRequirements and have 
an internal fork for PlayStation. I'm guessing it's probably similar 
to flatpack/jhbuild in terms of functionality but in our case we just 
use GitHub releases to have binaries ready.


Perhaps there are better ways for us to approach the requirements 
that would be beneficial to all ports?


I don't think there's really anything to do other than to decide how 
many old distros we're willing to cut off of updates. Currently the 
dependencies policy protects distros for three years. To continue 
supporting Ubuntu 16.04 (which reaches EOL in April 2021), it would 
need to be extended to five years. Probably not many developers would 
be very happy with that at all. But Ubuntu have a five-year lifecycle, 
so it's tough beans for WebKit users if we drop support before that 
time. RHEL and SLE have 10 and 12-year lifecycles, respectively... 
nobody is going to propose supporting that upstream, we just have to 
either figure out how to deal with it or cut off updates eventually 
once it becomes too hard to build.


I'd support extending our dependencies policy from three years up to 
five years... only problem is, five years makes it really hard to use 
new C++ features, and we like those. :( Anyway, with the current 
dependencies policy, ICU 60 is allowed. We'll just have to figure out 
how to deal with it downstream.


Michael


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


Re: [webkit-dev] Introducing a minimum ICU version for WebKit

2020-04-09 Thread Michael Catanzaro



On Thu, Apr 9, 2020 at 11:49 am, Alexey Proskuryakov  
wrote:


The license is not BSD or LGPL, so that's one aspect to consider.

Why exactly are distros unwilling to update ICU?

- Alexey


Distros would upgrade to newer minor releases of the library, but 
updating system packages to new major versions is not allowed in most 
stable distros.


Sometimes distros make exceptions (e.g. for WebKitGTK, which is special 
due to very high number of CVEs), but ICU does not warrant an 
exception. There are probably hundreds of applications using ICU in 
distros, if not more. Who knows what might break!



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


Re: [webkit-dev] Introducing a minimum ICU version for WebKit

2020-04-09 Thread Michael Catanzaro



Any objections to uploading a bundled ICU 60 under Source/ThirdParty?

Seems easier than forcing downstreams to work out bundling themselves. 
Most major distros will just stop providing WebKit security updates if 
we don't bundle it for them. E.g. this is sure to kill Ubuntu's current 
long streak of providing our updates to Ubuntu 16.04.



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


Re: [webkit-dev] [Styling] Space between [] and () in C++ lambdas

2019-11-01 Thread Michael Catanzaro

On Fri, Nov 1, 2019 at 11:19 am, Ryosuke Niwa  wrote:

Namely, some people write a lambda as:
auto x = [] () { }

with a space between [] and () while others would write it as:

auto x = []() { }


: I omit the () when there are no parameters, as in these examples.

No preference on spacing.


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


Re: [webkit-dev] Issues running remote debug inspector for WPE instance with Epiphany dev preview

2019-10-11 Thread Michael Catanzaro



Hi Ryan,

This is https://bugs.webkit.org/show_bug.cgi?id=202321

Michael


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


Re: [webkit-dev] Moving to Python 3

2019-07-14 Thread Michael Catanzaro
On Sat, Jul 13, 2019 at 9:26 PM, Maciej Stachowiak  
wrote:

Can you clarify why this is needed?


Well it just wouldn't seem very kosher to use a virtualenv for the 
serious work of performing real distro builds, right? In contrast to 
developer scripts for developer convenience, where I'd say it's 
perfectly fine to do whatever we want. But official builds should 
surely be performed using system dependencies only.


Anyway, it doesn't seem like a problem. From searching for 'python' in 
my build.ninja, I find:


JSC:

ud_itab.py
generateWasmOpsHeader.py
generateWasmValidateInlinesHeader.py
generateWasmB3IRGeneratorInlinesHeader.py
create_regex_tables
generateYarrUnicodePropertyTables.py
generateIntlCanonicalizeLanguage.py
KeywordLookupGenerator.py
generate-inspector-protocol-bindings.py
generate-js-builtins.py
generateYarrCanonicalizeUnicode
generate-combined-inspector-json.py
jsmin.py
cssmin.py
make-js-file-arrays.py

WebCore:

create-html-entity-table
create-http-header-name-table
makeSelectorPseudoClassAndCompatibilityElementMap.py
makeSelectorPseudoElementsMap.py

WebKit:

generate-message-receiver.py
generate-messages-header.py

WebInspectorUI:

copy-user-interface-resources.pl (perl script that runs some python)

Tools:

generate-inspector-gresource-manifest.py

It's possible I've missed some, but that's probably most of them. 
Basically all the scripts under Source/ -- the scripts that are really 
required to build -- and that one platform-specific exception under 
Tools/, shouldn't require a virtualenv IMO. That doesn't seem too 
difficult to ensure. We could either have them use the virtualenv only 
optionally if it's somehow already available (I'm not familiar with how 
it works) or only if the scripts detect that webkitpy exists, or just 
make this subset of scripts compatible with both python2 and python3 
for the next couple years.


In contrast, the vast majority of our python scripts are not required 
to build. They live under Tools/Scripts, are only used by developers, 
and are not included in release tarballs at all. That includes all of 
webkitpy, anything used by build-webkit, anything used by 
run-webkit-tests, etc. I'd say we can go crazy here. You get a 
virtualenv, you get a virtualenv, everybody gets a virtualenv!


Michael


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


Re: [webkit-dev] Moving to Python 3

2019-07-13 Thread Michael Catanzaro
On Sat, Jul 13, 2019 at 6:02 PM, Maciej Stachowiak  
wrote:
This is exactly what virtualenvs can do. And this is how we should do 
it IMO, even for systems that natively have some version of Python 3.


I guess that's fine for everything not required by the CMake build, 
e.g. build-webkit and webkitpy. That's probably 99% of our python code.


Scripts required by the CMake build should use system python3 though, 
not the virtualenv. I guess that's 1% or less of our python. OK?


Michael


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


Re: [webkit-dev] Moving to Python 3

2019-07-12 Thread Michael Catanzaro

On Fri, Jul 12, 2019 at 5:22 PM, Ryosuke Niwa  wrote:
I frequently do WebKit development in older versions of macOS to 
diagnose old OS specific regressions, and having to install Python 3 
each time I install an old OS is too much of a trouble.


I understand it would be a hassle. :/ But please consider it relative 
to the additional difficulty of rewriting all of webkitpy to support 
multiple versions of python at the same time, or setting up a wrapper 
layer of bash scripts around all of our python scripts to enter a 
virtualenv before executing the real script.


Michael


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


Re: [webkit-dev] Moving to Python 3

2019-07-12 Thread Michael Catanzaro
On Fri, Jul 12, 2019 at 2:18 PM, Jonathan Bedard  
wrote:
The trouble I foresee us encountering with any scheme which attempts 
a conversion which retains both Python 2.7 and Python 3 compatibility 
is code like this:


Is python2 support required for a well-motivated transitional purpose?

I had previously proposed making all our scripts work with both python2 
and python3 only because I thought Apple was going to require python2 
indefinitely. Now that you're interested in this transition, there's 
probably no need to continue python2 support. Anyone building WebKit on 
older versions of macOS can reasonably be expected to manually install 
python3, right? And it's clear that you're prepared to do this for 
infrastructure/bots already.


Then million-dollar question is: what shebangs will we use for our 
scripts? Will #!/usr/bin/env python3 work for Apple?


Michael


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


Re: [webkit-dev] What's the current Safari UA?

2019-07-12 Thread Michael Catanzaro


I received a good answer and will upgrade our versions accordingly. 
Thanks.



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


[webkit-dev] What's the current Safari UA?

2019-07-12 Thread Michael Catanzaro

Hi,

Relevant to [1], could someone please check what Safari's current UA 
string is, please? This is important to help me make sure WebKitGTK 
fakes the Safari user agent as well as possible. In particular, I'd 
like to know the version numbers used in the UA. I had thought we were 
frozen on:


Version/11.0 Safari/605.1.15

forever, but perhaps the Version/ component is not frozen and we're up 
to Version/12.0 or Version/12.1 now? I hope the 605.1.15, at least, is 
still frozen.


Also, for those naughty websites that require we use some serious 
fakery and pretend to be macOS, we currently use the string "Macintosh; 
Intel Mac OS X 10_13_4". I understand that Apple's previous attempt to 
freeze that value was not successful, so we still need to update this 
from time to time. What does it look like on, say, Mojave or Catalina?


Thanks,

Michael

[1] https://bugs.webkit.org/show_bug.cgi?id=199745


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


Re: [webkit-dev] [CMake] Bump cmake_minimum_required version to 3.10

2019-06-27 Thread Michael Catanzaro
On Thu, Jun 27, 2019 at 11:20 AM, Brent Fulgham  
wrote:
Apple is in the process of bringing up VS2019 now. I would be in 
favor of moving the minimum to 3.14 so we can safely support VS2019 
compiles.


The 3.14 target is too aggressive for WPE/GTK, unfortunately. You could 
use a different cmake_minimum_required for Windows only, of course.



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


Re: [webkit-dev] Windows 32-bit support?

2019-06-25 Thread Michael Catanzaro
On Tue, Jun 25, 2019 at 10:42 AM, Michael Catanzaro 
 wrote:
You say the cloop seems unstable for you, which is option (3). So 
perhaps you should try option (2) if you haven't already. I'm not 
actually sure if that works, because I'm not an expert, which is why 
I added that (?) to it. But at least it couldn't hurt to try.


I'm being advised that (2) isn't going to work on 32-bit either. So 
you'll need to try to make cloop work. Good luck... I'm not aware of 
anybody else supporting JSC on 32-bit Windows.


Michael


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


Re: [webkit-dev] Windows 32-bit support?

2019-06-25 Thread Michael Catanzaro
It's great that you find our stable branches helpful, but keep in mind 
those branches do not include Windows-specific fixes.


On Tue, Jun 25, 2019 at 9:53 AM, Arunprasad Rajkumar 
 wrote:
Right. Actually the problem is in 32-bit Windows platform. I see that 
the JIT support has been dropped some time ago, and CLOOP based 
backend seems to be unstable on 32-bit Windows. Any thoughts on that?


So I'm not an expert here, but I understand there are three ways you 
can build JSC:


(1) -DENABLE_JIT=ON, -DENABLE_C_LOOP=OFF
(2) -DENABLE_JIT=OFF, -DENABLE_C_LOOP=OFF (?)
(3) -DENABLE_JIT=OFF, -DENABLE_C_LOOP=ON

(-DENABLE_JIT=ON and -DENABLE_C_LOOP=ON are incompatible.)

I believe that nowadays the only 32-bit platforms supported by JIT are 
Linux, and there only for ARM and MIPS, not x86. So you're almost 
certainly going to need to use -DENABLE_JIT=OFF. That eliminates option 
(1).


You say the cloop seems unstable for you, which is option (3). So 
perhaps you should try option (2) if you haven't already. I'm not 
actually sure if that works, because I'm not an expert, which is why I 
added that (?) to it. But at least it couldn't hurt to try.


Maybe the Windows port maintainers know more about the status of 32-bit 
Windows support?


Michael


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


Re: [webkit-dev] Windows 32-bit support?

2019-06-25 Thread Michael Catanzaro
On Tue, Jun 25, 2019 at 8:31 AM, Arunprasad Rajkumar 
 wrote:
So my question is, do WebKit/JavaScriptCore still supports 32-bit 
Windows?


Hi Arunprasad,

The last version of WebKitGTK to support Windows was 2.4, from 2014.

If you had 2.22 working, that's news to us. To my knowledge, nobody has 
ever done that before. You might well be the only one; certainly you're 
the only one to tell us about it. Anyway, that's cool.


We don't support Windows anymore because nobody seems to be interested 
in (a) making it work, and (b) maintaining the code upstream. So you're 
kinda on your own here. If you only needed a few downstream changes 
required to make it work, then we could consider accepting those 
upstream if you'd be willing to maintain the Windows-specific parts. 
We're not going to be willing to bring back real Windows support 
otherwise, since all current developers use Linux and are only 
interested in Linux.


Anyway, to answer your question: JavaScriptCore is used on Windows by 
the Apple Windows port and the WinCairo port, and there is very little 
GTK-specific code in JSC, so this should be the easiest part of 
WebKitGTK to get working on Windows. You might consider basing your 
Windows port on WinCairo rather than WebKitGTK, since that port is 
designed to run on Windows.


Good luck,

Michael


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


Re: [webkit-dev] C++17 is here. Should we use it?

2019-06-17 Thread Michael Catanzaro
Alex already switched all WebKit ports to building with C++17 enabled 
in https://bugs.webkit.org/show_bug.cgi?id=197131.


On Sun, Jun 16, 2019 at 8:25 PM, Sam Weinig  wrote:
If the issue is getting these bots updated, can we do that? Are there 
any other bots that might need updating as well?


We've previously agreed that we can increase the GCC version limit to 
GCC 7, but nobody ever implemented this. Reported 
https://bugs.webkit.org/show_bug.cgi?id=198914.


The easiest way to sniff out which bots should be upgraded is to just 
land the change and see which bots break. But I'll ask internally to 
ensure all remaining Igalia bots are upgraded to GCC 7 soon.


Be aware that while GCC 7 has basic support for structured bindings, 
there are limitations documented at 
https://gcc.gnu.org/projects/cxx-status.html which are not supported 
until GCC 8.


Michael


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


Re: [webkit-dev] Requesting feedback about EWS comments on Bugzilla bugs

2019-06-16 Thread Michael Catanzaro
1-4 all seem uncontroversial, especially with Tim's suggested 
improvement to immediately leave a "some queues failed" comment.


On Sat, Jun 15, 2019 at 11:13 PM, Aakash Jain  
wrote:
5) Do not comment on bugzilla bug at all, instead send email to the 
author of the patch.
Pros: less noisy, also this will allow to include more detailed 
information about the failure in email.
Cons: reviewers would have to click status-bubbles to see the 
failures, failure information is not immediately present in the 
comments.


Well I think this would be OK, but next we'll be complaining about the 
emails. The underlying problem is excessive test flakiness. We're just 
not doing a very good job of tracking flaky tests and EWS isn't good at 
detecting flaky tests automatically. (Often a flaky test will fail 
twice in the same run, and that gets detected as a test failure.) 
Instead of reporting bugs for such tests, we're ignoring them because 
there are so many and we're so used to it.


commit-queue is able to report bugs when it detects a flaky patch, but 
EWS doesn't do this. That might be a positive change. Of course, EWS 
would need to be smart enough to not report a bug if the flakiness is 
triggered by the patch itself, which might not be simple to determine.


I don't have any concrete suggestions here. Just brainstorming.


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


Re: [webkit-dev] CI builds failing for ppc64, ppc64le and s390x

2019-06-04 Thread Michael Catanzaro



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


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


Re: [webkit-dev] CI builds failing for ppc64, ppc64le and s390x

2019-06-03 Thread Michael Catanzaro



Did your builds for ARM succeed? We're having a similar (though 
completely different) packing problem there:


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


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


Re: [webkit-dev] C++17 is here. Should we use it?

2019-05-11 Thread Michael Catanzaro
On Fri, May 10, 2019 at 6:47 PM, Yusuke Suzuki  
wrote:

1. We can use GCC 7
2. We can use libstdc++7

Is my understanding correct? Basically, this means that we can use 
cool C++17 features super aggressively :)


I would say you can use cool C++ 17 features cautiously, enjoying those 
features when they work, and expecting the possibility of libstdc++7 
bugs causing them to not work.


I think our EWS bots are not yet on GCC 7, but that should be addressed 
soon.


Michael


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


Re: [webkit-dev] C++17 is here. Should we use it?

2019-05-07 Thread Michael Catanzaro
On Tue, May 7, 2019 at 1:46 PM, Konstantin Tokarev  
wrote:
Note that since we have to support libstdc++ 6.x, most of C++17 
standard
library features () should be disallowed. Those include 
std::filesystem,

std::string_view, etc. Core language features should be fine.


With my suggested one-time exception to drop support for Debian Stretch 
early due to lack of security updates there, I think it's perfectly 
fine to require libstdc++ 7 now. Igalia's EWS and stable release bots 
might need to be updated, but this is not a problem.


Michael


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


Re: [webkit-dev] C++17 is here. Should we use it?

2019-05-07 Thread Michael Catanzaro
On Tue, May 7, 2019 at 1:53 PM, Alex Christensen 
 wrote:
If you have a minimum-requirements system that you want to keep 
building, put build infrastructure on build.webkit.org so we can see 
when things break.


We already have stable release bots to test the lowest-supported 
configurations, but most developers should only ever need to worry 
about EWS, as always.


Michael


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


Re: [webkit-dev] C++17 is here. Should we use it?

2019-05-07 Thread Michael Catanzaro



Since there were no objections, I've updated the policy on the wiki:

https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy
https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement

Michael


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


Re: [webkit-dev] C++17 is here. Should we use it?

2019-05-04 Thread Michael Catanzaro
On Tue, Apr 23, 2019 at 10:50 AM, Konstantin Tokarev 
 wrote:
[1] says: "we support each major Debian version until one year after 
the release of the next major version"


Given that Buster is not released yet, bumping GCC requirement to 7 
seems to be premature.


The dependencies policy states that toolchains are only supported until 
the release of the next major version, but yes, the Debian Buster 
release has not happened yet and is likely still several months away.


Still, it's been two weeks since Alex proposed to require GCC 7, and no 
objections have been posted to this list. After talking with Berto, 
I've confirmed that Debian is OK with building packages with Clang if 
need be, and if it works for Debian it should work for Ubuntu as well. 
So instead of requiring that WebKit build with the default system 
compiler, we can just require that it build with *some* system compiler.


We do need to support the distro's libstdc++ for the full year after 
the next release, though, as otherwise it won't be possible for the 
distros to continue to update WebKit. The current policy language 
regarding toolchains does not account for that. So I'd like to simplify 
this by saying that we support some system compiler for one year after 
the release of the next major version, but not necessarily the default 
system compiler.


My proposed changes to 
https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy are:


Keep:

"""
Our dependencies policy is simple:

* We support each major Debian version until one year after the 
release of the next major version.
* We support each Ubuntu LTS until one year after the release of the 
next Ubuntu LTS.

"""

Then replace all the rest with:

"""
During the support period, we intend for WebKit to remain buildable on 
these distributions using some system-provided compiler, not 
necessarily the default system compiler, and with the default system 
libstdc++. The purpose of this policy is to ensure distributions can 
provide updated versions of WebKit during the support period to ensure 
users receive security updates.

"""

Now, those changes would imply that we can require GCC 7 now, but not 
yet libstdc++ 7, since the policy would normally require that we 
continue supporting Debian Stretch for another year. But we can make a 
one-time decision to ignore that, because Stretch isn't receiving 
WebKit security updates, so it doesn't really matter. Now, good news: 
Debian Buster will be the first version to receive WebKit updates, 
thanks to our promises of stable dependencies and Ubuntu's success with 
providing WebKit updates during the last two years. The goal of 
providing security updates to Debian will fail if we drop support for 
Debian's libstdc++ within their primary security support period (one 
year after release of the next version), though; that would be a major 
setback. So my proposed change makes it easier to increase our GCC 
requirement (if the old distros can build with old clang, then we can 
do it), but harder to increase our libstdc++ requirement (need to wait 
one additional year to do so).


The proposed future would look like this:

* Imminently: require GCC 7 and libstdc++ 7
* April 2021: require libstdc++ 8 (one year after Ubuntu 20.04 release)
* Late 2021 or early 2022: require libstdc++ 9 (one year after the 
successor to Debian Buster is released)


Then we can require new GCCs whenever we want, as long as the old 
clangs suffice. Ubuntu 18.04 has clang 6.0, for instance, so as long as 
clang 6.0 works, then we can advance to GCC 8 whenever desired. Debian 
Buster has clang 7.0, so come April 2021 we'd be able to require that. 
But one of the system compilers would need to work for the full three 
years. Then the long support period for libstdc++ is required to make 
sure our users don't get cut off from security updates. There's no way 
around that: if we want to require newer standard libraries, then our 
users will no longer receive updates, period.


Is this OK?

OTOH, GCC 6 has partial support of C++17 [2,3] under -std=c++1z, 
which might be sufficient for now.


Beware that GCC 9, released yesterday, is the first version in which 
C++ 17 support is no longer experimental. Most things should work in 
GCC/libstdc++ 7, but as always, there's going to be bugs that we're 
going to have to live with.


Michael


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


Re: [webkit-dev] Spam and indexing

2019-05-02 Thread Michael Catanzaro

On Thu, May 2, 2019 at 4:32 PM, Darin Adler  wrote:
For example, can someone without administration privileges do the 
right thing?


Nope.


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


Re: [webkit-dev] Spam and indexing

2019-04-22 Thread Michael Catanzaro
On Mon, Apr 22, 2019 at 11:06 AM, Konstantin Tokarev 
 wrote:
Another possible way is to disable self-registration for new users, 
similarly

to what LLVM project did [1].


GCC Bugzilla did this a long time ago.

It will make it really hard to convince users to report bugs. I would 
try deindexing first, since it's a smaller hammer. Then we could try 
this if that fails.


Michael


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


Re: [webkit-dev] Spam and indexing

2019-04-22 Thread Michael Catanzaro
Not indexing bugs.webkit.org will be sad for people who won't be able 
to find bugs they may be interested in via search engines... but those 
people are probably not WebKit developers working with WebKit on a 
daily basis. For us, it's just annoying to deal with the spam. I would 
turn off the indexing if we think it could make a difference.




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


Re: [webkit-dev] Spam and indexing

2019-03-29 Thread Michael Catanzaro
On Thu, Mar 28, 2019 at 3:57 PM, Alexey Proskuryakov  
wrote:

2. Block indexing completely.

Seems like no one was bothered by lack of indexing on new bugs so far.


Spam problem seems worse than not being indexed.

If you want to search for WebKit bugs, you can do that on WebKit 
Bugzilla, right?


Michael


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


Re: [webkit-dev] webkitgtk 2.22.6 tarball inaccessible

2019-03-22 Thread Michael Catanzaro



Looks like a permissions mistake. We'll investigate.

Michael


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


Re: [webkit-dev] -Wpessimizing-move and -Wredundant-move

2019-03-19 Thread Michael Catanzaro
Several more return WTFMove() cases were committed just between 
yesterday and today. Please be careful. :)


On Tue, Mar 19, 2019 at 8:01 AM, Emilio Cobos 
=?iso-8859-1?q?=C1lvarez?=  wrote:
In Gecko, when I switched from mozilla::Move to std::move [1], I had 
to

disable the warning and fix all of them in a followup, since clang
didn't use to warn about them.


We used to have WTF::move defined as a function, but now it's a #define 
to ensure std::move gets called directly. I think that's what Andy 
meant when he says "WTFMove was written to accommodate these warnings."


Michael


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


Re: [webkit-dev] -Wpessimizing-move and -Wredundant-move

2019-03-19 Thread Michael Catanzaro
On Tue, Mar 19, 2019 at 12:57 AM, Tomas Popela  
wrote:
If a note from 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=dc06c8f4989fc28d0c31ebd333e53dfe0e0f5f66 
applies, then you can't fix it until we support Ubuntu 14.04 (due to 
its old gcc version):


Turns out the
std::move can only be dropped if the compiler has a fix for CWG1579.  
For GCC

that's the case starting with GCC 5.1


Currently we require GCC 6 to build, and if we follow our dependencies 
policy we'll be able to require GCC 7 next month, so that should be no 
problem.



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


Re: [webkit-dev] -Wpessimizing-move and -Wredundant-move

2019-03-18 Thread Michael Catanzaro

On Mon, Mar 18, 2019 at 4:43 PM, Andy Estes  wrote:
FWIW, Apple’s ports use the equivalent clang warning for 
pessimizing and redundant moves, and we cleaned up a bunch of these 
mistakes in our ports a few years ago. Hopefully you aren’t finding 
any of these mistakes in shared code.


There are a lot, actually. Maybe clang only has -Wpessimizing-move 
(which caused relatively few warnings) and not -Wredundant-move (which 
caused very many). I'm not actually sure what the difference is; in 
both cases, a local variable is cast to rvalue reference via std::move 
before it is returned.


Anyway: patch in https://bugs.webkit.org/show_bug.cgi?id=195920, review 
appreciated. That patch also fixes several -Wdeprecated-copy warnings 
and a couple -Wclass-memaccess, but the vast majority is just removing 
WTFMove().



(WTFMove was written to accommodate these warnings, in fact.)

Really glad you’re turning these warnings on!


Note we actually haven't changed our warning flags, they're just new 
warnings enabled by -Wextra, and we've always used -Wextra. So let's 
thank the GCC developers. Each new GCC is a ruined day for me whenever 
I try to make WebKit build cleanly, but the warnings are worth it.


Michael


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


[webkit-dev] -Wpessimizing-move and -Wredundant-move

2019-03-18 Thread Michael Catanzaro

Hi,

GCC 9 has new -Wpessimizing-move ("warning: moving a local object in a 
return statement prevents copy elision") and -Wredundant-move 
("warning: redundant move in return statement") warnings. These are 
enabled by -Wextra (which we use) and will be triggered by code like:


return WTFMove(foo);

when foo is a copyable type. This idiom is only appropriate if foo is a 
noncopyable (move-only) type. We have many, many instances of such 
code. I'm trying to fix them. Please don't add more! (It's easy enough 
to disable the warnings, but they're there for a reason.)


Thanks,

Michael


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


Re: [webkit-dev] Queries regarding few Components in webkit

2019-03-17 Thread Michael Catanzaro

Hi,

It might be more realistic to try making an existing WebKit port work 
on Haiku (either WebKitGTK or WPE WebKit) rather than try to create an 
entirely new port.


Previously you indicated that you were planning to create a new network 
backend for Haiku; that alone would be enough to occupy a developer 
full-time for a long while and doesn't seem very realistic. But that's 
just one small portion of developing and maintaining an entire WebKit 
port. Taking an existing port and making it run on Haiku would be much 
easier.


On Sun, Mar 17, 2019 at 7:38 AM, Rajagopalan Gangadharan 
 wrote:

What is a WKRetainPtr ? where can I use it?


It's a smart pointer for holding ownership of C API types, which you 
shouldn't be using. The C API is not stable and is slowly being 
retired. If you really don't want to use WebKitGTK or WPE WebKit, then 
you should create your own separate public API based on WebKit 
internals, not based on the C API. If you use the C API, your port will 
be difficult to maintain in the long run.


What is WKContext and WKView (I think Webview is different from 
WKView) -> as far my understanding is Context like the context menu 
an os offers (ie right clicking provides copy,paste etc.)


No, it's a library context object (corresponding to WebProcessPool). If 
you have two web contexts, you effectively have two separate instances 
of WebKit (e.g. separate NetworkProcess, separate data storage 
directories, separate everything) to avoid shared global state.



and View is where rendering takes place?


This is correct.

Good luck,

Michael


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


Re: [webkit-dev] PSA: WebCore::Quirks should define the logic to determine if a particular site specific quirk is needed or not

2019-03-12 Thread Michael Catanzaro

On Tue, Mar 12, 2019 at 9:42 PM, Ryosuke Niwa  wrote:
On that note, I'd appreciate if someone who maintains PlayStation / 
Windows ports could cleanup standardsUserAgentForURL to use 
WebsitePolicies in WebKit layer instead of having the logic in 
WebCore.


Looks like standardUserAgentForURL is a stub for both PlayStation and 
Windows? Only the UserAgentGLib.cpp implementation of 
standardUserAgentForURL actually calls into UserAgentQuirks.cpp. What 
exactly are you hoping to have changed?


If anyone seriously looks into changing user agent quirks, it would be 
a good time to try investigating 
https://bugs.webkit.org/show_bug.cgi?id=191858 as well.


Michael

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


Re: [webkit-dev] Rename AtomicString to AtomString

2019-03-04 Thread Michael Catanzaro


On Wed, Jan 30, 2019 at 1:38 PM, Adrian Perez de Castro 
 wrote:

Hi,

On Wed, 30 Jan 2019 08:31:49 -0800, Darin Adler  
wrote:


 So, did we reach consensus that we should rename AtomicString to 
AtomString?


Let's go with it 


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

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


Re: [webkit-dev] Reminder regarding formatting uint64_t

2019-02-27 Thread Michael Catanzaro

On Wed, Feb 27, 2019 at 6:05 PM, Keith Rollin  wrote:

The underlying Cocoa os_log facility


Yeah this is really interesting too. RELEASE_LOG is Cocoa-specific, 
because it's only backed by os_log. So when you change debug LOGs to 
RELEASE_LOG, you're removing the logging for other platforms. I wonder 
if we should change that.


is able to greatly compress the logs stored in memory and on disk, as 
well as get corresponding performance benefits, by taking advantage 
of the fact that the formatting string is a literal that can be found 
in the executable’s binary image. When you log with a particular 
formatting string, that string is not included in the log archive, 
but a reference to it is. In the case that Michael gives, a reference 
to the big formatting string is stored along with the pointer, the 
unsigned long long, and the integer. In the above example, a 
reference to “%s” is stored, along with the fully-formatted 
string. This latter approach takes up a lot more memory.


Wow.

Michael

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


[webkit-dev] Reminder regarding formatting uint64_t

2019-02-27 Thread Michael Catanzaro

Hi,

For the past several years, I've been regularly fixing -Wformat 
warnings that look like this:


../../Source/WebKit/WebProcess/WebPage/WebPage.cpp:3148:46: warning: 
format ‘%llu’ expects argument of type ‘long long unsigned 
int’, but argument 6 has type ‘uint64_t’ {aka ‘long unsigned 
int’} [-Wformat=]
RELEASE_LOG_ERROR(ProcessSuspension, "%p - WebPage 
(PageID=%llu) - LayerTreeFreezeReason::ProcessSuspended was set when 
removing LayerTreeFreezeReason::PageTransition; current reasons are %d",
 
^~

this, m_pageID, m_LayerTreeFreezeReasons.toRaw());
  

Problem is that uint64_t is long long unsigned int on Mac, but only 
long unsigned int on Linux. It can't be printed with %llu, so please 
use PRIu64 instead. E.g.:


LOG("%llu", pageID); // wrong
LOG("%" PRIu64, pageID); // correct

This is good to keep in mind for any sized integer types, but uint64_t 
in particular since this is what causes problems for us in practice.


Thanks,

Michael

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


Re: [webkit-dev] Code Style: Opinion on returning void

2019-02-20 Thread Michael Catanzaro
On Wed, Feb 20, 2019 at 12:33 PM, Simon Fraser  
wrote:
I find it mind bending. It makes me wonder if the author made a 
coding error.


Yeah me too. It does seem to work nicely in Alex's CompletionHandler 
example, but still, I'd just add braces and return on an extra line if 
I was writing it.


Anyway, it seems we don't have any consensus here, so no need to create 
a rule.


Michael

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


Re: [webkit-dev] Moving to Git

2019-02-20 Thread Michael Catanzaro
FWIW, it's not hard to enforce fast-forward merges with a git hook; 
that way, we can guarantee that the history has no merge commits and is 
fully linear. GitLab has built-in support to enforce this for merge 
requests (though not for direct commits). I agree that linear history 
is a must for a project the size of WebKit. rNN tags would be nice, 
but hardly essential as long as the history is linear.


On Wed, Feb 20, 2019 at 1:38 PM, Bug Tracker 
 wrote:
I considered this option, but my work will involve touching multiple 
parts of the codebase and thus I would like to be able to keep up / 
merge locally with the upstream every now and then (e.g. on each 
relatively stable release, such as Apple's Safari Technology Preview).


However, all branches, tags etc. are available only on SVN.


Migrating to git would be wonderful, but a huge amount of 
infrastructure effort. Since it's unlikely that anyone is going to 
invest the large amount of effort required to transition WebKit to git 
anytime soon, I'd recommend learning how to work with git-svn. It's a 
bit of effort but not too hard, and way better than using Subversion 
directly.


Michael

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


Re: [webkit-dev] Experimental features review

2019-02-14 Thread Michael Catanzaro



No strong opinion from me here. I'm not familiar with how Safari's UI 
exposes some features but not others. In the GTK/WPE API, the features 
are not enumerable and only a few selected features are exposed at all, 
so that's not an issue for us.


I do think we have a semantic issue, though, if some features 
considered "experimental" are enabled by default. Not sure what the 
solution is. (And of course, if we change our experimental features 
policy, we'll want to ensure the comment in the WebPreferences.yaml 
file is updated.)


Michael

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


Re: [webkit-dev] Experimental features review

2019-02-14 Thread Michael Catanzaro
On Wed, Feb 13, 2019 at 9:16 PM, Simon Fraser  
wrote:
For these two, we now have them on by default because we think they 
are ready to ship. They still exist as experimental features so that 
people can turn them off for regression testing, but is the policy 
now to move them back to Debug features at this stage?


Well, I'm really not sure, other than that the feature is no longer 
supposed to be experimental once it's ready to be on by default.


I notice there is a new class of features called internal features:
https://trac.webkit.org/changeset/235921/webkit. Perhaps that would 
suffice for regression testing?


Michael

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


[webkit-dev] Experimental features review

2019-02-13 Thread Michael Catanzaro

Hi,

Last year, we cleaned up experimental features in WebPreferences.yaml 
to ensure no experimental features were enabled by default. Since then 
we have regressed a bit when enabling cool new web features. :) 
Currently we have 12 offenders, listed below. Most likely, the 
category: experimental line should be removed from these features. 
Alternatively, the defaultValue should be changed to either false or 
DEFAULT_EXPERIMENTAL_FEATURES_ENABLED (or something depending on that).


If you know about any of these settings, please keep reading and help 
decide what to do with them:


BlankAnchorTargetImpliesNoOpenerEnabled
ThirdPartyIframeRedirectBlockingEnabled
ScreenCaptureEnabled
WebRTCUnifiedPlanEnabled
WebRTCVP8CodecEnabled
WebRTCH264SimulcastEnabled
WebRTCMDNSICECandidatesEnabled
IntersectionObserverEnabled
VisualViewportAPIEnabled
DarkModeCSSEnabled
WebSQLDisabled
ProcessSwapOnCrossSiteNavigationEnabled

Details:

BlankAnchorTargetImpliesNoOpenerEnabled:
  type: bool
  defaultValue: true
  webcoreBinding: RuntimeEnabledFeatures
  humanReadableName: "Blank anchor target implies rel=noopener"
  humanReadableDescription: "target=_blank on anchor elements implies 
rel=noopener"

  category: experimental

ThirdPartyIframeRedirectBlockingEnabled:
  type: bool
  defaultValue: true
  humanReadableName: "Block top-level redirects by third-party iframes"
  humanReadableDescription: "Block top-level redirects by third-party 
iframes"

  category: experimental

ScreenCaptureEnabled:
 type: bool
 defaultValue: true
 webcoreBinding: RuntimeEnabledFeatures
 condition: ENABLE(MEDIA_STREAM) && PLATFORM(MAC)
 humanReadableName: "ScreenCapture"
 humanReadableDescription: "Enable ScreenCapture"
 category: experimental

WebRTCUnifiedPlanEnabled:
 type: bool
 defaultValue: true
 webcoreBinding: RuntimeEnabledFeatures
 condition: ENABLE(WEB_RTC)
 humanReadableName: "WebRTC Unified Plan"
 humanReadableDescription: "Use WebRTC Unified Plan"
 category: experimental

WebRTCVP8CodecEnabled:
 type: bool
 defaultValue: true
 webcoreBinding: RuntimeEnabledFeatures
 condition: ENABLE(WEB_RTC)
 humanReadableName: "WebRTC VP8 codec"
 humanReadableDescription: "Enable WebRTC VP8 codec"
 category: experimental

WebRTCH264SimulcastEnabled:
 type: bool
 defaultValue: true
 webcoreBinding: RuntimeEnabledFeatures
 condition: ENABLE(WEB_RTC)
 humanReadableName: "WebRTC H264 Simulcast"
 humanReadableDescription: "Enable WebRTC H264 Simulcast"
 category: experimental

WebRTCMDNSICECandidatesEnabled:
 type: bool
 defaultValue: true
 humanReadableName: "WebRTC mDNS ICE candidates"
 humanReadableDescription: "Enable WebRTC mDNS ICE candidates"
 webcoreBinding: RuntimeEnabledFeatures
 category: experimental
 condition: ENABLE(WEB_RTC)

If the above features are to remain experimental, they should be sorted 
lower in the file, below this comment explaining experimental feature 
policy:


# For experimental features:
# The type should be boolean.
# You must provide a humanReadableName and humanReadableDescription for 
all experimental features. They

# are the text exposed to the user from the WebKit client.
# The default value may be either false (for unstable features) or
# DEFAULT_EXPERIMENTAL_FEATURES_ENABLED (for features that are ready for
# wider testing).

More offenders:

IntersectionObserverEnabled:
 type: bool
 defaultValue: true
 humanReadableName: "Intersection Observer"
 humanReadableDescription: "Enable Intersection Observer support"
 webcoreBinding: RuntimeEnabledFeatures
 category: experimental
 condition: ENABLE(INTERSECTION_OBSERVER)

VisualViewportAPIEnabled:
 type: bool
 defaultValue: true
 humanReadableName: "Visual Viewport API"
 humanReadableDescription: "Enable Visual Viewport API"
 category: experimental

DarkModeCSSEnabled:
 type: bool
 defaultValue: true
 humanReadableName: "Dark Mode CSS Support"
 humanReadableDescription: "Enable Dark Mode CSS Support"
 webcoreBinding: RuntimeEnabledFeatures
 category: experimental
 condition: ENABLE(DARK_MODE_CSS)

WebSQLDisabled:
 type: bool
 defaultValue: true
 humanReadableName: "Disable Web SQL"
 humanReadableDescription: "Disable Web SQL"
 webcoreBinding: RuntimeEnabledFeatures
 category: experimental

This one's weird because it's Disabled rather than Enabled... the 
semantics should probably be reversed. We probably want a WebSQLEnabled 
feature defaulting to false?


ProcessSwapOnCrossSiteNavigationEnabled:
 type: bool
 defaultValue: DEFAULT_PROCESS_SWAP_ON_CROSS_SITE_NAVIGATION_ENABLED
 humanReadableName: "Swap Processes on Cross-Site Navigation"
 humanReadableDescription: "Swap WebContent processes on cross-site 
navigations"

 category: experimental
 webcoreBinding: none

DEFAULT_PROCESS_SWAP_ON_CROSS_SITE_NAVIGATION_ENABLED is TRUE on macOS 
and iOS, bypassing DEFAULT_EXPERIMENTAL_FEATURES_ENABLED.


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


Re: [webkit-dev] Tools/TestWebKitAPI

2019-02-05 Thread Michael Catanzaro

On Tue, Feb 5, 2019 at 4:01 PM, ross.kirsl...@sony.com wrote:
That said, I would expect specifically the Tools/TestWebKitAPI/Tests 
subdirectory to be the thing moved to APITests/, since the code that 
actually runs the tests is as much a “tool” as DRT, WKTR, or 
various other test-running scripts under

 Tools/Scripts are.


I dunno, we could do it either way, but there's value in keeping 
related code together. E.g. our tests subclass lots of TestWebKitAPI 
classes, so we'd have code in APITests/ subclassing stuff under 
Tools/TestWebKitAPI/. It's much more tightly-coupled than, say, the 
layout tests are to TestController/WKTR, which communicates with layout 
tests over well-defined interfaces. In contrast, our API tests really 
depend on implementation details of TestWebKitAPI and they often have 
to be changed in tandem.


Michael

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


[webkit-dev] Tools/TestWebKitAPI

2019-02-05 Thread Michael Catanzaro

Hi,

I started writing this mail to propose creating a separate ChangeLog 
for Tools/TestWebKitAPI, to make the Tools/ ChangeLog more focused on, 
you know, actual tools. So many of my changes under Tools/ are to the 
API tests.


But this reminded me that TestWebKitAPI is the only testsuite we have 
under Tools/. All the rest are toplevel directories:


JSTests/
LayoutTests/
ManualTests/
PerformanceTests/
WebDriverTests/
WebPlatformTests/

So it almost doesn't fit under Tools/ at all, right? Would there be any 
objections to moving it to a toplevel WebKitAPITests/ or just APITests/ 
directory? That would nicely parallel all our other tests.


(The practical objection is that moving anything is difficult for 
someone without familiarity with both XCode and CMake. I'd only be able 
to help with the CMake portion of the move. And then Apple internal 
build will inevitably break too, so someone would need to volunteer to 
care for that.)


If we don't want to move it, I guess a new ChangeLog file would be 
fine? :)


Michael

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


Re: [webkit-dev] WebKit2 owners help for GTK and WPE

2019-02-04 Thread Michael Catanzaro



Also:

[GTK] Implement back/forward touchpad gesture
https://bugs.webkit.org/show_bug.cgi?id=193919

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


[webkit-dev] More suggested Bugzilla component renames

2019-02-01 Thread Michael Catanzaro

WebKit Gtk -> WebKitGTK+ (or just WebKitGTK if the + is not allowed)
WebKit WPE -> WPE WebKit

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


Re: [webkit-dev] Reducing globals

2019-01-30 Thread Michael Catanzaro

Sorry again for the delay. I've started here:

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

That covers the first two out of six parameters. I'll do 
CookieAcceptPolicy next, separately, since it requires modifying 
cross-platform stuff to do properly. And then the second half.


Michael

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


Re: [webkit-dev] Rename AtomicString to AtomString

2019-01-30 Thread Michael Catanzaro



On Wed, Jan 30, 2019 at 10:31 AM, Darin Adler  wrote:
So, did we reach consensus that we should rename AtomicString to 
AtomString?


+1 from me, it seems like a much less confusing name.

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


Re: [webkit-dev] libsoup and libcurl networking implementations

2019-01-19 Thread Michael Catanzaro



I just started on reducing use of NetworkProcessCreationParameters, 
which is a little trickier than I was expecting. 
(WebCore::SoupNetworkSession vs. WebKit::NetworkSessionSoup: confusing 
much?)


I'll look into this too, since it's related.

Michael

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


Re: [webkit-dev] Compile error in WebGL2RenderingContext.cpp

2019-01-17 Thread Michael Catanzaro
On Thu, Jan 17, 2019 at 1:13 PM, Maciej Stachowiak  
wrote:

std::array is fixed size.


Er, yeah, oops. Size must be known at compile time, so it can't be used 
to replace a VLA. Vector it is


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


  1   2   3   4   >