June 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

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

CSSOM View behavior for scrollLeft, scrollTop, scrollWidth etc
by Frédéric Wang 24 Sep '18

24 Sep '18

Hi everybody, I'd like to announce that I started to implement the behavior for scrollLeft, scrollTop, scrollWidth, scrollHeight, scrollTo, scrollBy and scrollingElement [1] as specified by the CSSOM View specification [2]. To summarize, the main difference is which element to use in order to set or get the scroll properties of the viewport in standard (non-Quirks) mode: * The CSSOM View spec says it should be document.documentElement and most browsers implement it that way. * Chromium used to use document.body but this has recently been changed to follow the CSSOM View spec [3]. * WebKit still uses document.body and I'm proposing to change this behavior. Note that this is likely to break existing content. The change was attempted in WebKit in the past but broke some non-regression tests [4]. Chromium people also had some issues when trying to ship the change but things went well at the end [5]. For now I'm developing it under a CSSOMViewScrollingAPI developer flag. I was able to run the tests with that flag enabled, modulo a few test adjustments. [1] https://bugs.webkit.org/show_bug.cgi?id=5991 [2] https://drafts.csswg.org/cssom-view [3] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/X64Sg16RhT4 [4] https://bugs.webkit.org/show_bug.cgi?id=106133, https://bugs.webkit.org/show_bug.cgi?id=121876 [5] https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/2iOz5-fgD8Y/… ; https://bugs.webkit.org/show_bug.cgi?id=5991#c20 -- Frédéric Wang - frederic-wang.fr

1 3

EWS for security bugs
by Daniel Bates 12 Jul '18

12 Jul '18

Hi all, All Mac and iOS EWS bots now process security bug patches. We are working to configure the Apple Windows EWS bots and the WinCairo EWS bots should follow shortly. I do not know who maintains the GTK and WPE EWS bots. If you maintain one of these bots then please email me directly so that we can get you setup. For now, EWS processing of security patches is limited to the bubble status and the results posted to webkit-queues.webkit.org. That is, the EWS bots will not post comments to- or upload result archives to- security bugs. Also, we do not support using commit-queue for landing security patches at the moment. Help keep the tree green! Dan

3 2

JavaScriptCore on Fuchsia
by Adam Barth 28 Jun '18

28 Jun '18

As part of developing Fuchsia [1] (a new open-source operating system), we ported JavaScriptCore to run on Fuchsia [2]. At the time, our intent was to use this code within the Fuchsia source tree but not to make it available for developers writing applications for Fuchsia. However, recently, we've gotten a number of requests from customers who would like to use JavaScriptCore in their Fuchsia applications. I'd like your advice about the best way to maintain JavaScriptCore support for Fuchsia. Here are some possibilities I can imagine, but we're open to other possibilities as well: 1. Maintain a fork of JavaScriptCore somewhere on googlesource.com that supports Fuchsia and instruct customers to obtain the Fuchsia port of JavaScriptCore from googlesource.com. 2. Maintain a branch of JavaScriptCore in svn.webkit.org that supports Fuchsia. 3. Maintain support for JavaScriptCore in the mainline of svn.webkit.org. For reference, here's the patch we applied to WTF and JavaScriptCore to enable Fuchsia support: https://gist.github.com/abarth/b4fc909d83be5133cd7a5af209757e96 This patch is based on webkit@206446, but we'd obviously rebase the patch onto top-of-tree before contributing it. I'm happy to answer any questions you might have that would help you provide the best advice. If you would prefer to communicate off-list, I'm happy to do that as well. Thanks in advance, Adam [1] https://fuchsia.googlesource.com/docs/+/master/README.md [2] Actually, if you look at https://fuchsia.googlesource.com/third_party/webkit, you'll see that we've ported WebCore as well, but this email concerns only JavaScriptCore.

5 8

Re: [webkit-dev] Experimental features enabled by default
by Michael Catanzaro 27 Jun '18

27 Jun '18

On Wed, Jun 20, 2018 at 6:05 PM, Tim Horton <thorton(a)apple.com> 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

2 4

wpt.fyi survey
by Mark Dittmer 26 Jun '18

26 Jun '18

Greetings web platform testers and builders! You probably received the WPT survey not long ago, and, since everyone loves filling out *even more* surveys, I'm sending out a survey about wpt.fyi. Survey link <https://goo.gl/forms/ppfjAUIw5YIU46ge2> ( https://goo.gl/forms/ppfjAUIw5YIU46ge2) This survey is *not* about web platform tests themselves, or the infrastructure used to write and run them. It *is* about the test results dashboard, wpt.fyi, and how it can be more useful to you. The survey is short and will drive the priorities of the team that owns wpt.fyi, so please fill it out and make your voice heard! Thanks! //Mark

1 0