October 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

EWS now parses error logs in case of build failure
by Aakash Jain 11 Aug '20

11 Aug '20

Hi Everyone, I am happy to announce another EWS feature. From now on, in case of build failure, EWS will parse the errors and display them in a separate 'errors' log. You wouldn't have to search through thousands of lines of logs to find the error message. For example, in https://ews-build.webkit.org/#/builders/16/builds/6054, in step #7 WebKit failed to compile. Complete logs (stdio) are 38,000+ lines, and the error is not at the end of the logs. Normally, it requires some searching through the logs to find the relevant errors. But now, there is another 'errors' log, which contains just the relevant 11 lines (containing error and few related lines to provide additional context). Hopefully this would save some time and efforts previously spent on searching through the large logs. Note that this information is not displayed in status-bubble tool-tip, since this might be lot of text to display in the tooltip. My further plan is to make this information more readily available, by adding it to a custom designed page which will open on clicking the status bubble https://webkit.org/b/197522 Please let me know if you notice any issues or have any feedback. Thanks Aakash Reference: https://webkit.org/b/203418

4 6

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
by Jonathan Davis 31 Oct '19

31 Oct '19

Hi WebKit folks, The 2019 WebKit Contributors Meeting is tomorrow! Please keep in mind the following important notes: **New Location** We are at the Hilton Santa Clara this year. https://maps.apple.com/place?address=4949+Great+America+Parkway,+Santa+Clar… **Wear Layers** Our after hours dinner party will be outdoors. While there will be heaters, I recommend wearing several layers for the evening festivities. I look forward to seeing everyone again this year! – Jon Davis

1 0

Re: [webkit-dev] [blink-dev] Re: What to do about scroll anchoring?
by Emilio Cobos Álvarez 29 Oct '19

29 Oct '19

Hi all, 10/18/19 7:19 PM, Chris Harrelson wrote: > Hi, > > Another quick update: Emilio, Navid, Nick, Stefan and I met today and > discussed which issues are important to fix and why. We now have a list of > spec issues, and WPT tests to fix that are Chromium bugs, that should > substantially improve interop. Nick and Stefan will take on the work to fix > them, with the review and feedback support of Emilio. So, today another scroll-anchoring bug crossed my radar, and this one I'm not sure at all how to fix it, because there's no obvious answer here as far as I can tell. My diagnosis (for one of the pages, the one I could repro and reduce) is in here[1], but basically my current explanation is that the page should be broken per spec, and that when it works it's hitting a bug in both Chromium[2] which we have an equivalent of but are just not hitting because in Firefox changing `overflow` does more/different layout work than in Chrome. The test-case may as well work if we change our scroll event or timer scheduling (see there), but that is obviously pretty flaky. I honestly don't have many better ideas for more fancy heursitics about how to unbreak that kind of site. From the point of view of the anchoring code, the page is just toggling height somewhere above the anchor, which is the case where scroll anchoring _should_ work, usually. I can, of course (and may as a short-term band-aid, not sure yet) add `overflow` to the magic list of properties like `position` that suppress scroll anchoring everywhere in the scroller, but that'd be just kicking the can down the road and waiting for the next difference in layout performance optimizations between Blink and Gecko to hit us. I think (about to go on PTO for the next of the week) I'll add telemetry for pages that have scroll event listeners, and see if disabling scroll anchoring on a node when there are scroll event listeners attached to it is something reasonable (plus adding an explicit opt-in of course). I'm not terribly hopeful that the percentage of such documents is going to be terribly big, to be honest, but providing an opt-in and doing outreach may be a reasonable alternative. Another idea would be to restrict the number of consecutive scrolls made by scroll anchoring to a given number at most. That would made the experience in such broken websites somewhat less annoying, but it'll also show flickering until that happens, which would make the browser still look broken :/. Thoughts / ideas I may not have thought of/be aware of? Thanks, -- Emilio [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1592094#c15 [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=920289 > Thanks all, > Chris > > > On Thu, Oct 10, 2019 at 2:13 PM Rick Byers <rbyers(a)chromium.org> wrote: > >> Sorry for the delay. >> >> We agree that scroll anchoring has unrealized potential to be valuable for >> the web at large, and to make that happen we should be investing a lot more >> working with y'all (and if we can't succeed, probably removing it from >> chromium). Concretely +Chris Harrelson who leads rendering for Chrome (and >> likely someone else from his team), as well as +Nick Burris from the Chrome >> input team will start digging in ASAP. In addition to just the normal >> high-bandwidth engineer-to-engineer collaboration between chromium and >> gecko I propose the following high-level goals for our work: >> >> - Ensure that there are no known deviations in behavior between >> chromium and the spec (one way or the other). >> - Ensure all the (non-ua-specific) site compat constraints folks are >> hitting are captured in web-platform-tests. I.e. if Gecko passes the tests >> and serves a chromium UA string it should work as well as in Chrome (modulo >> other unrelated UA compat issues of course). >> - Look for any reasonable opportunity to help deal with UA-specific >> compat issues (i.e. those that show up on sites that are explicitly looking >> for a Gecko UA string or other engine-specific feature). This may include >> making changes in the spec / chromium implementation. This is probably the >> toughest one, but I'm optimistic that if we nail the first two, we can find >> some reasonable tradeoff for the hard parts that are left here. Philip (our >> overall interop lead) has volunteered to help out here as well. >> >> Does that sound about right? Any suggestions on the best forum for tight >> engineering collaboration? GitHub good enough, or maybe get on an IRC / >> slack channel together somewhere? >> >> Rick >> >> On Mon, Oct 7, 2019 at 2:11 PM Mike Taylor <miket(a)mozilla.com> wrote: >> >>> Hi Rick, >>> >>> On 9/28/19 10:07 PM, Rick Byers wrote: >>>> Can you give us a week or so to chat about this within the Chrome team >>>> and get back to you? >>> >>> Any updates here? >>> >>> Thanks. >>> >>> -- >>> Mike Taylor >>> Web Compat, Mozilla >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to blink-dev+unsubscribe(a)chromium.org. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-DPW4tXA_… >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-DPW4tXA_…> >> . >> > _______________________________________________ > dev-platform mailing list > dev-platform(a)lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform >

1 0