September 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

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

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

Planned Maintenance: svn.webkit.org downtime this weekend
by Lucas Forschler 15 Oct '18

15 Oct '18

Hello WebKit Developers! We are planning maintenance to our webkit.org continuous integration infrastructure this weekend. The last time we had a lengthy outage, many regressions crept into the tree and it took a while to get them all resolved. Therefore, starting at 5pm on Friday August 24th (PST), svn.webkit.org will be made read only for the duration of the maintenance. I apologize for the downtime and inconvenience. We are doing our best to keep it as short as possible and over a weekend/non-core hours. We anticipate having everything back online under normal operation before Monday at 8am, PST. I will reply to this email when svn is back open for business. Please email admin(a)webkit.org if you have any questions or concerns. Thanks, Lucas

3 11

iOS EWS broken?
by Ryosuke Niwa 01 Oct '18

01 Oct '18

e.g. https://webkit-queues.webkit.org/results/9366267 RuntimeError raised: Timed out while waiting for data migration Traceback (most recent call last): File "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/layout_tests/run_webkit_tests.py", line 85, in main run_details = run(port, options, args, stderr) File "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/layout_tests/run_webkit_tests.py", line 448, in run run_details = manager.run(args) File "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/layout_tests/controllers/manager.py", line 246, in run if not self._set_up_run(tests_to_run): File "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/layout_tests/controllers/manager.py", line 181, in _set_up_run self._port.setup_test_run(self._options.device_class) File "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/port/ios.py", line 160, in setup_test_run self._create_devices(device_class) File "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/port/ios_simulator.py", line 103, in _create_devices SimulatedDeviceManager.initialize_devices([request] * self.child_processes(), self.host) File "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/xcode/simulated_device.py", line 368, in initialize_devices SimulatedDeviceManager.wait_until_data_migration_is_done(host, max(0, deadline - time.time())) File "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/xcode/simulated_device.py", line 428, in wait_until_data_migration_is_done raise RuntimeError('Timed out while waiting for data migration') RuntimeError: Timed out while waiting for data migration Error in atexit._run_exitfuncs: Traceback (most recent call last): File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/xcode/simulated_device.py", line 446, in tear_down device.platform_device._tear_down(deadline - time.time()) File "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/xcode/simulated_device.py", line 522, in _tear_down self._shut_down(deadline - time.time()) File "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/xcode/simulated_device.py", line 508, in _shut_down raise RuntimeError('Timed out while waiting for {} to shut down'.format(self.udid)) RuntimeError: Timed out while waiting for 3FDF5418-1774-4710-B947-9952835E2563 to shut down - R. Niwa

3 3