On 1/16/20 8:35 AM, Frederik Braun wrote:
How much of this platform-dependent rendering is web observable? If yes, I guess we'll need an escape hatch for Resist Fingerprinting Mode.
This doesn't feel particularly worse than our platform-dependent form controls. Height of <input> is different in different platforms for example, and you can query it trivially from script to make a guess.
I _think_ you could observe outline overflow areas from JS without much trouble.
I'm not aware of any RFP mitigations for form controls and such, though if there are some, or plans to add some then I'm happy to hook outline-style: auto into them or what not.
-- Emilio
Emilio Cobos Álvarez <emi...@mozilla.com <mailto:emi...@mozilla.com>> schrieb am Mi., 15. Jan. 2020, 19:27:Hi, In bug 1031664 I plan to enable the themed rendering of outline-style: auto. Standard: https://www.w3.org/TR/css-ui/#outline-style <https://www.w3.org/TR/css-ui/#outline-style> (sorry for the TR version, but I have problems to access the current draft without building it locally :/) Platform coverage: Linux, Mac, Windows Preference: layout.css.outline-style-auto.enabled DevTools bug: N/A (works fine with existing tools) Status in other browsers is: * EdgeHTML: Doesn't parse the value at all. * Safari: Supports the value as intended, by using the platform theme. * Chromium: Parses the value, and outputs a fixed-width outline in chromium with a slight radius (at least on Linux and Windows, not sure about Mac). It respects outline-color which is a bit weird. * Epiphany: Uses 1px dotted outline instead, with some weird effects if you change outline-width. Also respects outline-color. Without this patch, our current behavior is that we just treat auto as solid, respecting width (unlike other browsers), and color (unlike Safari, but like Chrome). With this patch our behavior would match Safari's, effectively. web-platform-tests: This is pretty hard to test in WPT, as it is platform and browser-dependent behavior. Secure contexts: This is not restricted to secure contexts, like other CSS features, and features that other browsers ship in insecure contexts. Addendum: I want to use the auto value as the default for our form controls, so that I can fix bugs like [1] by omitting its rendering for themed form controls. That is not _theoretically_ blocked by this change, I guess, as we have the auto value in the computed style anyway, but it'd be nice to show the native outline even if the form control is not themed. Also falling back to solid for form controls may not be great (other focused things use dotted outlines). If we find any compat issues / developer or user complaints due to this (specially on Windows / Linux), we should probably reconsider and take an approach more similar to Chromium / Epi's and remove the widget-specific implementations. But I think it'd be nice to do what the feature was intended for, I think. That being said, given the (clearly sub-standard) compat situation, let me know if you think it's better to keep it turned this on only for Nightly / Beta for a release or two. We're early in the cycle but... If you find any rendering problems with them or pages looking worse because of them, please file a bug blocking bug 1031664 and needinfo me or such. Thank you, -- Emilio [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1311444 <https://bugzilla.mozilla.org/show_bug.cgi?id=1311444> _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org <mailto:dev-platform@lists.mozilla.org> https://lists.mozilla.org/listinfo/dev-platform <https://lists.mozilla.org/listinfo/dev-platform>
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
