April 2021 - webkit-dev - lists.webkit.org

Request for Position: COLR v1 Vector Color Fonts
by Dominik Röttsches 03 May '21

03 May '21

Hi, This is a request for WebKit's position on COLR v1 vector color fonts. Spec: https://github.com/googlefonts/colr-gradients-spec/blob/main/OFF_AMD2_WD.md *Proposed changes to ISO/IEC 14496-22 (Amendment 2)* Chromium Bug: https://crbug.com/1170733 Summary: COLR v1 fonts are a new vector color font format that provides gradients, transforms and compositions for font glyph drawing enabling an expressive, very compact glyph definition format for OFF/OpenType fonts. This format provides size and rendering fidelity (scaling) advantages over bitmap fonts such as SBIX, CBDT/CBLC fonts for glyph designs that lend themselves well to being encoded as vector art. Thank you in advance for your position statement on this topic, Dominik

2 2

Is valgrind suppressions.txt unused
by Aakash Jain 30 Apr '21

30 Apr '21

Hi Everyone, Is anyone (particularly gtk folks) are using valgrind especially suppressions.txt file (https://github.com/WebKit/WebKit/blob/main/Tools/Scripts/valgrind/suppressi…) This file doesn't seems to be modified for a long time, so I am not sure if this is even being used. I am looking into using inclusive naming, and this file contains the term 'slave' (as "fun:gtk_im_multicontext_get_slave"). I can look into that specific line as well, but I was wondering if the file is used at all or not. Thanks Aakash

1 0

Request for position: Removing 3DES from TLS
by David Benjamin 29 Apr '21

29 Apr '21

Hello WebKit friends, We're looking at dropping 3DES cipher suites from TLS. For us, this is just TLS_RSA_WITH_3DES_EDE_CBC_SHA. Looks like Safari additionally supports TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA and TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, which would also fall under that category. After TLS 1.0 and 1.1 were removed, our metrics report a whole 0.00% of TLS connections using TLS_RSA_WITH_3DES_EDE_CBC_SHA. (And, of course, no sites use the other two in Chrome, since we don't support them in the first place.) For additionally background and motivation, see the blink-dev posting here. https://groups.google.com/a/chromium.org/g/blink-dev/c/RShdgyaDoX4/m/JikQYH… David

3 5

Request for Position on Delegated Ink Trails
by Mario Bianucci 29 Apr '21

29 Apr '21

Hi webkit-dev, This is a request for WebKit's position on Delegated Ink Trails. It is currently in progress behind a flag in Chromium. There is no spec yet, but here is a link to the WICG explainer: https://github.com/WICG/ink-enhancement Thanks, Mario Bianucci (Apologies for the noise if you received this twice - I wasn't subscribed to webkit-dev earlier.)

1 0

Mailman web interface missing
by Adrian Perez de Castro 28 Apr '21

28 Apr '21

Hello all, Mailing lists seem to be working fine, and web pages for their archives are accessible, for example https://lists.webkit.org/pipermail/webkit-wpe/ works fine—but on the other hand the Mailman administrative interface seems to have gone the way of the dodo: - https://lists.webkit.org/listinfo/webkit-wpe/ results in “Not Found” - https://lists.webkit.org/admindb/webkit-wpe/ results in “403 Forbidden” I noticed this a couple of days ago because I got a notification from Mailman that there are messages pending moderation for the WPE mailing list; but I cannot do anything about that because the web interface (second link above) does not seem to work. Could anyone at Apple please take a look at this? Thanks in advance! —Adrián

2 3

New EWS queue: Stress Test EWS
by Aakash Jain 28 Apr '21

28 Apr '21

Hi Everyone, I am happy to announce that I have added a new EWS queue: Stress Test EWS. From now on, you would see a new status bubbles (on Bugzilla bug) named: 'mac-wk2-stress'. For the patches that add or modify layout tests, this EWS will run those added/modified layout-tests repeatedly large number of times (currently 100 iterations). It will also run those added/modified layout-tests repeatedly in guard-malloc mode. Example: https://ews-build.webkit.org/#/builders/62/builds/249. The aim is to find any issue with the layout-tests, especially flakiness, or failure when run in a certain manner. Flaky layout-tests are currently a huge problem, as they sometimes cause false positives on EWS (and other parts of infrastructure), and slow down our infrastructure (as for every test failure, EWS needs to run the test-suite few times to ensure the failures are not flaky or pre-existing). Until now, we didn't have any good automated way to indicate the test flakiness to the engineers. With this EWS, we are adding pre-commit testing for layout-test flakiness. We understand that layout tests might be flaky in a variety of ways, sometimes in a very specific or unexpected manner. I am looking at covering more and more scenarios in this EWS by making incremental improvements to it. Few ideas to further improve this EWS are: - Test on more OS/configurations (this EWS is currently using macOS release wk2 mode) - Run the test being added/modified repeatedly along-with other layout-tests in same directory - Improve the logic to identify layout-tests, current logic is naive and only recognizes html layout-tests More ideas are welcome. Thanks Aakash

3 2

Detecting and handling unresponsive web processes
by Miguel Gomez 28 Apr '21

28 Apr '21

Hi WebKit folks! I'm working on improving the detection of unresponsive web processes and how to recover from that situation on the GTK and WPE ports. Investigating how ResponsivenessTimer and BackgroundProcessResponsivenessTimer work, I see that currently there are 3 ways to detect that the process has become unresponsive: * When there's an user event, the event is passed to the web process and the ResponsivenessTimer is started to check whether there's an answer from the web process in the next 3 seconds. If this doesn't happen, the process is marked as unresponsive. * Same that above, but started from some API call (like reload for example) instead of an user event. * When the WebProcessProxy doesn't have visible pages or it's used for a ServiceWorker, the BackgroundProcessResponsivenessTimer will periodically ping the web process, and mark it as un responsive when there's no answer. This is enabled for non Apple ports only. What I see is that there's no way to check the responsiveness of the web process when there are no API calls or the user is not interacting with the page. I'm thinking on the user watching a video without interacting with the page, or some JS script locking the main thread at some point. To improve this, I've created https://bugs.webkit.org/show_bug.cgi?id=224862 and sent a patch for the ResponsivenessTimer to send a ping to the web process every ten seconds after the last reply from the web process. I was thinking of enabling this feature only for GTK and WPE, but maybe some other ports are interested as well. Just answer this or add some comment to the bug and I'll remove the platform guards. Also, in https://bugs.webkit.org/show_bug.cgi?id=224359 I added a property to WebKitWebView (in GTK and WPE) to signal the web process responsiveness, so with these 2 things the detection should be covered. Then there's the problem of recovering from an unresponsive web process. We should probably show a warning to the users so they can decide whether to wait or stop the page. And then, what to do if the user decides to stop the page? I see 2 options here: * Have some API method that allows to kill the problematic web process, and let the browser call it when needed. The next load will create a new web process. * Modify some of the existent load/reload API calls so they check whether the web process is responsive or not. If it's unresponsive, kill the process before trying to do anything else, and a new web process will be created when the rest of the code is executed. On https://bugs.webkit.org/show_bug.cgi?id=224533 we were leaning towards the second option, so we don't need to add new API and the whole situation is handled inside WebKit. But studying the code I found that the Apple ports seem to use the first one: the object handling the responsiveness is an external class that implements the WKNavigationDelegate inteface, and I guess it uses _killWebContentProcess or _killWebContentProcessAndResetState in order to kill the web process before loading some new content. Am I right regarding how Apple ports work? If the answer is yes, is there any special reason to do it what way? Should we follow that approach too? WDYT? Regards! -- Miguel Gomez Igalia - www.igalia.com

2 3

EWS offline for maintenance for about an hour
by Aakash Jain 24 Apr '21

24 Apr '21

Hi Everyone, We need to do some maintenance on the EWS bots (in order to switch the repository from git.webkit.org to https://github.com/webkit/webkit, https://bugs.webkit.org/show_bug.cgi?id=220479) EWS buildbot will be offline for about an hour, so it wouldn't process any new builds. However, EWS status-bubbles will still keep loading on Bugzilla. Thanks Aakash

1 5

Request for position: Element/FrozenArray<Element> IDL attribute reflection
by Alice Boxhall 23 Apr '21

23 Apr '21

Hi WebKit engineers, I've been working with Ryosuke Niwa and James Craig (and others) on developing a design for a mechanism to allow setting and getting an Element or a FrozenArray<Element> as the value for an IDL attribute which reflects a content attribute which takes an IDREF or IDREF list. As a short example, that would look like: <label> Phone number: <input type="tel"></label><span id="description">Please include international country code, e.g. +61</span> const input = document.querySelector('input');const description = document.getElementById('description'); input.ariaDescribedByElements = [description]; You can read the more detailed explainer <https://github.com/WICG/aom/blob/gh-pages/element_reference_properties.md> for more in-depth examples and edge cases - please note that this explainer is written for an audience of web content authors, and as such some of the terminology doesn't precisely line up with spec terminology. The current spec draft is here: https://github.com/whatwg/html/pull/3917 At this point, we have an implementation <https://www.chromestatus.com/feature/6244885579431936> ready for developer trial which matches the API described in the spec draft and explainer. We're wondering what interest WebKit as a whole has in this API. In particular, there is an open question <https://github.com/whatwg/html/pull/3917#discussion_r603794547> as to whether FrozenArray<Element> is a good choice, given validation constraints (in part to avoid leaking Shadow DOM internals) mean that it violates <https://github.com/WICG/aom/blob/gh-pages/element_reference_properties.md#n…> the self-equality part of the "Attributes should behave like data properties" <https://w3ctag.github.io/design-principles/#attributes-like-data> TAG design principle. Dominic Mazzoni (cc'd) is also participating in this design process, and will be able to answer any clarifying questions that might arise. Thanks! Alice

2 1

Re: [webkit-dev] Request for Position: COLR v1 Vector Color Fonts
by Peter Constable 20 Apr '21

20 Apr '21

Sorry for a slow response on this topic. I have some thoughts in reply to Myles' comments. Before jumping in, let me mention that Microsoft in general is supportive of the COLR v1 proposal, and has contributed to its development; and Microsoft's web-platform team is aligned with Chromium on COLR v1 support. Now for specific remarks. I'm looking at this from the perspective of what makes sense for the OpenType spec and colour fonts generally, though along the way I'll take into consideration what may or may not make sense for WebKit. >Inversely, here is a list of things we don't like about the proposal: >It re-invents the wheel. This new format is as expressive and powerful as any general-purpose 2D graphics serialization format. There are many, many existing serialization formats for general-purpose 2D graphics. It's fair to ask whether there is some existing, binary serialization format. And, I find it particularly interesting since, in past interactions (five or so years ago), I was given to understand that Apple engineers would have been interested if Microsoft had pursued a COLR enhancement or _some_ vector format for color glyphs _other than_ SVG. For an enhancement in OT, I'd rule out something based on XML (or JSON, etc.) rather than a binary format since these are inherently less efficient size-wise. There are, of course, things like .swf, .emf, .eps, and of course .pdf, though I don't know of any that would clearly a better choice: If they're not too product-specific (such as .emf), they're also too generic, supporting far more than is needed. We'd face the same issue you'll recall we had with OT-SVG of figuring out what parts to explicitly exclude. (It's the same issue why, in the OT spec, PDF is excluded as a supported format for the sbix table.) Moreover, none of those formats can take advantage of tables OT already has for representation of vector geometries: the 'glyf', CFF or CFF2 tables. (This is an issue, as well, for OT-SVG.) >It doesn't exist yet (outside of a development configuration of Chrome). "Doesn't exist elsewhere" could have been used to argue against any number of other things. It could have been used as an argument against adding variations to OT back in 2016. I don't think it's a useful argument of itself. Rather, one needs to ask whether or not there are technical merits that might make a case for supporting it elsewhere. >OT-SVG, which is just as expressive*, exists and has shipping implementations in DirectWrite, Core Text, Firefox, and many (most? all?) of Adobe creation apps. That's true; but one can't say that OT-SVG is ubiquitous by any stretch. As we know, it's not supported in Chromium. But there are also many other contexts in which the OT spec is supported as a font format, yet in which OT-SVG is not; and there's fair reasons to think there are contexts in which OT-SVG would not likely be supported if there were another binary-format alternative. OT / OFF is supported in lots of consumer electronic or other classes of device beyond computers and phones. There will be many small-device contexts in which there may be interest in colour fonts but in which there will concerns such as size that will make OT-SVG less than ideal. > Many OT-SVG fonts already exist. Yes, there are existing OT-SVG fonts. But OT-SVG fonts aren't _that many_ in number, and aren't exactly taking off. I suspect that font developers have shied away because there hasn't yet been one clear winner for colour font format. >Because this proposal doesn't exist yet outside of Chrome, there is no ecosystem in existing authoring tools. Again, this is the "doesn't exist elsewhere" argument I commented on above. >Conversely, many design authoring tools already export SVG. True; and I expect that SVG will remain an important format in COLR v1 font development workflows because it is a common format supported in most/all graphics-authoring tools. In that regard, it's a much better choice as input to a font compiler than font-compilation tools having to support a variety of formats supported in various graphics-authoring apps-.eps, .ai, .dwg, etc.. But support for SVG as an input format doesn't imply that font compilation tools wouldn't support compilation from SVG to COLR v1: I suspect the consideration for the likes of FontLab and Glyphs will be about how many of their customers want to generate COLR v1 fonts, and not about whether they could otherwise have generated OT-SVG fonts. I can't predict that FontLab, etc. _will_ support compilation to COLR v1. My point is only that I don't see this as a strong argument against enhancing OT with COLR v1 and supporting it in apps or on the Web. Of course, for browser / application developers, availability of font tools to generate COLR v1 is not irrelevant since it's an indirect predictor of the prevalence of COLR v1 fonts. For app developers, current or anticipated prevalence of COLR v1 fonts will certainly be an important consideration. If you're saying that you _do not_ anticipate much use of COLR v1 in fonts, then I can't really argue against that since there isn't enough data yet one way or another. >Supporting both OT-SVG and this new proposal is twice (-ish) the maintenance burden, for a format that isn't any more expressive* than the format we support already. Supporting both OT-SVG and this new proposal increases our binary size. We expect the additional binary size increase to be roughly equivalent to the binary size increase we observed after implementing OT-SVG. (OT-SVG does involve an XML parser, but WebKit already links with an XML parser, so we expect the size of this new proposal to be roughly equal to the size increase we saw after implementing OT-SVG. That's a fair argument... for a browser developer whose product already has XML and CSS parsers built in. But as mentioned above, there are many other contexts for OT fonts that do not have independent reason to support SVG/XML/CSS parsers. For those contexts, your reasoning above strongly suggests that the runtime binary size increase for supporting COLR v1 would be _much smaller_ than for supporting OT-SVG. This isn't making the case that, therefore, WebKit should support COLR v1 at this time; but I think it does make the case that, in the long term, COLR v1 may have an advantage over OT-SVG for at least some app or device contexts in which colour font support might be considered. > This proposal would require its own novel parsing / overflow detecting / interpretation code.) Supporting both OT-SVG and this new proposal roughly doubles the surface area for security attacks for vector-based color fonts. Even considering an engine that only supports this proposal and not SVG, we haven't seen any evidence that avoiding XML will reduce security bugs compared to a novel binary format. Historically, in WebKit, we've observed that opaque binary formats (like image formats) have plenty of their own security bugs. True, it will require new parsing. That will be true of any new enhancement to OT. Of course, that comes with new surface area for security attack. This is a cost to be considered for many potential features that might be considered for software products. As is always the case, the fact that there are such costs isn't of itself a deal-breaker, but one considers this with other costs of development to evaluate against anticipated benefits. >The spec has over 2,500 lines, and the images/ directory of the spec has 77 figures, and there is only a single implementation of this proposal. It's complicated enough that we're not confident that it can be implemented interoperably. I don't think it's actually all that complicated. There was potential to misunderstand: I, myself, misunderstood important aspects of the proposed design on reading an earlier, much shorter proposal doc. And I made a point to put lots of details into the spec with a view to providing clarity that would lead to interoperability. The possibility that implementations will not be interoperable is a hypothesis that would be empirically tested each time someone attempts to implement. But I'm not sure it's valid to make a sweeping generalization that it's too complicated to lead to interoperability. That feels to me like a premise being crafted to support an a priori conclusion. If you can point to specific aspects of the spec that are not sufficiently clear, then that would be helpful --- and the spec can be improved. Frankly, I think variations was **much** more complex than this. * The amount of content added to the spec for variations was **well over double** that added for COLR v1, and that was for mostly extending existing concepts with a few new concepts versus mostly-new concepts for COLR v1. * Variations introduced eight entirely new top-level tables, versus zero new tables for COLR v1. * The binary formats added for variations included several complexities: * run-length-encoded data; * table members that semantically comprise multiple sub-fields that need to be parsed and processed separately; * many places in which inter-table references and validations are involved; and * several new concepts that interact in complex ways (see how many people can explain why HOI works). In contrast, the new formats for COLR v1 are much simpler to parse with only a few inter-table references ('glyf' or CPAL entries) or validations (maxp.numGlyphs). Yet very quickly many different implementations for variable fonts arose with a high degree of interoperability. > We're worried the behavior of the drawing operations may be specific to Skia, and difficult/impossible to implement on Core Graphics. For example, at first glance, we are not sure that the radial gradients in this proposal can be implemented on Core Graphics. The radial gradients are very similar to those defined in PDF and those in HTML Canvas 2D, the only differences being with extend modes. > As far as we're aware, this proposal has not undergone a rigorous standardization process from many independent stakeholders. It is in the midst of that very process. There is an alpha for OT 1.9 published for broad review (OpenType 1.9 Alpha Review - Typography | Microsoft Docs<https://docs.microsoft.com/en-us/typography/opentype/otspec190alpha/ot190al…>); a working draft for the corresponding ISO standard has been available for review for several months; and there have been a number of technical comments submitted from reviewers that have been addressed in the spec. >Embedding raster image data inside color font tables is common today, but this new proposal has no affordances for allowing it, despite its vector facilities being as expressive as any general-purpose 2d graphics serialization format. Therefore, it doesn't actually improve upon the color font table fragmentation situation, which is widely regarded as one of the biggest drawbacks to color fonts today. I'm a little puzzled as to why a lack of support for raster data embedded within COLR v1's vector formats is seen is a big gap. Raster data with a vector image might be useful as a pattern fill that can be repeated as the geometries are scaled, but otherwise a raster image doesn't scale, which is a key aspect of vector graphics. Addition of patterns is something that could potentially be added in the future. Also, noting that, in some cases, someone might want to a raster image alone as a colour glyph for a character, giving the designer control over every pixel, nothing in the spec prevents a hybrid approach in which colour glyphs for some characters are implemented as vector data using COLR v1 while the colour glyphs for some other characters are implemented as raster data using sbix. If raster image data were assumed to be the best of all possibilities for colour glyphs that would put an end to the colour font fragmentation problem, then I think that's clearly not a valid assumption since colour raster formats have been available to font developers since colour fonts first became a thing almost a decade ago. >Given these two lists, Apple's WebKit team and Core Text team are negative on this proposal. As one vendor considering support in an app, I can certainly understand a perspective of saying, This has costs but doesn't provide immediate benefits for what I use in my products. When considering support in a platform or an app that needs to support user content, I can certainly understand a perspective of saying, I will wait to see how much demand there will be. But there are several aspects in the reasoning given by Myles that I don't find compelling. Cheers! Peter

1 0