Intent to prototype and ship: Make mac mouse focus model closer to other platforms
Summary: Mac currently doesn't focus form controls (like buttons) with the mouse. This follows Safari's platform convention, however it also means that Firefox behaves inconsistently for web developers across platforms. I plan to enable the accessibility.mouse_focuses_formcontrol pref (only has an effect on Mac) by default in bug 1614658. There's a bit more reasoning on the commit message of that bug, but tldr apart of consistency, it also fixes some focus navigation edge cases and makes :focus-visible behave more like you'd expect. One important note is that (by default at least) this shouldn't result in more outlines being shown when clicking on form controls. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1614658 Standard: N/A Platform coverage: This is a Mac only change, and will match all other platforms. DevTools bug: N/A Other browsers: Behavior matches Firefox behavior on non-mac platforms, and Chromium browsers, but diverges from Safari. web-platform-tests: Some focus-visible tests start passing with this change on mac, but other than that I don't plan to add more WPTs since this is not really standardized. -- Emilio ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
intent to ship: sha2 windows signing
Per https://bugzilla.mozilla.org/show_bug.cgi?id=1697185#c4 and https://jira.mozilla.com/browse/RELENG-429 . We haven't made a product-level decision here, but a) it looks like timestamp.digicert.com may have silently EOLed sha1 timestamps since Microsoft has EOLed sha1 signing years ago, and b) it may be the case that changing the signature may only affect Windows 7 SP 0 users on first install. I'm not 100% sure about the second point. Should we continue testing and rolling out, or pause work here until we make a product decision? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to prototype: glyph-scale-factor descriptor for @font-face rules
On Monday, March 15, 2021 at 1:39:36 PM UTC+1, Jonathan Kew wrote: > Summary: For a given "font size" as expressed e.g. in CSS px or points, > different fonts can vary significantly in how visually large they look. > The nominal "font size" does not necessarily relate to any specific > dimension of the glyphs; it sizes the coordinate space within which the > glyph shapes are drawn, but different designs may fill that space in > very different ways. > > The proposed glyph-scale-factor descriptor (name to be bikeshedded) will > allow authors to adjust the scaling of individual fonts loaded using > @font-face, to better harmonize the visual sizes of different designs, > or to more closely match a fallback face to a resource that may be > swapped in later, thereby minimizing visual layout shift when the final > font becomes available. > > Unlike modifying the font-size property, this will scale the glyphs (and > metrics) of the font but will *not* affect things like the CSS 'em' > unit. It affects how glyphs scale within the font's em square, not the > size of the em square itself. > > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1698495 > > Standard: This is currently under discussion for CSS Fonts 5; details > still to be worked out. See https://github.com/w3c/csswg-drafts/issues/6075. > > Platform coverage: All > > Preference: layout.css.glyph-scale-factor.enabled > > DevTools bug: None needed. (More generally, it would be awesome to have > a @font-face rule inspector in DevTools -- distinct from the existing > font *properties* inspector; such an inspector would expose this along > with the other @font-face descriptors. But that's not specific to this > new descriptor.) > > Other browsers: > Blink: Considering (already experimented with possible implementation, > see https://github.com/w3c/csswg-drafts/issues/5533#issuecomment-714166725). > Webkit: Present in CSS WG discussions but no clear signals yet AFAIK. > > web-platform-tests: To be added to web-platform/tests/css/css-fonts (as > .tentative initially, until spec is finalized). If I'm not mistaken, the CSS WG ended up naming the descriptor 'size-adjust'. See https://github.com/w3c/csswg-drafts/pull/6108. Sebastian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ PSA: Use [[nodiscard]] instead of MOZ_MUST_USE
Bug 1571631 has landed. The `MOZ_MUST_USE` macro has been removed and all uses have been replaced with C++17's `[[nodiscard]]` function attribute. Use [[nodiscard]] instead of MOZ_MUST_USE. One caveat: unlike MOZ_MUST_USE, [[nodiscard]] must precede all of a function declaration's declaration specifiers (like static, extern, inline, or virtual): - static inline MOZ_MUST_USE nsresult SomeFunction(); + [[nodiscard]] static inline nsresult SomeFunction(); Next steps: 1. Replace MOZ_MUST_USE_TYPE type declarations with [[nodiscard]]. Bug 1628542 2. Consider removing `mozilla::Unused`, replacing over 3000 uses of `Unused << SomeFunction()` with a more idiomatic `(void) SomeFunction()` cast. mozilla::Unused was a workaround for the fact that gcc didn't allow MOZ_MUST_USE (`__attribute__((warn_unused_result))`) warnings to be suppressed with a void cast. Because this change would touch so many files, it's probably not worth the trouble. Bug 1628542 On 12/21/2020 4:20 PM, Chris Peterson wrote: Now that Firefox is compiled as C++17 (bug 1560664), you can use C++17's [[nodiscard]] attribute [1] instead of the MOZ_MUST_USE macro (defined using clang and gcc's non-standard __attribute__((warn_unused_result))). I have been slowly replacing MOZ_MUST_USE with [[nodiscard]] in my free time and hope to eventually remove the MOZ_MUST_USE definition itself. That is meta bug 1571631. In the meantime, please: 1. Avoid adding more uses of MOZ_MUST_USE. Use [[nodiscard]]. 2. Consider making more functions use [[nodiscard]] when writing or reviewing new code. Functions that return errors as nsresult or bool are probably good candidates for [[nodiscard]]. (I looked at adding [[nodiscard]] to the nsresult type definition, but the results were too noisy.) One caveat: the [[nodiscard]] attribute must precede all of a function declaration's declaration specifiers (like static, extern, inline, or virtual). The __attribute__((warn_unused_result)) attribute (and thus MOZ_MUST_USE) does not have this order restriction. - static inline MOZ_MUST_USE nsresult SomeFunction(); + [[nodiscard]] static inline nsresult SomeFunction(); Once __attribute__((warn_unused_result)) has been replaced with [[nodiscard]], we can also remove mozilla::Unused, replacing `Unused <<` with a more idiomatic `(void)` cast (bug 1628542). [[nodiscard]] can also be applied to types, so we may be able to replace our custom MOZ_MUST_USE_TYPE clang plugin with [[nodiscard]]. [1] https://en.cppreference.com/w/cpp/language/attributes/nodiscard ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
