May 2019 - 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

Changing the svn commit hook to allow tabs for tests.
by Keith Miller 04 Apr '20

04 Apr '20

Hi all, I don’t know if this is possible but it would be great if some sub-directories could be excluded from the no-tabs pre-commit hook. For example, there are many test262 tests that contain tabs, either because they intentionally try to test parsing tab characters or because they were written by someone that used them. Regardless, it’s pretty inconvenient to add the svn attribute that allows tabs every time I update the tests. Since svn properties can’t apply to directories, as far as I know, there’s no way to add the “allow-tabs” property to the entire test262 directory. Alternatively, we could remove the pre-commit hook as tabs should be caught by the style-checker anyway. This is a more contentious choice so I’m not proposing it as the first option unless someone else wants to push for it. Cheers, Keith Miller

3 5

Is anyone maintaining Nicosia scrolling code?
by Simon Fraser 27 Feb '20

27 Feb '20

There’s a bunch of code in Source/WebCore/page/scrolling/nicosia/ that I keep breaking with scrolling tree refactoring. Most of it it stubs. Is anyone maintaining this code, because it obviously doesn’t work, and I’d like to remove the maintenance burden. Simon

3 3

[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

Introducing brand new EWS
by Aakash Jain 04 Sep '19

04 Sep '19

Introducing brand new EWS with EWS for API Tests (for macOS and iOS) and EWS for WebKitPerl Tests! Starting today, when you upload a patch to bugs.webkit.org <http://bugs.webkit.org/>, you will see few more bubbles (for API tests and webkitperl tests). You might also see additional button 'Submit to new EWS' (if the patch doesn't have r? flag). The new EWS comes with many new features and there are lot more I want to add. But, I don't want you guys to wait more to start getting the benefits. That's why I am rolling it out in phases, starting with EWS for API Tests and WebKitPerl Tests. These are tests which are not currently covered by the existing EWS. Next step would be to move queues from existing EWS to new EWS one by one, with the eventual goal of moving over everything to new EWS. Why new EWS? The existing EWS has certain architectural limitations. One of the prominent limitation is that there is no concept of building and testing the patch on different queues. If we have three queues: WK1 tests, WK2 tests and API tests, all three queues would need to compile WebKit independently. So WebKit would be compiled thrice instead of once. This is inefficient and thereby require more hardware. The new EWS has separate builder and tester queues. Builder queues build once and upload the archive. Multiple tester queues download that same archive and run tests on that. That way WebKit is compiled only once, and re-used on multiple tester queues. This improves system efficiency and allows us to add new test queues with substantially less hardware. The new EWS uses Buildbot at the back-end, which is a production-level CI system. It is easier to maintain and automatically provide various features like historical build logs, real-time log streaming, easier bot management, ability to retry a build etc. Plus, it’s a system most of you are already familiar with (build.webkit.org <http://build.webkit.org/>). How can you contribute: If you are interested in contributing, the source code is located at: ews-build (Buildbot): Tools/BuildSlaveSupport/ews-build ews-app (web-app): Tools/BuildSlaveSupport/ews-app Detailed instructions are at: https://trac.webkit.org/wiki/EarlyWarningSystem#ContributingtoEarlyWarningS… <https://trac.webkit.org/wiki/EarlyWarningSystem#ContributingtoEarlyWarningS…> Upcoming features: - status-bubble should display position in queue https://bugs.webkit.org/show_bug.cgi?id=196607 <https://bugs.webkit.org/show_bug.cgi?id=196607> - EWS should comment on Bugzilla bugs about failures https://bugs.webkit.org/show_bug.cgi?id=196598 <https://bugs.webkit.org/show_bug.cgi?id=196598> - EWS should have a way to retry a patch https://bugs.webkit.org/show_bug.cgi?id=196599 <https://bugs.webkit.org/show_bug.cgi?id=196599> - Security EWS https://bugs.webkit.org/show_bug.cgi?id=196605 <https://bugs.webkit.org/show_bug.cgi?id=196605> If you notice any issue, please feel free to file bugs (and assign to me). Thanks & Regards Aakash Jain

3 8

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

Waiting for an event in layout test...
by Ryosuke Niwa 31 May '19

31 May '19

I’m gonna give you a game changing function: function listenForEventOnce(target, name, timeout) { return new Promise((resolve, reject) => { const timer = timeout ? setTimeout(reject, timeout) : null; target.addEventListener(name, () => { if (timer) clearTimeout(timer); resolve(); }, {once: true}); }); } You can then write a test like this: await listenForEventOnce(document.body, 'load'); // do stuff after load event. await listenForEventOnce(document.querySelector('input'), 'focus'); await listenForEventOnce(visualViewport, 'scroll', 5000); // After the input element is focused, then the visual viewport scrolled or 5 seconds has passed. - R. Niwa

2 1

IPC implementation help in haiku's webkit port
by Rajagopalan Gangadharan 30 May '19

30 May '19

Hello Everybody, I stumbled upon a problem in an attempt to port webkit to haiku. Before everything I would like to take few moments to explain about state of the port. 1) We have a well maintained WebKitLegacy port on haiku. 2) Now in the process of porting latest webkit to haiku currently at fixing IPC. We didnt want to use BSD sockets and would like to use Native messaging framework [BMessage : https://www.haiku-os.org/docs/api/classBMessage.html ] because our native application waits for BMessage in its main thread as a result we cant wait for both sockets and BMessage on same thread. Also we would like to maintain the haiku ecosystem :) . 3) We need process id of the intended process we would like to connect to send data [BMessenger: https://www.haiku-os.org/docs/api/classBMessenger.html ] So instead of exchanging socket id's we would just exchange pid's 4) We were able to successfully deliver and process the messages. Currently we were able to proceed until creating a connection between network process and webprocess(NetworkConnectionToWebProcess). Now where we are stuck is that After creating a connection between network process and webprocess we would have to reply back to webprocess about the connection info( pid of network process in our case ). I see the reply is an alias of DelayedReply(CompletionHandler<Attachment&>) according to the derived sources. Unfortunately the webprocess is indefinitely waiting for reply from webprocessproxy for which we are unable to "reply" . Could anyone point me where I would have went wrong or what could be done to fix this and any better ways for implementing this. Please check the source references for more info: NetworkProcessProxy: [ https://github.com/RAJAGOPALAN-GANGADHARAN/webkit/blob/6bf81d79669be06b4efd… ] NetworkProcess [ https://github.com/RAJAGOPALAN-GANGADHARAN/webkit/blob/6bf81d79669be06b4efd… ] ConnectionHaiku : [ https://github.com/RAJAGOPALAN-GANGADHARAN/webkit/blob/ipc-iteration2/Sourc… ] Attachment : [ https://github.com/RAJAGOPALAN-GANGADHARAN/webkit/blob/ipc-iteration2/Sourc… ] I believe these places are currently in focus For further reference please check [ https://github.com/RAJAGOPALAN-GANGADHARAN/webkit/tree/ipc-iteration2] Thank you Regards G.Rajagopalan

3 3