December 2018 - 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

[CSSOM View] Smooth scroll behavior via CSS property / DOM scroll* API
by Frédéric Wang 13 Feb '20

13 Feb '20

Hi all, This email is to announce that I have started to work on (programmatic) smooth scrolling in WebKit from the CSSOM View specification [1]. To use this effect, web developers can pass a behavior parameter (auto, smooth, or instant) to Element.scroll, Element.scrollTo, Element.scrollBy, Element.scrollIntoView, Window.scroll, Window.scrollTo or Window.scrollBy [2]. When behavior is auto, the instant/smooth characteristic is actually taken from the value of a new CSS scroll-behavior property [3]. This new feature will be protected by a compile flag (enabled by default) and a runtime flag (an experimental feature). If you are interested, you can follow advancement on Bugzilla [4]. Incidentally (and since that was convenient to do it before) I also added some basic support for new ScrollIntoView options [5] [6] that allow to specify how you want the revealed element to be aligned with respect to its scrollable ancestors. Cheers, Frédéric [1] https://drafts.csswg.org/cssom-view [2] https://drafts.csswg.org/cssom-view/#dictdef-scrolloptions [3] https://drafts.csswg.org/cssom-view/#propdef-scroll-behavior [4] https://bugs.webkit.org/show_bug.cgi?id=188043 [5] https://bugs.webkit.org/show_bug.cgi?id=189258 [6] https://drafts.csswg.org/cssom-view/#dictdef-scrollintoviewoptions

1 3

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

Reducing globals
by Alex Christensen 31 Jan '19

31 Jan '19

I am embarking on a journey to reduce the number of global variables and singletons we use instead member variables on the proper objects. Feel free to join! 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.

4 8

Lots of spam on Bugzilla
by Ryosuke Niwa 15 Jan '19

15 Jan '19

e.g. https://bugs.webkit.org/show_bug.cgi?id=168774 Is there a way we can integrate CAPTCHA, etc... to prevent these spammers from getting Bugzilla account? - R. Niwa

6 9

'final' class specifier and 'final' method specifier
by Fujii Hironori 21 Dec '18

21 Dec '18

Hi WebKit devs, 'final' keyword can be applied to both a class and a method (non-static member function). I don't know correct terminology for them. I call them 'final' class specifier and 'final' method specifier. I'm now going to update WebKit Code Style Guidelines for using 'final' class specifier for all classes which has no derived classes in Bug 192844. https://bugs.webkit.org/show_bug.cgi?id=192844 I believe this is not controversial. This is not a topic I'd like to discuss today. I'd like to discuss which 'override' or 'final' should be used for methods. Currently, WebKit is using both inconsistently. For example, CSSFontFaceSet class is marked 'final' and its methods are marked 'final', while CSSFontFaceSource class is marked 'final' and its methods are marked 'override'. https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/css/CSSFontFace… https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/css/CSSFontFace… According to WebKit Code Style Guidelines, 'final' method specifier is preferable to 'override' if possible. There is a previous discussion thread. https://webkit.org/code-style-guidelines/#override-methods https://lists.webkit.org/pipermail/webkit-dev/2016-March/028022.html I'd like to change this because 'final' doesn't necessarily imply 'override'. See the following stackoverflow: https://stackoverflow.com/questions/29412412/does-final-imply-override IIUC, 'final' method specifier can be useful for such like the following case: class B { public: virtual foo(); virtual bar(); }; class B1 : public B { foo() final; }; class D final : B1 { bar() override; }; The 'final' method specifier indicates D can't override the method foo. Thus, using 'final' method specifier implies other virtual functions can be overridden. I'm not sure my understanding right. Please correct me.

5 10

Watch out for std::optional's move constructor
by Chris Dumez 20 Dec '18

20 Dec '18

Hi, I have now been caught twice by std::optional’s move constructor. It turns out that it leaves the std::optional being moved-out *engaged*, it merely moves its value. For example, testOptional.cpp: #include <iostream> #include <optional> int main() { std::optional<int> a = 1; std::optional<int> b = std::move(a); std::cout << "a is engaged? " << !!a << std::endl; std::cout << "b is engaged? " << !!b << std::endl; return 0; } $ clang++ testOptional.cpp -o testOptional -std=c++17 $ ./testOptional a is engaged? 1 b is engaged? 1 I would have expected: a is engaged? 0 b is engaged? 1 This impacts the standard std::optional implementation on my machine as well as the local copy in WebKit’s wtf/Optional.h. As far as I know, our convention in WebKit so far for our types has been that types getting moved-out are left in a valid “empty” state. As such, I find that std::optional’s move constructor behavior is error-prone. I’d like to know how do other feel about this behavior? If enough people agree this is error-prone, would we consider having our own optional type in WTF which resets the engaged flag (and never allow the std::optional)? Thanks, --  Chris Dumez

15 46