September 2019 - webkit-dev - lists.webkit.org

Implementing MathML stylistic attributes in WebKit
by Frédéric Wang 28 Sep '20

28 Sep '20

Hello, Currently MathML attributes mathvariant, displaystyle and scriptlevel [1] [2] are implemented in WebKit using custom "style resolution" and "one-glyph rendering" inside the MathML layout code [3] [4] [5]. These features involve text rendering and interaction with CSS font-size, so it is difficult to implement them properly and completely that way. There are known bugs and missing features right now (e.g. mathvariant transform only applies to one-character strings, automatic displaystyle/scriptlevel does not work with fractions, etc) Several years ago, Gecko used to do something similar but that was causing a lot of problems (dynamic update, assertion failures...). At the end, this is now implemented in Gecko more reliably by mapping the attributes to internal CSS properties ; [6] is based on that. When I tried to do something like this in WebKit three years ago, I was only able to rely on proprietary -webkit-* extensions exposed to users [7]. So my questions are: (1) What is WebKit's mechanism to implement such stylistic attributes? (2) Is it possible to implement internal (i.e. not web-exposed to users) CSS properties/values in WebKit? (3) Is it ok to add more -webkit-* properties/values or should these properties be standardized at the CSS WG instead? I understand answers to these general questions from other browser project is either use internal properties or standardize them. Thanks, Frédéric PS: For a concrete example, see [8]. Automatic mathvariant is used for italic variables while font-size in fractions is calculated according to displaystyle / scriptlevel rules. The latter is incorrect (check the attached screenshot) while selection highlight is broken for the former. [1] https://mathml-refresh.github.io/mathml-core/#the-mathvariant-attribute [2] https://mathml-refresh.github.io/mathml-core/#the-displaystyle-and-scriptle… [3] https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/css/mathml.css [4] https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/rendering/mathm… [5] https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/rendering/mathm… [6] https://mathml-refresh.github.io/mathml-core/#css-extensions-for-math-layout [7] https://bugs.webkit.org/show_bug.cgi?id=133845#c5 [8] https://bug-201242-attachments.webkit.org/attachment.cgi?id=377730 -- Frédéric Wang

2 4

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

2019 WebKit Contributors Meeting - Registration is Open
by Jonathan Davis 25 Oct '19

25 Oct '19

Hello WebKit Contributors, You are invited to attend the annual WebKit Contributors Meeting to be held at the Hilton Santa Clara hotel on Friday, November 1st, 2019 from 8 AM to 6 PM Pacific. Breakfast and sign-in will begin at 8 AM. Presentations will run between 9 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 dinner and drinks 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 open. Register at https://webkit.org/meeting/ The event format will include a mix of prepared talks around 40 minutes long with 10-15 minutes of questions, and spontaneous lightning talks about 5-10 minutes long. If you have a topic idea that you want to present, please email me directly. We look forward to seeing you there! Thank you, Jon Davis

7 11

Planned EWS improvements
by Aakash Jain 22 Oct '19

22 Oct '19

Hi Everyone, I have been making number of improvements to EWS. I also have various planned improvements to EWS. I wanted to reach out to you guys to see if anyone wants me to prioritize any particular improvement(s). If there is any improvement which you want to see and is not listed below, please feel free to let me know. Also most of the queues have been transitioned from old to new EWS and I am working on the remaining ones (jsc, windows and commit-queue). Here is the list of improvements (in no particular order): 1) Develop a webpage showing summary of EWS builds for a patch. This page would provide the summary of important build-steps, high-level details about the failure (e.g.: name of the tests which failed, or possibly relevant build failure logs), and include link(s) to the Buildbot page(s). This page will open on clicking the status-bubbles (and would be replacement of old EWS status page like https://webkit-queues.webkit.org/patch/379563/win-ews <https://webkit-queues.webkit.org/patch/379563/win-ews>). Currently clicking the status-bubble opens the Buildbot build page, which contains a lot of infrastructure details, and probably is information-overload for many engineers, so this summary page should help with that. https://webkit.org/b/197522 <https://webkit.org/b/197522> 2) Redesign status-bubble tooltip to include more detailed information about failures (e.g.: each test failure name along-with url to flakiness dashboard, and url to complete results.html file, as suggested by David Kilzer in https://lists.webkit.org/pipermail/webkit-dev/2019-September/030799.html <https://lists.webkit.org/pipermail/webkit-dev/2019-September/030799.html>). We should also add the tooltip support for iPad/iPhone https://webkit.org/b/201940 <https://webkit.org/b/201940> 3) Add a way to retry a patch in EWS. This would allow engineers to confirm that the failures indicated by EWS aren't flaky/incorrect. Maybe a good place to add the 'retry' button would be the status-bubble's tool-tip (visible only if the bubble is red) https://webkit.org/b/196599 <https://webkit.org/b/196599> 4) Parse the relevant build failure message from build logs (and display in summary page) https://webkit.org/b/201941 <https://webkit.org/b/201941> 5) Style failure should be displayed in-line on the review page along-with the code, just like the reviewer's comments https://webkit.org/b/202252 <https://webkit.org/b/202252> 6) Add more test-suites to EWS (e.g.: LLDB tests, resultsdbpy tests) https://webkit.org/b/189206 <https://webkit.org/b/189206>, https://webkit.org/b/201928 <https://webkit.org/b/201928> 7) Add commit-queue support for security bugs https://webkit.org/b/201939 <https://webkit.org/b/201939> 8) API tests should upload crashlogs https://webkit.org/b/201929 <https://webkit.org/b/201929> Thanks Aakash

6 9

Moving to Python 3
by Jonathan Bedard 09 Oct '19

09 Oct '19

Hello WebKit developers, Now that the Catalina developer seeds are available, it is official that the new Mac developer tools come with Python 3. As a result, we need to continue the ongoing discussion about migrating our Python 2.7 scripts to Python 3. I propose that, over the next 9 months, we do the following: 1. Make any no-cost Python 3 compatibility changes, in particular - print foo -> print(foo) - import .foo -> import webkitpy.foo 2. Convert any scripts not used in automation to Python 3 ASAP (scripts like bisect-builds, block-spammers, compare-results) 3. Make most Python 3 compatibility changes which sacrifice efficiency, subject to a case-by-case audit. These would be things like: - dict.iteritems() -> dict.items() - dict.items() -> list(dict.items()) 4. Install Python 3 on macOS Sierra and Mojave bots 5. Convert peripheral automation scripts to Python 3 1-by-1 (scripts like clean-webkit, merge-results-json, webkit-patch) 6. Convert testing scripts and webkitpy to Python 3 in a single change The trouble I foresee us encountering with any scheme which attempts a conversion which retains both Python 2.7 and Python 3 compatibility is code like this: for expectation_string, expectation_enum in test_expectations.TestExpectations.EXPECTATIONS.iteritems(): ... In this code, the EXPECTATIONS dictionary is thousands of elements long. In Python 2.7, iteritems() gives us an iterator instead of creating a new list, like items() would. In Python 3, iteritems() doesn’t exist, but items() does, and now gives us an iterator instead of creating a new list. The trouble here is that, in this case, creating a new list will be very expensive, expensive enough that we might manage to impact the testing run. There isn’t really an elegant way around this problem if we want to support both Python 2.7 and Python 3, other than defining different code paths for each language. There are other small gotchas as well. For example, ‘%’ is no longer a protected character, which can actually change the behavior of regexes. That’s why I think it’s better to just try and directly convert things instead of attempting to be compatible with both Python 2.7 and Python 3. Jonathan

15 26