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


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

2019-01-17 Thread Michael Catanzaro



On Thu, Jan 17, 2019 at 11:12 AM, Darin Adler  wrote:
Vector’s inline capacity feature was originally created as an 
alternative to variable length arrays for most of the purposes people 
would want to put them.


Any advantages of this over std::array (which is widely-used in WebKit)?

___
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 2:27 AM, Salisbury, Mark 
 wrote:

Thanks Tim!



I didn’t know about C++ variable length arrays.  That makes perfect 
sense now.




Looks like people have been requesting Visual Studio add support for 
VLAs; there are no indications they will be supported.


We shouldn't be using VLAs in WebKit. It's not standard C++, and even 
if it was, it's not safe. The code should use std::array or perhaps 
WTF::Vector.


Michael

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


Re: [webkit-dev] Lots of spam on Bugzilla

2019-01-15 Thread Michael Catanzaro
On Wed, Dec 5, 2018 at 11:30 AM, Michael Catanzaro 
 wrote:
Wow, I never noticed this. I thought Apple folks were using 
superpowers to obsolete comments!


Hi,

Recently a spammer added me to his Bugzilla user watchlist (Preferences 
-> Email Preferences -> User Watching on the bottom left) to follow me 
across Bugzilla, and has been manually sending me spam emails. I 
suppose it's retaliation for my tagging several Bugzilla comments as 
Spam, now that I know how. (I've asked the WebKit admins to ban his 
account.) Hopefully I'm just unlucky, but you might want to check the 
list of accounts watching you for suspicious accounts!


Michael

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


Re: [webkit-dev] Reducing globals

2019-01-15 Thread Michael Catanzaro

This:

On Thu, Nov 29, 2018 at 8:15 PM, Alex Christensen 
 wrote:
Specifically, I’m looking into reducing the number of members in 
the NetworkProcessCreationParameters structure.  Many of them need to 
go to NetworkSessionCreationParameters instead.  Could those 
maintaining the libsoup and libcurl networking implementations please 
lend a hand and move the members enclosed in USE(SOUP) or USE(CURL)?  
I have done similar moves in 
https://trac.webkit.org/changeset/238654/webkit and 
https://trac.webkit.org/changeset/238630/webkit if you would like a 
pattern to follow.


I'll try.

Michael

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


Re: [webkit-dev] JSCOnly bots on dashboard

2019-01-03 Thread Michael Catanzaro
On Wed, Jan 2, 2019 at 1:54 PM, Yusuke Suzuki 
 wrote:
This is because of old ICU. In old ICU, Intl.NumberFormats does not 
work.

Intl feature usually requires very new ICU.

IIRC, the similar issue happened in test262, and Ross skipped them.
I think we should put the condition in the tests that checks the ICU 
version.


We have ICU 63 in the GTK jhbuild environment though, so that's the ICU 
version we're guaranteed to have when running tests. FWIW I see the 
same failures locally when I run:


$ run-webkit-tests --gtk js/intl-numberformat.html

The actual results actually look slightly better to me than the 
expected results.


Michael

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


[webkit-dev] JSCOnly bots on dashboard

2019-01-02 Thread Michael Catanzaro

Hi,

I've updated https://build.webkit.org/dashboard/ to show our JSCOnly 
bots in addition to WPE and GTK, so we can monitor the health of these 
bots. Tip: disable all but the Linux ports in the upper-left to make 
the page load faster. Current status is:


* 90 failures on aarch64
* ARMv7 thumb2 and ARMv7 thumb2 softfp are GREEN! :)
* ARMv7 traditional fails to build
* 2 failures on MIPSel (one is flaky)

Also:

* 1 flaky JSC test on WPE
* 7-8 JSC failures on GTK

I promised to do this... what, half a year ago? Better late than never!

Michael

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


[webkit-dev] Hash table empty value

2018-12-19 Thread Michael Catanzaro

On Tue, Dec 18, 2018 at 2:31 PM, Ryosuke Niwa  wrote:
I tend to agree but then we'd come up with other numbers for the 
empty & deleted values.
I've been thinking that we could use -1 and -2 but that's also 
somewhat arbitrary restriction.


Using min/max values seems much safer. E.g. we already have in 
HashTraits.h:


// Default unsigned traits disallow both 0 and max as keys -- use these 
traits to allow zero and disallow max - 1.
template struct UnsignedWithZeroKeyHashTraits : 
GenericHashTraits {

   static const bool emptyValueIsZero = false;
   static T emptyValue() { return std::numeric_limits::max(); }
   static void constructDeletedValue(T& slot) { slot = 
std::numeric_limits::max() - 1; }
   static bool isDeletedValue(T value) { return value == 
std::numeric_limits::max() - 1; }

};

And:

template struct SignedWithZeroKeyHashTraits : 
GenericHashTraits {

   static const bool emptyValueIsZero = false;
   static T emptyValue() { return std::numeric_limits::min(); }
   static void constructDeletedValue(T& slot) { slot = 
std::numeric_limits::max(); }
   static bool isDeletedValue(T value) { return value == 
std::numeric_limits::max(); }

};

Which both seem much safer than the current default:

// Default integer traits disallow both 0 and -1 as keys (max value 
instead of -1 for unsigned).
template struct GenericHashTraitsBase : 
GenericHashTraitsBase {

   static const bool emptyValueIsZero = true;
   static void constructDeletedValue(T& slot) { slot = 
static_cast(-1); }
   static bool isDeletedValue(T value) { return value == 
static_cast(-1); }

};

Michael

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


Re: [webkit-dev] the name "AtomicString"

2018-12-19 Thread Michael Catanzaro

On Tue, Dec 18, 2018 at 9:31 PM, Darin Adler  wrote:
I’ve gotten used to the name AtomicString over the years, but I 
wouldn’t strongly object to changing it if other programmers are 
often confused by it’s similarity to the term “atomic 
operations”.


Well there were two other developers in the thread Ryosuke linked to 
who made the exact same mistake as me, so I do think the current name 
is problematic. A change wouldn't need to be drastic, though. I think 
suggestions from the old thread like "StringAtom" or "AtomString" would 
be unproblematic. The problem is the specific word "atomic" carries an 
expectation that the object be safe to access concurrently across 
threads without locks; I think that expectation doesn't exist if not 
for the "ic" at the end.


FWIW I've only ever heard the "interned string" terminology prior to 
now.


Michael

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


Re: [webkit-dev] 'final' class specifier and 'final' method specifier

2018-12-19 Thread Michael Catanzaro
On Wed, Dec 19, 2018 at 1:58 PM, Konstantin Tokarev  
wrote:
Adding override to method which already has final specifier doesn't 
affect anything,

because both final and override may ony be used on virtual methods


FWIW I prefer override because it's much more clear what that keyword 
is used for.


Michael

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


Re: [webkit-dev] Watch out for std::optional's move constructor

2018-12-18 Thread Michael Catanzaro

I know I'm getting a bit far afield here, but:

On Mon, Dec 17, 2018 at 9:26 PM, Ryosuke Niwa  wrote:
But then our behavior of HashMap which doesn't accept the POD 
integral value of 0 as a key


This behavior is really unexpected and dangerous [1], and we should 
seriously consider changing it. No doubt lots of bugs caused by this 
are just waiting to be uncovered. I've been working on WebKit since 
2014 and didn't know about this until last month.


Another oddity: I recently learned that AtomicStrings are actually 
interned strings. WTF. Why not call them that? I had thought for years 
that they were strings safe to be shared across threads, like other 
atomics. Not at all. Maybe this was dumb of me, but it could have been 
avoided by better naming.


Michael

[1] https://trac.webkit.org/changeset/238407/webkit

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


Re: [webkit-dev] What goes in FeatureDefines.xcconfig

2018-12-12 Thread Michael Catanzaro

On Mon, Dec 10, 2018 at 5:49 PM, don.olmst...@sony.com wrote:
Recently I did some work around syncing the contents of 
FeatureDefines.xcconfig and WebKitFeatures.cmake, 
https://bugs.webkit.org/show_bug.cgi?id=191167 . Michael mentioned 
someone noticing that ENABLE(RESOURCE_LOAD_STATISTICS) didn’t end 
up in that list. I did some digging and saw that it ended up in 
Platform.h, https://bugs.webkit.org/show_bug.cgi?id=189959 . So what 
I’m wondering is what is the criteria for something being in 
FeatureDefines.xcconfig and whether ENABLE_RESOURCE_LOAD_STATISTICS 
meets it


I just found wtf/FeatureDefines.h. Didn't know this existed.

Good grief, we have quite a mess here. Define your features in 
WebKitFeatures.cmake, FeatureList.pm, twenty FeatureDefines.xcconfig 
files, Platform.h, FeatureDefines.h


I think we can get rid of FeatureDefines.h and the vast majority of the 
defines in Platform.h. (I guess some will need to be kept where the 
logic required is more than a simple boolean, too complex for XCode.) 
WebKitFeatures.cmake and FeatureDefines.xcconfig we are stuck with, 
because those are needed for users to be able to configure the build. 
Then FeatureList.pm is questionable. It's a convenience to be able to 
easily pass flags to build-webkit, but this can also be done at the 
CMake or XCode levels, and I don't think it's worth the cost at all. So 
ideally we would have just WebKitFeatures.cmake and the 
FeatureDefines.xcconfig family of files that have to be manually kept 
in sync.


...unless am I missing something? Thoughts?

Michael

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


Re: [webkit-dev] Lots of spam on Bugzilla

2018-12-05 Thread Michael Catanzaro



On Wed, Dec 5, 2018 at 10:44 AM, ross.kirsl...@sony.com wrote:
You can click Tag and enter "spam". (There's also the "obsolete" tag 
for hiding, say, outdated feedback from the EWS bots. Unfortunately 
tagging is purely by manual entry right now, but it works.)


Wow, I never noticed this. I thought Apple folks were using superpowers 
to obsolete comments!


If we add rel="nofollow" then I think we should also respond with 
comments warning the spammers that we are using rel="nofollow" and 
their spam will not boost their SEO. Maybe that will convince 
individual spammers to give us a break.


Michael

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


Re: [webkit-dev] Lots of spam on Bugzilla

2018-12-05 Thread Michael Catanzaro



On Tue, Dec 4, 2018 at 7:47 PM, Alexey Proskuryakov  
wrote:

Anyone can tag comments to make them invisible


How?

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


Re: [webkit-dev] Remove HAVE_ACCESSIBILITY

2018-11-14 Thread Michael Catanzaro
On Wed, Nov 14, 2018 at 7:49 PM, Fujii Hironori 
 wrote:

 No, it isn't high. It is no problem to keep the code.

CMake defines the similar name macro ENABLE_ACCESSIBILITY=0 in 
generated cmakeconfig.h.


  
https://trac.webkit.org/browser/webkit/trunk/Source/cmake/WebKitFeatures.cmake#L88


This confuses me. I want to fix.


I would remove the flag if it's enabled for all ports.

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


Re: [webkit-dev] Is gperf really needed when building the JSCOnly with CMake?

2018-10-01 Thread Michael Catanzaro
On Sun, Sep 30, 2018 at 7:29 PM, Konstantin Tokarev  
wrote:

Or, better, if (ENABLE_WEBCORE)


Yeah, that's better
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Is gperf really needed when building the JSCOnly with CMake?

2018-09-30 Thread Michael Catanzaro


Yeah, I'd just put it in an if (NOT ${PORT} STREQUAL "JSCOnly")

(writing that off the top of my head, probably somehow wrong)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] [jsc-dev] Proposal: Using LLInt Asm in major architectures even if JIT is disabled

2018-09-20 Thread Michael Catanzaro

On Thu, Sep 20, 2018 at 12:02 PM, Filip Pizlo  wrote:
- Enable cloop/JSVALUE64 to work on 32-bit.  I don’t think it does 
right now, but that’s probably trivial to fix.

- Switch Darwin ports to that configuration for 32-bit.
- When changes land to support new features, make it mandatory to 
support JSVALUE64 and optional to support JSVALUE32_64.  Such changes 
should include whoever volunteers to maintain JSVALUE32_64 in CC.


If you guys consider JSVALUE32_64 to be critical, then you can go 
ahead and maintain it.  We’ll let JSVALUE32_64 stay in the tree so 
long as someone is maintaining it.


Yes that's fine with us. I think that's the previous agreement, anyway. 
:)


Michael

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


Re: [webkit-dev] [jsc-dev] Proposal: Using LLInt Asm in major architectures even if JIT is disabled

2018-09-20 Thread Michael Catanzaro



I believe Guillaume has previously established that results in a 
substantial performance regression for WPE. It is currently running in 
production on tens of millions of consumer set top boxes. I think 
that's substantial testing. :)


Michael

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


Re: [webkit-dev] Proposal: macros to explicitly ignore warnings

2018-08-28 Thread Michael Catanzaro
On Tue, Aug 28, 2018 at 11:47 AM, Guillaume Emont 
 wrote:

  PRAGMA_IGNORE_WARNING_CLANG("-Wfoo-bar")
  // Code that triggers the warning.
  PRAGMA_IGNORE_WARNING_CLANG_END("-Wfoo-bar")


Maybe:

PRAGMA_IGNORE_CLANG_WARNING("-Wfoo-bar")

? That reads slightly better to me.

FWIW I think this is great.

Michael

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


Re: [webkit-dev] Bugzilla component for CMake

2018-08-24 Thread Michael Catanzaro



On Fri, Aug 24, 2018 at 12:23 PM, Lucas Forschler 
 wrote:

Done!
Lucas


I'm afraid you'll likely be hearing from me a lot less now!

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


[webkit-dev] Bugzilla component for CMake

2018-08-24 Thread Michael Catanzaro

Hi,

I think it would be useful to have a Bugzilla component for CMake build 
system changes.


We have a lot of such bugs, and normally use the Tools/Tests component 
for them currently, which is not a great fit (and causes Lucas to be 
CCed unnecessarily on a bunch of bugs ;)


Michael

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


Re: [webkit-dev] Proposal: Not supporting x86 w/o SSE2

2018-08-04 Thread Michael Catanzaro



Technically, many of WebKitGTK+'s distributors require that it not use 
SSE2 instructions in 32-bit builds. I am no longer sure which ones. (It 
used to be the case for Fedora, for example, but that changed recently.)


In practice, so few people care about these old machines anymore that 
such use is unlikely to be noticed by many users. Certain software 
(including Firefox and Chromium) has already started to require SSE2 
and is broken on these machines, so the requirement is already not 
fulfilled by other software. E.g. it is clear that Debian is not 
patching Firefox or Chromium to remove the SSE2 instructions.


So times change, and I think we can get away with starting to require 
SSE2, if there is a compelling reason to do so. But according to 
Filip's review in that bug, we probably don't need to do so right now.


Michael

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


[webkit-dev] Fujii Hironori is now a WebKit reviewer

2018-07-14 Thread Michael Catanzaro

Hi,

Fujii Hironori is now a WebKit reviewer. He has expertise in Windows 
support, WebKitGTK+, and WebCore bugs. Please congratulate him and send 
him patches to review!


Michael

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


Re: [webkit-dev] JavaScriptCore on Fuchsia

2018-06-27 Thread Michael Catanzaro
On Tue, Jun 26, 2018 at 6:49 PM, Yusuke SUZUKI  
wrote:
My suggestion is introducing Fushcia port, adding both 
PLATFORM(FUSHCIA) and OS(FUSHCIA) ifdefs.
Use OS(FUSHCIA) when the change is b/c of Fushcia's APIs. And use 
PLATFORM(FUSHCIA) to change
the policy of the released build (e.g. enabling / disabling FTL JIT 
etc.).
By doing so, JSCOnly port also becomes available in Fushcia. And it 
means that Fushcia port can benefit

from JSCOnly port's work for making WTF and JSC portable.


I wonder if PLATFORM(FUSHCIA) is even needed? Maybe OS(FUSHCIA) would 
suffice? Then instead of a separate Fushcia port, we would just have 
the existing JSCOnly port running on Fuschia.


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


Re: [webkit-dev] Experimental features enabled by default

2018-06-27 Thread Michael Catanzaro
On Wed, Jun 27, 2018 at 1:00 PM, Tim Horton  
wrote:

Alright, how’s it looking now? :)


Good, thanks for taking care of this, Tim!

Michael

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


Re: [webkit-dev] Experimental features enabled by default

2018-06-26 Thread Michael Catanzaro



Hi,

We're a lot closer after r233227!

There is still IsSecureContextAttributeEnabled. Shall we switch the 
default value of that one to use DEFAULT_EXPERIMENTAL_FEATURES_ENABLED 
instead of true?


We should also move CSSAnimationTriggersEnabled to the experimental 
features section of the file, and add the category tag. 
FullScreenEnabled and EncryptedMediaAPIEnabled should also be moved 
down in the file.


Then we can just update the comment to indicate that custom values like 
DEFAULT_SERVICE_WORKERS_ENABLED are fine as long as they're thoughtful 
and consider ENABLE(EXPERIMENTAL_FEATURES), and that will take care of 
the other cases.


Michael

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


Re: [webkit-dev] Experimental features enabled by default

2018-06-20 Thread Michael Catanzaro

On Wed, Jun 20, 2018 at 6:05 PM, Tim Horton  wrote:

It’s definitely not OK, no.


Well, we should make sure the right choice is made for each individual 
feature, but I don't know what those right choices are... hence the 
motivation for my mail.


I think we have some sorting out of this to do, I think it would be 
appreciated if you could hold off for a little bit. Sorry for the 
mess!


OK, I didn't know you were already discussing this. I'll hold off, then.

Michael

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


[webkit-dev] Experimental features enabled by default

2018-06-20 Thread Michael Catanzaro

Hi,

I noticed in glancing over WebPreferences.yaml that we have a large 
number of experimental features enabled by default. There is a comment 
header indicating that the only allowed values are false or 
DEFAULT_EXPERIMENTAL_FEATURES_ENABLED, so true is disallowed, but 
that's being ignored in many cases. It's become a bit difficult to 
notice the comment header because the experimental feature list has 
grown quite large in the past year or two.


Background: DEFAULT_EXPERIMENTAL_FEATURES_ENABLED is enabled by default 
in the XCode build (because Apple disables experimental features on 
branches, not trunk), disabled by default in the CMake build (to 
prevent experimental features from sneaking into GTK and WPE releases), 
and finally enabled by build-webkit (so experimental features are 
always enabled for bots and developers).


I'm planning to change the default values of the following features 
from true (not allowed for experimental features) to 
DEFAULT_EXPERIMENTAL_FEATURES_ENABLED:


CacheAPIEnabled
ConstantPropertiesEnabled
CrossOriginWindowPolicySupportEnabled
IsSecureContextAttributeEnabled
StorageAccessAPIEnabled
SubresourceIntegrityEnabled
RestrictedHTTPResponseAccess
CrossOriginResourcePolicyEnabled
StorageAccessPromptsEnabled

But I wonder if this is OK for all of the above features, as no doubt 
the intention behind using true was to make the feature always enabled. 
So if any of the above features are no longer experimental and should 
be enabled by default on all ports, please speak up so they can be 
graduated out of the experimental features category. My recommended 
sanity-check is that if the feature is ready for all Safari users and 
not just Tech Preview users, then it's probably no longer experimental.


A couple more oddities:

I'll mark CSSAnimationTriggersEnabled as experimental, since it uses 
DEFAULT_EXPERIMENTAL_FEATURES_ENABLED and is clearly intended to be.


For DisabledAdaptationsMetaTagEnabled, I'm not sure. We could change 
the default value from DISABLED_ADAPTATIONS_META_TAG_ENABLED to 
DEFAULT_EXPERIMENTAL_FEATURES_ENABLED, and add a PLATFORM(WATCHOS) 
condition. I think this should be OK for watchOS. Alternatively, I 
wonder if it might be better to consider it non-experimental and simply 
set the default to true (with a PLATFORM(WATCHOS) condition)?


Michael

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


Re: [webkit-dev] Switch to std::variant?

2018-05-23 Thread Michael Catanzaro
On Wed, May 23, 2018 at 10:52 AM, Konstantin Tokarev 
 wrote:

What do you mean under "std::optional fiasco"?


Well we had a bunch of difficult build failures:

https://bugs.webkit.org/show_bug.cgi?id=185159
https://bugs.webkit.org/show_bug.cgi?id=185194
https://bugs.webkit.org/show_bug.cgi?id=185198

That last one is still unresolved.

Not sure if we should expect similar difficulty with std::variant.

Michael

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


Re: [webkit-dev] Switch to std::variant?

2018-05-23 Thread Michael Catanzaro

On Wed, May 23, 2018 at 6:14 AM, z...@falconsigh.net wrote:
Some GCC-and-libstdc++ configurations would still require a fallback 
implementation


After the std::optional fiasco, I'm pretty nervous about the state of 
using new C++ 17 features.


We've wound up in a situation where we're OK with increasing the 
compiler requirement to recent versions... as long as WebKit continues 
to build with ancient libstdc++. So increasing use of more C++ 17 
standard library features seems difficult, and of really limited 
benefit if we're going to need to keep a fallback WTF implementation 
around, which will receive limited testing from us, but which will be 
used by most of our users in practice (at least for GTK).


This is a hard problem. I don't have any answers. But I don't think our 
status quo is very good. https://bugs.webkit.org/show_bug.cgi?id=185198 
is still unresolved and I'm out of ideas


Michael

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


Re: [webkit-dev] [jsc-dev] Proposal: Removing ENABLE(INTL)

2018-05-21 Thread Michael Catanzaro
On Mon, May 21, 2018 at 9:45 AM, Michael Catanzaro 
<mcatanz...@igalia.com> wrote:
But I'm curious if anyone knows what the ICU requirement is for 
ENABLE(INTL)?


Also, Ms2ger reported https://bugs.webkit.org/show_bug.cgi?id=185714 
recently. It seems there are new options 
ENABLE_INTL_NUMBER_FORMAT_TO_PARTS and ENABLE_INTL_PLURAL_RULES, both 
disabled in WebKitFeatures.cmake. Ideally those would be enabled if ICU 
is new enough. Does anybody know what ICU versions are required for 
these? (If so, best comment in the bug.)


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


Re: [webkit-dev] [jsc-dev] Proposal: Removing ENABLE(INTL)

2018-05-21 Thread Michael Catanzaro
On Mon, May 21, 2018 at 8:55 AM, Konstantin Tokarev  
wrote:
For the record, having !ENABLE(INTL) option allowed to build WebKit 
against old ICU versions, e.g. version that is shipped with RHEL 7.


For WebKitGTK+, we do not support building without ENABLE(INTL), and we 
don't need to worry about RHEL 7 since RHEL is shipping an unsupported 
version of WebKit with bundled ICU.


But we do need to support Ubuntu 16.04 (with ICU 55). If ENABLE(INTL) 
is going to require newer ICU than that, then we would need to expose 
ENABLE(INTL) and ensure that disabling it works. We do have a buildbot 
to check this, and it's green right now, so trunk must be fine. But I'm 
curious if anyone knows what the ICU requirement is for ENABLE(INTL)?


Michael

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


Re: [webkit-dev] New iOS versions sending bogus User-Agent build data

2018-04-26 Thread Michael Catanzaro
On Thu, Apr 26, 2018 at 12:48 PM, Colin Bendell | +1.613.914.3387 
 wrote:

Can you give me an example where UA parsing is punishing users of
alternative user agents? Is this a theoretical problem, or a
widespread problem? I'm not asking to be divisive, but because I know
for a fact that UA parsing is improving the user experience. I can
give you dozens of examples where we must resort to UA parsing for the
betterment of the user (for all flavors of UAs).


I would say it's the most serious web compatibility problem that exists 
today. Our users complain and blame us when important websites are 
broken in WebKit because of it. I have personally wasted days [1] of 
[2] development [3] effort [4] playing with WebKit's user agent quirks 
to get important websites to work properly. You can look at the history 
of our quirks list for non-Safari ports [5] to get an idea of the 
trouble we've had to deal with in recent years. That doesn't count 
cases like [6] where I suspect user agent trouble, but just don't care 
to investigate.


As a web engine developer, it's hard to understate how frustrating this 
is, especially in cases like [7] where we had tons of users complaining 
and the quirks were particularly difficult to write. It sometimes feels 
like website developers are our enemy, just out to break our web 
engine. Sometimes that's even true, e.g. when websites intentionally 
decide to block access to unrecognized browsers, or scare our users 
with claims that a browser is "unsupported" even though it works fine 
with a UA quirk.


This is not a healthy situation for the web.

If everyone was careful and responsible with how they use the user 
agent, it wouldn't be a problem, but at this point it's long been 
spoiled for everyone. I'm sorry that this fallout affects developers 
like you who are just trying to work around a bug. :(


On Thu, Apr 26, 2018 at 12:48 PM, Colin Bendell | +1.613.914.3387 
 wrote:

Again I ask, is there room for compromise where we can expose the
version details in the UA (or some alternative) so that we ensure a
consistent and optimized user experience?


I don't know. I wish there was, but I don't think so. If you have any 
suggestions, that'd be great, but I think it's going to be extremely 
difficult or impossible to solve this problem in a way that makes 
everyone happy.


I don't think I'll be happy until major browsers send the same, 
standardized user agent as other major browsers. (Or send 
fully-randomized user agents, but that's probably an impossible dream.) 
Freezing just the version numbers is not good enough, but it's a step 
in the right direction, and I really appreciate it.


[1] https://trac.webkit.org/changeset/206519/webkit
[2] https://trac.webkit.org/changeset/216139/webkit
[3] https://trac.webkit.org/changeset/216343/webkit
[4] https://trac.webkit.org/changeset/217203/webkit
[5] 
https://trac.webkit.org/log/webkit/trunk/Source/WebCore/platform/UserAgentQuirks.cpp

[6] https://bugs.webkit.org/show_bug.cgi?id=180995
[7] https://bugs.webkit.org/show_bug.cgi?id=171770#c4

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


Re: [webkit-dev] New iOS versions sending bogus User-Agent build data

2018-04-26 Thread Michael Catanzaro
On Thu, Apr 26, 2018 at 11:13 AM, Michael Catanzaro 
<mcatanz...@igalia.com> wrote:
By fixing the WebKit bug, of course. And in the meantime you can work 
around it on the server side by not using img src=mp4, right?


Consider the other perspective on this problem. If other servers look 
at the WebKit version in the UA to determine if WebKit supports img 
src=mp4, other WebKit ports that don't support this are going to be out 
of luck and get broken pages. I know that's not what you're doing -- 
you're looking at iOS version instead, and only doing it to work around 
a specific bug, which is much better -- but the problem of websites 
sending bad content based on bad user agent parsing is so severe that 
we don't have many good options, here. :/


Michael

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


Re: [webkit-dev] New iOS versions sending bogus User-Agent build data

2018-04-26 Thread Michael Catanzaro
On Thu, Apr 26, 2018 at 10:57 AM, Colin Bendell | +1.613.914.3387 
 wrote:

How do we navigate this?


By fixing the WebKit bug, of course. And in the meantime you can work 
around it on the server side by not using , right?


Michael

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


Re: [webkit-dev] Compiling Webkit --wincairo

2018-04-19 Thread Michael Catanzaro
On Thu, Apr 19, 2018 at 9:24 AM, Barone Ashura  
wrote:
Can someone give me some hints on how to better control the output of 
the build process?


I would just use CMake directly, so you won't need to deal with 
build-webkit getting in the way. That script is not really intended to 
be used for production builds, despite the --release option


Alternatively you could try to update FeatureList.pm to ensure it is 
able to disable all the things you want disabled, but this seems like a 
lost cause to me, as your mail shows clearly.


Good luck!

Michael

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


Re: [webkit-dev] python2

2018-04-11 Thread Michael Catanzaro
OK then... this won't be fun, but we'll just have to make the scripts 
support both major versions of python. At least the scripts we use 
during the build, and use ourselves... and the ones that are tested by 
test-webkitpy... oh boy.


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


[webkit-dev] python2

2018-04-10 Thread Michael Catanzaro

Hi,

python2 end of life is January 1, 2020. But even before then, we'll 
need to make WebKit work in environments without python2 available, 
because it's not going to be present in the next Red Hat Enterprise 
Linux or SUSE Linux Enterprise, and its fate in community distros like 
Fedora (where it is being orphaned by the maintainers, and at risk of 
removal) is looking questionable at best.


So we have basically two options:

* Require python3 and port our python scripts from python2 to python3
* Make our scripts support both major versions of python simultaneously

The later would be quite a pain, because developers using python2 are 
sure to break developers using python3, and vice-versia. But my 
understanding is that python3 is not readily-available on Macs, so that 
might be what we need to do if Apple wants to stick with python2. 
Thoughts on this?


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?

2018-03-26 Thread Michael Catanzaro

On Fri, Mar 23, 2018 at 4:32 PM, JF Bastien  wrote:

Hello again WebKitten!

April 2018 is fast approaching, which means that we might be able to 
require GCC 6 and all the great C++17 features that’ll come with 
it. So what say you?
From C++17 it looks like we wouldn’t get quite a few things, but 
we’d be able to use a few nice things (see the table).


JF


Hi,

I've been asking around, and it sounds like this will be a significant 
inconvenience for some Igalia projects where upgrading the compiler is 
a bit difficult, but everyone agrees the time specified in the 
dependencies policy (the next Ubuntu LTS release) is fast approaching, 
and that the policy is a good compromise. It looks like the next Ubuntu 
release is due on April 26 [1], one month from today, so we should be 
good to require GCC 6 at that time. Sound good?


Michael

[1] https://wiki.ubuntu.com/BionicBeaver/ReleaseSchedule
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Using compile_command.json in sources that go into Unified Sources

2018-03-26 Thread Michael Catanzaro
On Sat, Mar 24, 2018 at 6:03 PM, Cadu Bentzen  
wrote:
I included calling this script at the end of the build-webkit (under 
a command line option) script. So far it has work for me, but I 
wonder if this is the right approach or if you already solved that in 
another way.


Is compile_commands.json intended only for use by IDEs? If it's not 
going to break anything, then this seems reasonable to me. I would go 
ahead and submit a patch for review on bugs.webkit.org, and leave a 
link to it in this thread.


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


  1   2   3   >