August 2017 - webkit-dev - lists.webkit.org

PSA: Bit fields won't be packed on Windows if you mix types
by Ryosuke Niwa 04 Sep '20

04 Sep '20

Hi, Unlike gcc and clang, MSVC pads each consecutive member variables of the same type in bitfields. e.g. if you have: struct AB { unsigned m_1 : 31; bool m_2 : 1; } then *MSVC pads m_1 and allocates sizeof(unsigned) * 2 for AB* whereas gcc and clang only allocate sizeof(unsigned) * 1 for AB. This is *not a compiler bug*. It's a spec. compliant behavior, and may in fact have a better run-time performance in some situations. However, for core objects like RenderObject and InlineBox, allocating extra 4-8 bytes per each object is prohibitory expensive. In such cases, please *use the same POD type for all bitfield member variables*. (Storage class classifiers and variable qualifiers seem to have no effect on how variables are packed; e.g. mutable, const, etc...). For example, MSVC will allocate sizeof(unsigned) * 1 for AB if we rewrite the above code as: struct AB { unsigned m_1 : 31; unsigned m_2 : 1; } When you're making this change, *be sure to audit all code that assigns a non-boolean value to m_2* because implicit type coercion into boolean is no longer in effect. For example, AB ab; ab.m_2 = 2; puts(ab.m_2 ? "true" : "false"); will print "true" before the change and will print "false" after the change. An easy way to ensure you've audited all such code is to add getters and setters for all bitfield member variables or wrap them in a special structure or class as done in http://trac.webkit.org/changeset/103353 and http://trac.webkit.org/changeset/104254. Best regards, Ryosuke Niwa Software Engineer Google Inc.

4 8

Support "registerProtocolHandler" in WebKit2
by Gyuyoung Kim 20 Apr '20

20 Apr '20

Hello, I would like to listen what do you think to support 'registerProtocolHandler' in WebKit2. This feature is to execute web content through registered custom protocol. - For example, web content can register "mailto" custom protocol using this feature, <script> navigator.registerProtocolHandler("mailto", "https://mail.naver.com/", "Web Mail"); </script> <html> <head> <title>Web Protocol Handler Sample - Test</title> </head> <body> <p>Send an email : <a href="mailto://">this !</a></p> </body> </html> Besides this feature has been supported by Mozilla and Chromium (From Mozilla 3.0, Chromium 13). - https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocol… - https://developer.mozilla.org/en/docs/Web-based_protocol_handlers The feature is included in the W3C recommendation 28 released on Oct. 2014. - W3C spec : http://www.w3.org/TR/html5/webappapis.html#custom-handlers IIRC, some WebKit1 ports supported this feature though, those ports were deprecated. Now WebKit port supports this feature no more. There is a very old bug to support this feature though, it wasn't maintained so far. Recently I updated it based on latest WebKit. - https://bugs.webkit.org/show_bug.cgi?id=92749 Feel free to give me any feedback about this feature. Gyuyoung.

10 26

WebKit project in Coverity
by Carlos Alberto Lopez Perez 09 Jan '20

09 Jan '20

Hi, Coverity is an static analysis tool that allows to find bugs and vulnerabilities on the source code via static analysis. For open source projects, they offer free usage of their platform. The WebKit project is already registered there since a while. [1] To read the reports in detail or run new scans you have to be member of the WebKit project in Coverity. I happen to be one of the admins there, and I will happily grant you access to this platform if you are a WebKit committer (listed in contributors.json). So if you are interested in this, just send me an email requesting access. Regards ------- [1] https://scan.coverity.com/projects/webkit

2 1

C++17 is here. Should we use it?
by JF Bastien 26 Jun '19

26 Jun '19

Hello WebKilters, Our Chrome-y friends are considering the use of C++14 <https://groups.google.com/a/chromium.org/forum/?utm_medium=email&utm_source…>. I have to say that C++14 in WebKit has been quite amazing, and we should consider using C++17: it has many wonderful new things <https://github.com/tvaneerd/cpp17_in_TTs/blob/master/ALL_IN_ONE.md>, some of which we already use through WTF’s re-implementation of library features. By now (table as witness <http://en.cppreference.com/w/cpp/compiler_support>) most C++17 languages features are in clang and GCC, and MSVC isn’t doing too bad either. Language things can just come through WTF if we really want them. So how about it? JF

8 23

For your consideration: Naming scheme for fooIfExists/ensureFoo
by Darin Adler 22 Feb '19

22 Feb '19

Lets bike shed! For some time, functions with names like fooIfExists and ensureFoo have been bothering me. I find both names kind of opaque and unpleasant. Here’s an example: StyleResolver* styleResolverIfExists(); StyleResolver* ensureStyleResolver() What do you think of these names instead? StyleResolver* optionalStyleResolver(); StyleResolver& requiredStyleResolver(); I like them better. Note also that I think the requiredStyleResolver function should return a reference so nobody is tempted to do null checks. It seems like the C++ community likes the name optional for this concept; isn’t there some kind of std::optional template? -- Darin

15 25

2017 WebKit Contributors Meeting – Registration is Open!
by Jonathan Davis 13 Sep '17

13 Sep '17

Hello WebKit Contributors, You are invited to attend the annual WebKit Contributors Meeting to be held at the Hyatt House San Jose/Silicon Valley hotel on Friday, October 13th, 2017 from 8 AM to 6 PM Pacific. Breakfast and sign-in will begin at 8 AM. Presentations will run between 9:30 AM to 6 PM. Lunch will be provided with all day coffee, tea and a mid-afternoon snack break. A reception is planned at the venue after the meeting with drinks and snacks from 6 PM to 9 PM. To attend you must be an active WebKit contributor. The meeting will be free of charge, and registration is now open. Sign up at https://webkit.org/meeting/ to reserve your spot. The registration deadline is Friday, September 29th, 2017. If you are traveling internationally and require a formal invitation letter, please email me. The event format will follow last year’s mix of proposed talks of around 40 minutes long and spontaneous lightning talks about 5-10 minutes long. If you have a topic idea that you to present, please email me directly. We look forward to seeing you there! Thank you, Jon Davis

1 1

Bring back ARMv6 support to JSC
by Caio Lima 12 Sep '17

12 Sep '17

Hi All. Some of you guys might know me through the work I have been doing in JSC. The experience working with WebKit has been great so far, thank you for the reviews! Since 1st May, we at Igalia have been working on bring back the ARMv6 support into JSC. We already have commits into our downstream branch port[2] that fixes some compile/runtime errors when building JSC to ARMv6 and also fixes some bugs. However, this branch is not synced with WebKit upstream tree and I would like to pursue the upstreaming of this ARMv6/JSC support to WebKit. As a long shot, we are planning to maintain the ARMv6 support and make tests run as green as possible. Also, it's our goal make ARMv6 support not interfere with other ARM versions support code negatively and we will be in charge of implement platform-specific fixes/features for JSC/ARM6, this way no imposing burden to the rest of the community. To keep track of work to be done, I've create a meta-bug in bugzilla[3] and it's going to be used firstly to organize the commits from our downstream branch, but pretty soon I'm going to create issues related with javascriptcore-test failures and send patches to fix them. We have already submitted 3 patches (they are marked as dependence of [3]) that fixes ARMv6 into LLInt and JIT layers and got a round of review into them. Best Regards, Caio. [1] - https://www.igalia.com/about-us/coding-experience [2] - https://github.com/WebPlatformForEmbedded/WPEWebKit [3] - https://bugs.webkit.org/show_bug.cgi?id=172765

9 20

WebVR on WebKit
by Sergio Villar Senin 12 Sep '17

12 Sep '17

Hi, some weeks ago I uploaded [1] a patch (based on previous work by my colleague at Igalia Zan) which basically adds the IDLs for WebVR 1.1 spec along with the required stubs and the cmake build configuration. As Sam Weining perfectly pointed out, this needs some previous discussion in the list in order to go ahead. WebVR is an API which provides support for exposing virtual reality devices (like HMDs) to web apps so that the info coming from those devices could be converted into position, orientation and interactions with virtual worlds. Note that for a complete VR experience some other APIs would be needed as for example de Gamepad API for controller support (some extensions were proposed). Although the spec[2] mentions that 1.1 is deprecated it is what browsers are shipping initially as 2.0 is still in a "do not implement" state. Regarding interest from other vendors, WebVR is already supported in Edge, Firefox nightly and experimental builds of Chromium. Other browsers supporting it are Samsung Internet and Oculus Carmel. Our main interest is to eventually have some implementation working on WebKitGtk and/or WPE on Linux but obviously there is a lot of cross- platform work that needs to be done as well. Our initial idea would be to use the OpenVR API as Valve released a Linux version of their SDK some months ago. Looks like a safe bet as other vendors like Firefox or Chromium already include it in their trees as third party. WDYT? BR [1] https://bugs.webkit.org/show_bug.cgi?id=174202 [2] https://w3c.github.io/webvr/spec/1.1/

4 7

Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)
by Keith Miller 04 Sep '17

04 Sep '17

Hello fellow Webkittens, Are you growing tired of long cat naps while waiting 45 minutes for WebKit to build? (I’ve definitely never done this 🤐!) Do you want WebKit to build up to 3-4x faster on a clean build?* Does seeing your incremental build… stay the same sound good? You’ll be purring with excitement after you switch to unified source builds!** * Building JSC with CMake, including CMake configuration time, went from ~8m15s to ~2m30s on my MBP using unified sources only on cpp files in JavaScriptCore. Final results on WebKit may vary. Using unified sources may cause sudden feelings of euphoria and productivity (or grumpiness from lack of naps…). Not responsible for any bugs in extra patches produced by using unified source builds (excluding build system related bugs) except where required by law (pizlo(a)apple.com <mailto:pizlo@apple.com>). ** Soon. Unified source builds haven’t been landed yet. How are things going to change? Great question! Let’s find out! When you fire off the build script it will automagically paw your source files into bundles. The size of each bundle is speculatively going to be 8 .cpp files but that’s up for experimentation. From my testing so far, the compile time for a bundle is at most 20% (~6s vs ~7s for the Air directory) longer than the longest file it includes. Given that most of the build time in incremental builds is scanning dependencies, this change is probably only barely noticeable. Bundling happens as part of the CMake configuration process, in the CMake build. In the Xcode build it’s more complicated since we cannot dynamically choose the files we are going to compile. The only solution I know of is to pre-list a bunch of files for the build to dump files into. Occasionally, we’ll need to add more files to the build list. When you add or remove a file in the project, the cost is higher. The current plan to bundle source files is by directory. This means that when a .cpp file is added or removed you will rebalance the bundles in its directory, and you will have to rebuild up to the full directory that file is in. My goal is to make all of this invisible to developers as much as possible. I believe, for the most part, things should operate mostly as they have before. As the details on unified source builds get finalized, I’m sending out a separate email documenting any workflow changes. I’ll also do my best to answer any questions or concerns. “But Keith, am I going to have to make major changes to the way I develop WebKit?” Yes and, hopefully, no. There is one major common workflow change that comes with unified sources, the naming of static variables and functions. Since C++ does not have a way to only declare a static function or variable in some restricted top level scope we are going to need to create some work around. The choice I’m thinking we’ll go with is to have an auto-generated macro value FILENAME, which is similar to __FILE__ except that it doesn’t have file extension (We can’t use FILE since that’s actually a type in C 🙁). This macro would be redefined in the unified source directly above the file that is about to be included. Then in each cpp file that has static functions/variables developers would have: namespace FILENAME { static int myVariable { 0 }; static int myFunction() { return myVariable; } } The advantage of using a macro over textually writing the filename is that it makes code more portable between files. Also, once people get used to the concept of FILENAME in the code base it will, hopefully become obvious what it means. The main downside to this is using FILENAME in a header would give you whatever cpp file first included you (if only we got the compiler magic of __FILE__...). We would probably need to prohibit using FILENAME in .h files. Unfortunately, you cannot "using FILENAME;” because it will export all the values in each subsequent namespace. e.g. namespace JSC { namespace Foo { static int myVar { 0 }; } using Foo; } namespace JSC { namespace Bar { static int myVar { 0 }; } using Bar; } does not compile. Does anyone have other name recommendations for the macro name other than FILENAME? I went with file name since it describes what the substituted value will be the best, which is helpful for debugging. The other options I considered were FILE_LOCAL and PER_FILE. Are there other issues that people think might occur with unified sources? Note, It’s also likely that there are some source files that need to be excluded from the unified source builds for various reasons. “Is there anything else I need to do with unified sources?”, Yes! Enjoy the faster builds! To help visualize how much of a difference unified sources can make for you, I’ve illustrated this helpful graph on the WebKit developer experience: * Due to size constraints this graph is not to scale. Cheers, Keith P.S. For those interested there was a long process in deciding how to improve builds: The first thing I looked at was using C++ modules. There were a couple of problems with C++ modules. First, different compliers support modules in different ways. This was not a major concern since we probably would have gone with Clang’s version of modules. As far as I know, almost all developers either use clang or could likely switch to clang for development. The bigger problem with Clang modules is that it seemed like we would have a rough early adopter problem. Additionally, since a lot of Apple’s internal SDK’s don’t seem to support modules it was likely to be a major slog to get everything working correctly. In a few years I think it will probably be worth looking at C++ modules again as, in theory, C++ modules should be better than unified sources. Since we decided against C++ modules that really only leaves us with some form of unified sources. Obviously, doing all in one builds would be out of the question. While all in ones would have been great for clean builds, it also means incremental builds are essentially the same as clean builds. So, I concluded that we should go with some kind of automated unified build file solution. An automated unified build file solution means that most of the time the build system is opaque to developers (well as much as is possible with a unified source build). Since the static variable naming problem was likely to be the biggest issue with unified sources, it was important to create a system that made this a pain free as possible. There were other options we could go with. We could have a script that parses .cpp files and looks for static variables with the same name and yells at you. This is pretty annoying and wouldn’t help actual development when people hit an error. For example, I know I never run the check-webkit-style script until I’m putting a patch up for review.

25 69

Webkit Nightly build is broken
by Alex Skachkov 31 Aug '17

31 Aug '17

Hi all, I can’t found any new Webkit Nightly build in https://webkit.org/nightly/archives/ <https://webkit.org/nightly/archives/> later then r220267 August 4, 2017. It seems that Webkit Nightly build is broken, is it possible to fix it? Best regards, Oleksandr Skachkov

2 3