November 2018 - webkit-dev - lists.webkit.org

Clarifying feature flags
by Don.Olmstead＠sony.com 07 Nov '18

07 Nov '18

Hi WebKittens, After I saw that CSS_PAINTING_API wasn't exposed in CMake I took a stab at looking into the different ENABLE_ flags inside WebKit's source to try and get what's exposed on the XCode side synced. I ended up searching through the source code and found around 200 different ENABLE_ flags. https://bug-191167-attachments.webkit.org/attachment.cgi?id=353663 has the listing. It was just generated by blindly greping the source code with Python. I'm wondering if there's any way to get a better taxonomy on these things. I know there are other macros like HAVE and USE which some of these options might better fit into. Some flags seem to be around internal debugging like ENABLE_YARR_JIT_DEBUG and a bunch of stuff looks applicable to JSC debugging. So as an example maybe DEBUGGING(YARR_JIT) might be a better way to flag things. Then maybe build-webkit can have some flags which enable different debugging scenarios. Some flags are tied to ports. Only Apple ports are going to have support for ENABLE_APPLE_PAY and ENABLE_WEBMETAL. Maybe those should be under HAVE_ or USE_ or perhaps there's a way to better convey that its definitely port specific. This is probably dependent on whether it's something you'd want to toggle. Then there are features that are in various states. Some for sure are complete but you may want to turn off or on like WebGL or video support based on your platform. For those there should definitely be an ENABLE or maybe FEATURE might be a better way to designate it when A port has shipped an implementation. Some are not port specific and can be turned on when complete, YARR_JIT_BACKREFERENCES, sticks out that it is likely going to be removed once the tests all pass. Maybe DEVELOP or EXPERIMENTAL would be a better designation. If it requires a port to do some work to enable it then perhaps that information can be passed along as well. There's also some stale code like enabling web components in the perl and stuff like ENABLE_ACCESSIBILITY in the CMake that are just hanging out without actually doing anything. Anyways those are just some thoughts on how we might be able to get things a bit more under control and clue developers in a bit more on what things are so they can utilize it all. As a side effect perhaps we can also get more tooling around this so we can also keep the XCode and CMake bits in sync. I was messing around with some code generation in python around it and I'd be happy to throw those up as patches if there's interest. I'm really interested in other people's thoughts on this. Thanks Don

3 3

Experimental and (new) Internal feature flags
by Dean Jackson 06 Nov '18

06 Nov '18

I just added support for a new category of WebKit2 preference: internal debug. The motivating factor was that people were abusing experimental features to add flags for anything they wanted to toggle at runtime, even if our users would have no idea what it meant (nor should they ever toggle it). Internal features are not public-facing. My next task will be to remove the ability to set a default value for experimental features. They will default to be off (if it really is experimental, it shouldn't be on by default). This will apply even to tests - see below for how to turn them on at runtime inside WKTR. Documented here: https://trac.webkit.org/wiki/ExperimentalAndInternalFeatureFlags WebKit provides a way to expose a feature flag to a client application at runtime, and have that application toggle the feature. This lets us to start work on experimental features without fully exposing them to the Web, but allows Web developers to turn them on and test. There are two types of exposed features: Experimental and Internal Debug. The configuration file WebPreferences.yaml controls these features. Just set the category value to experimental or internal. Note that you should also provide a nice human-understandable description and name. These are only exposed by WebKit2. If you want your feature to be toggled via WebKit1 you'll have to manually add more code. Experimental Features ---- These features are designed for Web developers, and are exposed via Safari's Develop menu as well as MiniBrowser. Internal Debug Features ---- These features are designed for WebKit developers, and are exposed via Safari's secret-but-not-really Debug menu. We do not expect Web developers to change these settings. They are also exposed by MiniBrowser. Which should I use? ---- If a Web developer wouldn't understand what the feature is by name, or it is just for internal testing, then you should use an internal feature. For example, we don't want users to disable Service Workers, and almost no one would know what MDSN ICE Candidates are. What about testing? ---- You can turn both experimental and internal features on via headers in WebKitTestRunner. Use experimental:FeatureName or internal:FeatureName. For example...  Dean

6 15

dump-class-layout script not working
by Frank Jaeger 06 Nov '18

06 Nov '18

Hello. First of all I'm really sorry if this is the wrong mailing list to post to, webkit-help would have probably been better but it doesn't seem very active. I run into some problems while trying to use the dump-class-layout script (found in Tools/Scripts/). I built WebKit using the build-webkit script with the --debug flag. After building, I tried to run the dump-class-layout script with the following arguments: ./Tools/Scripts/dump-class-layout --architecture=x86_64 -c Debug JavaScriptCore JSString I also tried different frameworks and classes. The script always fails telling me that "no type matches x in y" where x is the class name I used in the run and y is the framework name. Why is this happening? The script is correctly finding the built and symbolicated framework image, so why is it not working properly? Thanks in advance.

3 5

[Deadline October 30] Dropping support for Arm traditional (no Thumb2)?
by Guillaume Emont 03 Nov '18

03 Nov '18

Hi all, With this email, I would like to express the intent of dropping support for Armv7 traditional (without the Thumb2 extension) from the tree. Though we at Igalia are willing to continue supporting Armv7 with Thumb2 extension, we don't have any need for the support of platforms lacking Thumb2. Currently, this combination is broken and does not even compile. The proposed change means that going forward, the only Arm 32-bit architecture supported in LLInt, JIT and DFG would be Armv7 with the Thumb2 extension. Other variants would have to resort to using LLInt with the CLoop. We currently have a buildbot for Armv7 Traditional[1] and we plan to remove it. If anyone cares for this specific platform, and wants to step forward to do the maintenance work for it and set up their buildbot for it, please say so before October 30 (a week+ from now). Otherwise I'll assume nobody cares about this and I'll work on a patch to remove all the code we have that is specific to Arm traditional. Cheers, Guij [1] https://build.webkit.org/builders/JSCOnly%20Linux%20ARMv7%20Traditional%20R…

2 1

CSS Logical Properties and Values
by Oriol Brufau 02 Nov '18

02 Nov '18

https://drafts.csswg.org/css-logical-1/defines properties and values to control layout through logical, rather than physical, direction and dimension mappings. I have been working on implementing this in Blink, now I'm starting with WebKit. Various properties are already supported but using non-standard names with a -webkit- prefix. The standard properties have already been shipped in Firefox and Blink, so I will start with implementing them and converting the prefixed ones into aliases. This will happen in https://bugs.webkit.org/show_bug.cgi?id=188386, the specific list of properties is: * margin-{block,inline}-{start,end} * padding-{block,inline}-{start,end} * border-{block,inline}-{start,end} * border-{block,inline}-{start,end}-{width,style,color} * {block,inline}-size * {min,max}-{block,inline}-size See Blink's Intent to Ship: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/tkN-r119eNc <https://groups.google.com/a/chromium.org/forum/#%21topic/blink-dev/tkN-r119…> After this I willcontinue withthe remaining flow-relative box model properties and the flow-relative values for existing properties: * margin-{block,inline} * padding-{block,inline} * border-{block,inline} * border-{block,inline}-{width,style,color} * float: inline-{start,end} * clear: inline-{start,end} * resize: {block,inline} This will be behind an experimentalflag, like it's being done in Blink. Firefox shipped some. See Blink's Intent to Implement: https://groups.google.com/a/chromium.org/d/msg/blink-dev/48OwfwZrbvI/A1XZFG… I would like to get your feedback and comments about this topic, if you are fine with the plan we will start to land patches next week.

3 6

Rename wtf/unicode/UTF8.h
by Fujii Hironori 01 Nov '18

01 Nov '18

wtf/unicode/UTF8.h is conflicting with ICU header in MSVC builds. I'd like to rename wtf/unicode/UTF8.h to wtf/unicode/WTFUTF8.h. Any suggestion? Here is ICU's #include "unicode/utf8.h" which happens to include wtf/unicode/UTF8.h https://github.com/unicode-org/icu/blob/master/icu4c/source/common/unicode/… Here is MSVC quoted form #include behavior documented. https://msdn.microsoft.com/en-us/library/36k2cdd4.aspx Bug 189693 – [Win][Clang] warning: #include resolved using non-portable Microsoft search rules as: ..\..\Source\WTF\wtf/unicode/utf8.h https://bugs.webkit.org/show_bug.cgi?id=189693 -- Fujii

4 5