Intent to prototype and ship: make width and height map to aspect-ratio for , and

[Emilio Cobos Álvarez]

Summary: We do this for  already, and HTML was changed a while ago 
to do this for  /  / .


It seems like an uncontroversial change.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1700640

Standard: 
https://html.spec.whatwg.org/#attributes-for-embedded-content-and-images


> The width and height attributes map to the aspect-ratio property on 
img, canvas, and video elements, and input elements with a type 
attribute in the Image Button state.


There are some edge cases about  and zero-valued attributes 
which I've filed as https://github.com/whatwg/html/issues/6527.


Platform coverage: all

DevTools bug: N/A

Other browsers:

 * Chrome: They implement that though I don't know if it's shipped or 
not (https://chromium-review.googlesource.com/c/chromium/src/+/2642857 / 
https://chromium-review.googlesource.com/c/chromium/src/+/2650135 / 
https://chromium-review.googlesource.com/c/chromium/src/+/2690929).


 * Safari: They only implement  I _think_.

There's another follow-up change we need to implement which is 
supporting it in  elements for , but that's a more 
involved change.


web-platform-tests: 
https://wpt.fyi/results/html/rendering/replaced-elements/attributes-for-embedded-content-and-images?label=master=experimental


 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: printf_stderr now works out of the box on Windows

[Emilio Cobos Álvarez]

On 3/19/21 21:12, Jeff Muizelaar wrote:


15 years ago we landed a change to make printf_stderr reopen fd 2
instead of using stderr directly to work around a linking issue. This
prevented printf_stderr from showing up in the console on Windows.

I landed https://bugzilla.mozilla.org/show_bug.cgi?id=1680402 this
week to fix this.

Now you don't have to redirect fd 2 to a file to see printf_stderr.


First, thanks a lot for fixing this. Every single time I need to debug 
something windows-specific and I had to printf something I had to 
remember the right incarnation to use.


Does this work now on content processes out of the box? Or do we still 
need to disable the sandbox or what not to see those?


 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to prototype and ship: Make mac mouse focus model closer to other platforms

[Emilio Cobos Álvarez]

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

Re: Intent to ship: Return pixel deltas in wheel event if deltaMode is not checked by authors

[Emilio Cobos Álvarez]

On 3/9/21 20:36, James Graham wrote:

It seems like having all browsers have the same behaviour is going to be
better in the long run than having some weird heuristic in gecko that
acts as a footgun for authors going forward.

Do we have any way to assess the compat impact of switching to match
Blink and WebKit always?


Not an easy one that I can think at least. We can measure how often 
pages access the deltas without the deltaMode or vice versa, but it's 
not clear to me how to correlate that to broken or good behavior easily.


I guess we could enable the always-disabled pref on Nighly and watch for 
a few releases to see if there's reports of broken sites. Would that 
seem reasonable to you?


 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Return pixel deltas in wheel event if deltaMode is not checked by authors

[Emilio Cobos Álvarez]

On 3/9/21 17:10, Anne van Kesteren wrote:


On Tue, Mar 9, 2021 at 4:45 PM Emilio Cobos Álvarez  wrote:

Let me know if you have any concerns with this or what not.


So if I understand it correctly we'll have a getter with side effects.
Is the expectation that we can eventually remove this? Are other
browsers on board with this model?


Well, the side effect is not _quite_ that bad IMO, in the sense that the 
page can't really tell whether the event is returning pixels because the 
scroll was actually pixel-based (e.g., trackpads do this IIRC) or 
because they didn't check deltaMode.


The only alternative to this that I can think of is basically never 
return DOM_DELTA_LINE (which is what other browsers do in practice), but 
that seemed both more risky for us, and also a potential regression 
(knowing lines can be useful).


  -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: Return pixel deltas in wheel event if deltaMode is not checked by authors

[Emilio Cobos Álvarez]

Hi,

In bug 1696384, I plan to enable 
dom.event.wheel-deltaMode-lines.disabled on all channels.


This is a compat intervention for sites that check 
WheelEvent.delta{X,Y,Z} before checking WheelEvent.deltaMode, generally 
assuming that the deltas are going to be pixels.


These deltas are environment-specific, generally, and authors are always 
expected to check the deltaMode to determine how to scroll, see:


  https://w3c.github.io/uievents/#events-wheelevents

But other browsers historically have always returned pixels, and some 
websites depend on that behavior. That makes Firefox feel super-slow on 
those websites (as the site scrolls by e.g. 3 pixels rather than the 
equivalent 3 lines of content). See bug 1392460 and webcompat issues 
linked from there.


The behavior is the following, decided per event:

 * If deltaMode has been accessed, or the feature is disabled, then 
return the original delta mode and deltas (no behavior change from 
current release).


 * If deltaMode has _not_ been accessed, and it's DOM_DELTA_LINE, 
accessing any of the deltas cause the event to always report 
DOM_DELTA_PIXELS, and the deltas get appropriately converted to pixels too.


There are three prefs involved in controlling the behavior:

 * dom.event.wheel-deltaMode-lines.disabled: This is the global switch 
and if false the behavior doesn't change. If true, it implements the 
behavior described above.


 * dom.event.wheel-deltaMode-lines.always-disabled: This implements the 
behavior of converting lines to pixels unconditionally (without 
depending on event ordering etc). Mostly intended for debugging.


 * dom.event.wheel-deltaMode-lines.always-enabled: This is a domain 
list for domains that might need to switch to the previous behavior. I 
really think that given how this is implemented it shouldn't cause 
trouble for most websites (the pref has been on on nightly for 4 months, 
with no serious regressions), so it should hopefully remain empty.


Let me know if you have any concerns with this or what not.

Cheers,

 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to prototype: CSS color-mix() function.

[Emilio Cobos Álvarez]

Summary:

Hi,

In bug 1695376, if all goes well, I plan to land a basic version of the 
color-mix() function. This is a trimmed down version of the spec (link 
below).


Firefox engineers requested this, and I also think this minimal version 
is super-useful on its own, without being blocked on all the HDR color 
stuff that we haven't implemented yet.


Bug: https://bugzil.la/1695376

Standard: https://drafts.csswg.org/css-color-5/#color-mix

Note that I'm only implementing the basic color-mix syntax without 
per-color-channel adjustments (so just a set of colors and weights), and 
I obviously haven't implemented the lab / lch / etc bits because we 
don't support those colors yet.


Platform coverage: all

Preference: layout.css.color-mix.enabled

DevTools bug: https://bugzil.la/1695382

Other browsers: Other browsers don't support this yet, to my knowledge. 
Safari has started implementing some of the CSS colors for other color 
spaces, though not sure if they ship that.


web-platform-tests: I added some basic WPTs that check parsing and that 
the interpolation matches the one from CSS animations. More tests are 
needed before shipping something like this of course.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to prototype and ship: :user-valid and :user-invalid pseudo-classes.

[Emilio Cobos Álvarez]

On 2/23/21 09:24, Anne van Kesteren wrote:

On Mon, Feb 22, 2021 at 2:59 PM Emilio Cobos Álvarez  wrote:

Let me know if you have any objections about this change, but I think
having a prefixed pseudo-class for this is not a great state of affairs.


This seems reasonable, but I think we should define the processing
model for them in the HTML Standard as well, to ensure everyone can
align on when exactly these are supposed to match.


The original spec text for :user-invalid was pretty flexible in terms of 
when it can match. My understanding is that that was kind of intentional 
(cc'ing fantasai who was part of those discussions).


But yeah I tend to agree we probably want to define more precisely when 
these must match and maybe even when they may match.


 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to prototype and ship: :user-valid and :user-invalid pseudo-classes.

[Emilio Cobos Álvarez]

On 2/23/21 11:52, Xidorn Quan wrote:

Please head up in CSS working group about this, and probably ask for a 
resolution on no objection for us to ship it, as this spec is still in draft.


Hmm, is it? https://www.w3.org/TR/selectors-4/#user-pseudos has had 
:user-invalid for quite a while, and we and other engines ship a lot of 
stuff in selectors-4.


(I just added spec text for :user-valid, but it was noted in the 
non-draft spec that there was a resolution to add it as well).


Anyhow not particularly trying to avoid this, just trying to clarify the 
situation. A heads-up probably wouldn't hurt anyways, and per Anne's 
comments we might want some html spec text as well.


 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: make outlines follow border-radius automatically

[Emilio Cobos Álvarez]

The soft freeze is over, the change has been enabled for a few weeks on 
Nightly, and so far I've only seen progressions due to this change, so I 
think there's no reason to keep it Nightly-only.


I've filed bug 1694146 to turn the pref on everywhere, so lacking 
objections or regressions due to the original change it should ship in 
Firefox 88.


 -- Emilio

On 2/9/21 00:37, Emilio Cobos Álvarez wrote:

Summary:

Hi,

In bug 315209 I landed a patch to get outlines to follow the 
border-radius of the element automatically. It should be enabled in 
Nightly for now.


There's some (a lot) of context in the bug, but TLDR:

* Long-standing request.

* Safari does this for outline-style: auto, and we will too, with the 
new non-native theme, so it seems like being consistent would be worth it.


* We have -moz-outline-radius to control the outline radius, but authors 
don't use it, and that makes outlines look worse, generally. It is also 
not standard, so it'd be great to get rid of it eventually.


Pref: layout.css.outline-follows-border-radius.enabled

Standard: https://drafts.csswg.org/css-ui-4/#outline-color

The parts of the outline are not required to be rectangular. To the 
extent that the outline follows the border edge, it should follow the 
border-radius curve.


DevTools bug: N/A, I think.

Other browsers:

* Safari: Shipped (for auto-style outlines) since ~forever.
* Chromium: N/A, though they have an slightly rounded auto-style outline.

web-platform-tests: I can upstream a couple of the existing reftests 
that we had for outline-radius etc to WPT.


Cheers,

  -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to prototype and ship: :user-valid and :user-invalid pseudo-classes.

[Emilio Cobos Álvarez]

Hi,

In bug 1694141 I plan to unprefix :-moz-ui-valid and :-moz-ui-invalid 
pseudo-classes. These are useful pseudo-classes to determine when to 
show feedback to the user about a form control being invalid.


Standard: https://drafts.csswg.org/selectors/#user-pseudos

Platform coverage: all

Preference: None

Devtools bug: N/A

Other browsers: No signal from other vendors, though we've shipped this 
functionality for quite a while and the CSS working group considers it 
useful, see discussions:


 * https://lists.w3.org/Archives/Public/www-style/2012Aug/0749.html
 * https://lists.w3.org/Archives/Public/www-style/2015Sep/0111.html

I'm hoping that unprefixing it in Gecko will serve as a bit of a nag to 
other browsers.


Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1156069

WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=67

web-platform-tests: There's a test for :user-invalid in css/selectors. I 
plan to add a test for :user-valid. There's 
https://github.com/web-platform-tests/wpt/issues/9346 on file for adding 
WPTs that test the user-interaction part of this.


Let me know if you have any objections about this change, but I think 
having a prefixed pseudo-class for this is not a great state of affairs.


 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: :-moz-submit-invalid pseudo-class.

[Emilio Cobos Álvarez]

No other browser supports anything like this, and we don't even have 
internal uses of this pseudo-class.


Only uses of this I've found on the wild were just resetting the box 
shadow internal styling we added in bug 582277 (and since removed in bug 
600151).


I plan to put this behind a (default-off) pref in bug 1694129, but let 
me know if there's any objection to this.


Cheers,

 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: Non-standard values of caption-side property

[Emilio Cobos Álvarez]

Hi,

In bug 1688695 we've added a pref to unship the non-standard values of 
caption-side property:


  left | right | top-outside | bottom-outside

These values are not implemented by any other engine, and are not in any 
specification as of today.


There was some discussion on here as of 2016 about left | right, but it 
didn't gain traction:


  https://github.com/w3c/csswg-drafts/issues/497

If there is interest from other vendors to implement them, we could keep 
them, but otherwise having them around complicating our table layout 
code seems unfortunate.


Let me know if there's any objection or similar.

Cheers,

 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to prototype and ship: Make elements not traversable

[Emilio Cobos Álvarez]

(I forgot to send an intent for this a couple weeks ago)

Summary: This is a bit of a mess, see [1][2]. TLDR:

 * Gecko treated  elements like anchors, in the sense that if you 
display them, we allowed you to click around, etc. This meant also 
supporting :link / :visited on them, and such. We stopped supporting 
:visited on them a while back[3], because doing history queries for that 
and expose more attack surface for timing attacks seems just bad.


 * WebKit matched :link / :visited but didn't allow you to navigate 
using them. They stopped matching :visited around the same time as we 
did, too.


 * Blink at some point long time ago stopped matching :link / :visited 
on  elements.


This change aligns us with Blink (and the updated HTML spec).

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1687538

DevTools bug: N/A, I think

Other browsers: see above

Standard: https://github.com/whatwg/html/pull/6269

web-platform-tests: Landed with the html spec change.

[1]: https://github.com/w3c/csswg-drafts/issues/3817
[2]: https://github.com/whatwg/html/issues/4831
[3]: 
https://groups.google.com/d/msg/mozilla.dev.platform/1NP6oJzK6zg/uUq9bFLaAAAJ

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to prototype: make outlines follow border-radius automatically

[Emilio Cobos Álvarez]

Summary:

Hi,

In bug 315209 I landed a patch to get outlines to follow the 
border-radius of the element automatically. It should be enabled in 
Nightly for now.


There's some (a lot) of context in the bug, but TLDR:

 * Long-standing request.

 * Safari does this for outline-style: auto, and we will too, with the 
new non-native theme, so it seems like being consistent would be worth it.


 * We have -moz-outline-radius to control the outline radius, but 
authors don't use it, and that makes outlines look worse, generally. It 
is also not standard, so it'd be great to get rid of it eventually.


Pref: layout.css.outline-follows-border-radius.enabled

Standard: https://drafts.csswg.org/css-ui-4/#outline-color

> The parts of the outline are not required to be rectangular. To the 
extent that the outline follows the border edge, it should follow the 
border-radius curve.


DevTools bug: N/A, I think.

Other browsers:

 * Safari: Shipped (for auto-style outlines) since ~forever.
 * Chromium: N/A, though they have an slightly rounded auto-style outline.

web-platform-tests: I can upstream a couple of the existing reftests 
that we had for outline-radius etc to WPT.


Cheers,

  -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: Non-native theme turned on for Linux Nightlies

[Emilio Cobos Álvarez]

(+firefox-dev for visibility, but please reply to dev-platform),

Hey,

Just a PSA that the themed form controls on Linux Nightly are going to 
change soonish (when bug 1689359[1] is merged to central).


This is controlled by the widget.disable-native-theme-for-content pref. 
You can turn it on on other platforms if you want to test them too, the 
idea is that this will become the default for all platforms in the 
future, so testing and bug reports would be greatly appreciated!


It should fix some compat issues (GTK has usually huge default form 
controls) and will pave the way to remove unconditional X11 connections 
from content processes, which is a requirement for Fission.


The controls should be nicer / more consistent generally, but if you 
find something odd, or broken, please do reach out. You can file bugs 
against:


 * Bug 1411425 [2] for Linux-specific stuff (only scrollbars are 
Linux-specific).


 * Bug 1535761 [3] for OS-independent stuff.

Feel free to ni? me for improved turnaround times :-)

This is not just my work. Huge thanks to spohl, heycam and mstange, who 
did most of the work (my memory sucks, so sorry if I missed someone!).


Huge thanks to all the people that tested this early and filed bugs too 
(gcp / Itiel / evilpies / julienw come to mind as I'm writing this, but 
I'm sure I'm missing lots of others!).


Cheers,

 -- Emilio

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1689359
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1411425
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1535761
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: Unprefixed :autofill pseudo-class, :-webkit-autofill alias.

[Emilio Cobos Álvarez]

I filed bugs[1][2] on other engines, there's explicit support from 
Chromium on this[3], and the relevant spec[4] and WPT[5] changes are up 
for review, so as soon as they're merged I plan to turn the pref on on 
all platforms.


The bug for this is https://bugzilla.mozilla.org/show_bug.cgi?id=1685675

Let me know if there's any concerns with this. Florian in the CSSWG call 
raised a potential fingerprinting issue[6], but:


 * As discussed in that call that's a more general issue with 
autofilling. I think we never autofill without user interaction, too, 
which mitigates this.


 * It is already observable on Gecko via CSS (because we use the 
pseudo-class in the user-agent stylesheet, so you can query it by its 
effects like changing the computed values of color / filter).


Cheers,

 -- Emilio

[1]: https://bugs.chromium.org/p/chromium/issues/detail?id=1164311
[2]: https://bugs.webkit.org/show_bug.cgi?id=220459
[3]: https://github.com/whatwg/html/issues/6181#issuecomment-735665906
[4]: https://github.com/whatwg/html/pull/6273
[5]: https://github.com/web-platform-tests/wpt/pull/27098
[6]: https://github.com/w3c/csswg-drafts/issues/5775#issuecomment-755793947

On 12/10/20 3:20 AM, Emilio Cobos Álvarez wrote:

Summary:

I plan to prototype a standard :autofill pseudo-class, for two reasons

  * We have an internal :-moz-autofill pseudo-class, and webkit-based 
browsers have a publicly-exposed :-webkit-autofill counter-part.
  * We have a fair amount of compat reports of people forgetting 
:-webkit-autofill is not standard and making unrelated CSS not apply to 
Firefox.


Thus, I think it'd be nice to have an unprefixed pseudo-class authors 
can use, and parse the :-webkit- prefix (unfortunately) for compat.


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1475316

Standards: https://github.com/whatwg/html/issues/6181 and 
https://github.com/w3c/csswg-drafts/issues/5775 for the relevant spec 
discussion where I hope to get consensus.


Pref: layout.css.autofill.enabled.

Devtools Bug: I don't think devtools needs particular support. We could 
add an :autofill checkbox to the pseudo-classes submenu, please file and 
ni? me if you think it'd be useful.


Other browsers: Both WebKit and Blink ship for a long time prefixed 
(:-webkit-autofill)


web-platform-tests: I'll add parsing tests once the spec discussion is 
done. We can't do much more because actual autofill behavior is not 
particularly standard.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to prototype: CanvasRenderingContext2D.createConicGradient.

[Emilio Cobos Álvarez]

Sending this on behalf of the contributor that submitted the patch.

Summary: Implement a method analogous to createLinearGradient and 
createRadialGradient for canvas.


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1627014

Standard: https://github.com/whatwg/html/issues/5431

Platform coverage: All

Preference: canvas.createConicGradient.enabled

DevTools bug: N/A, I think

Other browsers:

 * Chromium: Implemented behind flag, pending some minor spec issues 
being sorted out I think.
 * WebKit: Supportive 
(https://github.com/whatwg/html/issues/5431#issuecomment-641097348)


web-platform-tests: 
html/canvas/element/fill-and-stroke-styles/2d.gradient.conic.html


 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to prototype: Standard :autofill pseudo-class, :-webkit-autofill alias.

[Emilio Cobos Álvarez]

Summary:

I plan to prototype a standard :autofill pseudo-class, for two reasons

 * We have an internal :-moz-autofill pseudo-class, and webkit-based 
browsers have a publicly-exposed :-webkit-autofill counter-part.
 * We have a fair amount of compat reports of people forgetting 
:-webkit-autofill is not standard and making unrelated CSS not apply to 
Firefox.


Thus, I think it'd be nice to have an unprefixed pseudo-class authors 
can use, and parse the :-webkit- prefix (unfortunately) for compat.


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1475316

Standards: https://github.com/whatwg/html/issues/6181 and 
https://github.com/w3c/csswg-drafts/issues/5775 for the relevant spec 
discussion where I hope to get consensus.


Pref: layout.css.autofill.enabled.

Devtools Bug: I don't think devtools needs particular support. We could 
add an :autofill checkbox to the pseudo-classes submenu, please file and 
ni? me if you think it'd be useful.


Other browsers: Both WebKit and Blink ship for a long time prefixed 
(:-webkit-autofill)


web-platform-tests: I'll add parsing tests once the spec discussion is 
done. We can't do much more because actual autofill behavior is not 
particularly standard.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Ship: :focus-visible pseudo-class

[Emilio Cobos Álvarez]

Summary: Implement the :focus-visible pseudo-class and effectively make 
:-moz-focusring an alias of it.


This is intended to simplify the way authors deal with outlines to 
improve accessibility. In particular, authors seem to hate outlines when 
users focus stuff with the mouse, generally and so a lot of them do 
:focus { outline: none }, which renders elements also inaccessible by 
keyboard.


We have always exposed :-moz-focusring to represent Gecko's opinion on 
whether something ought to have an outline, but that also didn't quite 
have the desired effect (plus it required Firefox-specific selectors).


:focus-visible is supposed to be the standard version of :-moz-focusring 
with a behavior that matches more author's expectations (but that users 
can also customize).


To summarize current and upcoming behavior:

The behavior we're shipping depends on the platform, but for Windows is:

 * If browser.display.show_focus_rings (default false), or a 
Windows-specific setting (also default off) to always show outlines is 
enabled, then all focused elements match :-moz-focusring.


 * Otherwise (the default behavior) it matches all focused elements 
only after the user has navigated once with the keyboard once in a given 
tab.


If enabling this goes well (it's been enabled for a long while on 
Nightly, with no known regressions, and it's early in the cycle so we 
still have a bunch of time to fix issues if they arise) this will be the 
new behavior (which is the current on Nightly):


 * The first bullet point remains the same (with :focus-visible rather 
than :-moz-focusring).


 * , contenteditable, and  elements that require 
keyboard input or such always match :focus-visible if focused.


 * For other elements, we follow the rules described in the spec (link 
below), which are roughly that focus-visible matches for keyboard focus 
but not mouse focus, and that whether programmatic focus matches depends 
on whether the previously-focused element matched it.


 * Additionally, if browser.display.always_show_rings_after_key_focus 
is true (default false), then we keep the existing behavior of matching 
all elements once keyboard navigation has occurred.


This should hopefully make developers happy and less prone to remove all 
outlines on focus.


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1445482

Standard: https://drafts.csswg.org/selectors-4/#the-focus-visible-pseudo

Platform coverage: All

Preference: layout.css.focus-visible.enabled

DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1617608

Other browsers:

 * Chrome: Shipped (M86)
 * WebKit: N/A (https://bugs.webkit.org/show_bug.cgi?id=185859)

web-platform-tests: 
https://wpt.fyi/results/css/selectors?label=master=experimental=focus-visible


Cheers,

 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Ship: Make wheel event listeners passive by default on the root

[Emilio Cobos Álvarez]

On 10/28/20 11:18 AM, Anne van Kesteren wrote:

On Mon, Oct 26, 2020 at 5:45 PM Emilio Cobos Álvarez  wrote:

Standard: None, this is an intervention, though
https://w3c.github.io/uievents/#cancelability-of-wheel-events is loosely
related.

I'm not sure "it's an intervention" is sufficient reason as making
breaking changes to the web platform is not great for web developers,
but the fact that both Chrome and Safari already do this is, somewhat.
There is https://github.com/whatwg/dom/pull/366 which hasn't been
looked at since there only was one interested implementer. You should
probably take a look at that if that roughly matches part of the
changes you had to make. (Not sure who should own the "default passive
algorithm" for the root element though, HTML?)


Given Safari and us have been shipping the similar touch event 
intervention for a long while it seems we should really merge that.


The IDL changes match the relevant gecko commit for that one:

https://hg.mozilla.org/mozilla-central/rev/99e592730f87f014a4d541ad301e27226d9e1cca 
<https://hg.mozilla.org/mozilla-central/rev/99e592730f87f014a4d541ad301e27226d9e1cca>


Regarding to who should own the default algorithm probably HTML? Or 
UI-events.


 -- Emilio

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Ship: Make wheel event listeners passive by default on the root

[Emilio Cobos Álvarez]

Summary: Make wheel / DOMMouseScroll / MozMousePixelScroll event 
listeners on the root passive by default.


This effectively aligns with Chromium (see [1]), and with touchstart / 
touchmove events.


Bug: 1673278

Standard: None, this is an intervention, though 
https://w3c.github.io/uievents/#cancelability-of-wheel-events is loosely 
related.


https://github.com/WICG/interventions/issues/64 is the main discussion.

Platform coverage: all

Preference: dom.event.default_to_passive_wheel_listeners

DevTools bug: N/A

Other browsers: Chromium-based browsers ship this since basically 
forever. WebKit doesn't implement this, but it does implement a similar 
quirk for touch events (as above), and I think implementing this would 
allow them to get rid of a nasty hack in their events code too[2] 
(interestingly chromium still keeps their smoothscroll.js intervention, 
though I think it's just dead code at this point, I filed [3] for that).


web-platform-tests: This is not tested by WPT, as it's an intervention. 
If WebKit decides to implement we should probably put this in a spec and 
move tests there.


Cheers,

 -- Emilio

[1]: 
https://developers.google.com/web/updates/2019/02/scrolling-intervention

[2]: https://bugs.webkit.org/show_bug.cgi?id=207040
[3]: https://bugs.chromium.org/p/chromium/issues/detail?id=1142482
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Implement :-moz-any() as an alias of :is()

[Emilio Cobos Álvarez]

On 9/21/20 3:46 PM, Tom Ritter wrote:

I imagine there's a good reason; but I'm curious: why do we want to
keep this legacy, prefixed pseudo-class and not just use is()?


Removing it is generally much more risky than aliasing to something that 
is more permissive. This is specially true when accounting for 
add-ons/userChrome.css users, but even without accounting for those, I 
suspect :-moz-any can be used in the wild much like @-moz-document to 
write Firefox-only CSS, which is a compat thing that we need to live with.


That being said, I could certainly look into it as a follow-up. Once 
:-moz-any usage is removed from the codebase (there's a patch under 
review) I can add a use counter and see how often it's hit on content, 
to consider removing it eventually if feasible.


 -- Emilio


-tom

On Sat, Sep 19, 2020 at 3:36 PM Emilio Cobos Álvarez  wrote:


Summary: Implement the legacy :-moz-any selector as an alias of :is().

This means that it'll be more powerful, and also simpler to maintain for us.

This has been enabled in 81 beta/nightly and for the whole 82 cycle with
no regriessions so far, see bug 561154.

This means that it will accept more selectors (like :is() does), which I
don't expect to be problematic.

It also means that specificity may change in some cases, because the
specificity of :-moz-any doesn't account for the inner selectors. This
was a long-standing issue that this change fixes (bug 561154), but that
can technically change behavior (thus the pref, and having it enabled on
Nightly / Early beta for a while).

This last bit is pretty hard to use-count, because the specificity
change in most cases won't end up resulting in an actual behavior
change. I expect this to not be problematic either, because of the
limited usage that this prefixed pseudo-class has, and because behavior
is closer to what authors expect. As a data point, this change required
no changes to the browser UI at all, which extensively used the
:-moz-any() pseudo-class.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1666086

Standard: N/A, this is a legacy, prefixed pseudo-class, which we'll
build on top of the standard alternative that we've shipped for a while.

Platform coverage: All

Preference: layout.css.moz-any-is-is.enabled

DevTools bug: N/A, devtools will work the same as they work with :is().

Other browsers: N/A, this is a -moz- prefixed pseudo-class.

web-platform-tests: There are tons of tests for :is(), but I don't plan
to test the :-moz- prefixed pseudo-class in WPT.

Cheers,

   -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: Implement :-moz-any() as an alias of :is()

[Emilio Cobos Álvarez]

Summary: Implement the legacy :-moz-any selector as an alias of :is().

This means that it'll be more powerful, and also simpler to maintain for us.

This has been enabled in 81 beta/nightly and for the whole 82 cycle with 
no regriessions so far, see bug 561154.


This means that it will accept more selectors (like :is() does), which I 
don't expect to be problematic.


It also means that specificity may change in some cases, because the 
specificity of :-moz-any doesn't account for the inner selectors. This 
was a long-standing issue that this change fixes (bug 561154), but that 
can technically change behavior (thus the pref, and having it enabled on 
Nightly / Early beta for a while).


This last bit is pretty hard to use-count, because the specificity 
change in most cases won't end up resulting in an actual behavior 
change. I expect this to not be problematic either, because of the 
limited usage that this prefixed pseudo-class has, and because behavior 
is closer to what authors expect. As a data point, this change required 
no changes to the browser UI at all, which extensively used the 
:-moz-any() pseudo-class.


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1666086

Standard: N/A, this is a legacy, prefixed pseudo-class, which we'll 
build on top of the standard alternative that we've shipped for a while.


Platform coverage: All

Preference: layout.css.moz-any-is-is.enabled

DevTools bug: N/A, devtools will work the same as they work with :is().

Other browsers: N/A, this is a -moz- prefixed pseudo-class.

web-platform-tests: There are tons of tests for :is(), but I don't plan 
to test the :-moz- prefixed pseudo-class in WPT.


Cheers,

 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to prototype: Allow :is() and :where() to have better selector error recovery.

[Emilio Cobos Álvarez]

Summary: Allow invalid selectors inside :is() and :where() to be 
ignored, rather than making the whole selector list invalid.


This would allow to have some sort of escape hatch for the usual footgun 
of "one invalid selector in the list makes the whole style rule 
invalid", which is generally considered a mistake 
.


This is technically a breaking change, see below for the position of 
other engines on this (though these pseudo-classes are relatively 
recent, and we're being more permissive). The intention is to enable the 
pref on Nightly and Early Beta for now. You'll hear from me when 
enabling it everywhere :)


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1664718 



Standard: This implements the resolution for csswg-drafts#3264 
. The spec is yet to be 
edited to reflect it.


Platform coverage: All

Preference: layout.css.is-and-where-better-error-recovery.enabled

DevTools bug: I'm not sure if it is necessary to have a devtools bug for 
this. The selector will serialize as :is(div) rather than :is(div, 
:nonsense), for example. Other than that, devtools should just work. If 
folks feel strongly otherwise, please file a bug and cc me on it and 
I'll take a look, maybe some more work could be done to surface this 
better in DevTools, though it wouldn't be trivial right now to expose it 
via the regular CSS parse error reporting mechanism (because parsing 
will, in fact, succeed).


Other browsers: Both Blink and Apple engineers have expressed support 
for this. Blink still doesn't implement these selectors, Apple engineers 
said on the call that they'd follow Gecko if we make the change.


web-platform-tests: Tests for this are added in the bug.

 -- Emilio

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Ship: ::file-selector-button pseudo-element

[Emilio Cobos Álvarez]

See the original intent to implement for ::file-chooser-button here:


https://groups.google.com/g/mozilla.dev.platform/c/70ODk1Gqrzs/m/CBLgePEkAAAJ

I plan to rename it and enable it by default for Firefox 82 (it's 
enabled in Nightly / Beta only right now) as per the resolution in:


  https://github.com/w3c/csswg-drafts/issues/5049

Let me know if there's any concern with this.

Thank you,

  -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: ::-moz-focus-outer pseudo-element.

[Emilio Cobos Álvarez]

Hi,

In bug 1655859, I intend to disable parsing for ::-moz-focus-outer on 
all channels.


This pseudo-element used to be an  specific 
pseudo-element to show some focus outlines, but it does literally 
nothing anymore (other than being parsed), after the changes in bug 
1636998. As part of making it do nothing, I made it not parse on 
Nightly, two releases ago, and we've had no reported regression. All 
uses that I've been able to find involve a single selector, so there 
should be no behavior change in that regard.


Let me know if there's any concern with doing this. This is behind a 
pref (layout.css.moz-focus-outer.enabled), so we could revert if need be.


Cheers,

 -- Emilio

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New Bugzilla component for keeping comm-central in sync with mozilla-central

[Emilio Cobos Álvarez]

On 7/7/20 4:11 PM, Tom Ritter wrote:

Hey Geoff - what sorts of things would be appropriate to file there?
Or perhaps as a more basic question - what *is* comm-central? Is it
'mozilla-central with constantly-rebased Thunderbird patches on top?'
Is it an old fork of mozilla-central where a lot (or very few) patches
are copied across? Some hybrid? I like Thunderbird, and I'd like to
make things easier on you, but truthfully I know very little about how
Thunderbird is made relative to my work on Firefox (and I couldn't
find a document online).


comm-central is a separate repo from mozilla-central. You need both 
comm-central and mozilla-central to build thunderbird, and comm-central 
depends on stuff (headers / interfaces / etc) from mozilla-central.


A common case of mozilla-central changes breaking comm-central is stuff 
like removing interfaces. There may be some interfaces that 
mozilla-central has no uses of, but comm-central still uses. Removing 
that kind of stuff without checking comm-central (which is pretty easy 
with searchfox) and without pinging the Thunderbird folks causes 
unnecessary churn for them.


Usually removing the remaining usages from comm-central is easy and 
folks like Geoff or others act pretty fast on that stuff (thank you!).


Otherwise you may need to keep some of the code in mozilla-central or 
what not.


 -- Emilio


-tom


On Tue, Jul 7, 2020 at 3:45 AM Geoff Lankow  wrote:


Hi everybody

Many changes to mozilla-central code require complementary changes to
comm-central code. Communication about this hasn't always been
effective, which leads to breakages that could have been prevented, and
wasted developer time.

We now have a dedicated Bugzilla component for alerting Thunderbird's
developers about such things: Thunderbird - Upstream Synchronization.
Please use it to keep us informed of impending changes that we'll need
to deal with.

Thank you to those who do keep us informed. I hope having a dedicated
component makes your life easier as well as ours.

GL
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal: remove support for running desktop Firefox in single-process mode (e10s disabled) anywhere but in tests

[Emilio Cobos Álvarez]

What is the situation of Thunderbird? I think they don't have e10s enabled
yet, and it may be worth at least knowing what their plans are.

 -- Emilio

On Wed, Jun 10, 2020, 8:44 PM Dave Townsend  wrote:

> Non-e10s is such a different environment that I don't think we have any
> hope of keeping it working without running the full test suite in that mode
> and I don't think anyone wants to do that. Now that this has started
> breaking I think it is actively harmful to our users for us to allow them
> to disable e10s.
>
> On Wed, Jun 10, 2020 at 11:30 AM Gijs Kruitbosch  >
> wrote:
>
> > (Copied to fx-dev; Replies to dev-platform please.)
> >
> > Hello,
> >
> > Just over a year ago, I started a discussion[0] about our support for
> > disabling e10s. The outcome of that was that we removed support for
> > disabling e10s with a pref on Desktop Firefox with version 68, except
> > for use from automation. We kept support for using the environment
> > variable. [1]
> >
> > Last week, we released Firefox 77, which turned out to break all
> > webpages sent using compression (like gzip) if you had disabled e10s
> > using this environment variable. [2]
> >
> > So here we are again. I'd like to propose we also stop honouring the
> > environment variable unless we're running tests in automation. We
> > clearly do not have sufficient test coverage to guarantee basic things
> > like "the browser works", it lacks security sandboxing, and a number of
> > other projects require it (fission, gpu process, socket process, ...),
> > so I think it's time to stop supporting this configuration at all.
> >
> > I hope to make this change for the 79 cycle. I'm open to arguments
> > either way about what to do for 78 esr (assuming the patch for 79 turns
> > out to be simple; the work to remove the pref had a number of annoying
> > corner-cases at the time).
> >
> > Please speak up if you think that this plan needs adjusting.
> >
> > ~ Gijs
> >
> >
> > [0]
> >
> >
> https://groups.google.com/d/msg/mozilla.dev.platform/cJMzxi7_PmI/Pi1IOg_wCQAJ
> > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1548941
> > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1638652
> > ___
> > firefox-dev mailing list
> > firefox-...@mozilla.org
> > https://mail.mozilla.org/listinfo/firefox-dev
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: prefers-color-scheme:no-preference value.

[Emilio Cobos Álvarez]

Following this CSS resolution[1], I intend to remove the no-preference 
value for the prefers-color-scheme media query in bug 1643656[2].


For context, this value never matches in any browser (unless the user 
overrides a hidden pref), and was relatively recently introduced, so the 
idea is that it should be pretty safe to remove.


In any case, I've added a pref just in case we need to back out the 
behavior change: layout.css.prefers-color-scheme-no-preference.enabled, 
which will default to false.


Blink already sent out a similar already-approved intent email[3], and 
WebKit already has a bug on file[4], plus they supported the change in 
previous discussions, see the minutes in the spec issue.


Let me know if there's any concern with this.

Thanks,

 -- Emilio

[1]: https://github.com/w3c/csswg-drafts/issues/3857#issuecomment-634779976
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1643656
[3]: 
https://groups.google.com/a/chromium.org/d/msg/blink-dev/ragu5Is6vCw/bsrP_5O6BAAJ

[4]: https://bugs.webkit.org/show_bug.cgi?id=212952
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to prototype: ::file-chooser-button

[Emilio Cobos Álvarez]

*Summary:* Add a pseudo-element to file inputs in order to expose the 
internal "Browse" button.


Since there's no spec yet, and the name might change, I plan to /not/ 
ship it just yet, and keep it Nightly / Dev Edition only for now until 
the dust settles.


*Bug:* bug 1635675 .

*Standard:* None yet, this was just resolved 
 by the CSS Working Group.


*Platform coverage:* All platforms.

*Preference:* layout.css.file-chooser-button.enabled

*Devtools Bug:* N/A

*Other Browsers:*

 * WebKit and Blink ship a prefixed version of this called
   ::-webkit-file-upload-button.
 * EdgeHTML shipped a prefixed version of this called ::-ms-browse.

*web-platform-tests:* I'm adding some very basic tentative tests in the 
patch.


*Secure contexts:* Not restricted to secure contexts as many other CSS 
selectors.


*Is this feature enabled by default in sandboxed iframes?* Yes

  -- Emilio

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Cargo.lock in hg repository?

[Emilio Cobos Álvarez]

On 5/19/20 3:11 AM, ISHIKAWA,chiaki wrote:
Thank you for the feedback. So I am not alone in seeing this. I will 
ignore the anomaly for now although there are a few strange local 
changes due to this now.


You shouldn't see it anymore if you rebase:

  https://hg.mozilla.org/mozilla-central/rev/6db4b71d0c20

 -- Emilio



Chiaki

On 2020/05/18 1:08, Emilio Cobos Álvarez wrote:
I see this too, I think it's a rebase messup between bug 1631630 and 
bug 1636068.


 -- Emilio

On 5/17/20 2:44 PM, ISHIKAWA,chiaki wrote:

I am developing TB patches locally on my linux PC.

Have anyone noticed mozilla/Cargo.lock seems to be in mercurial 
repository and that it got updated

during development?
That is, as far as *I* am concerned, I never tough it directly.
But, it seems |mach clobber|, |mach configure|, |mach build| and 
other |mach| invocations and the subsequent commands invoked within 
during configure and compilation/build seemed to
change the file, mozilla/Cargo.lock. And during local hg update 
(applying my patches, etc.), hg commands suddenly states

that there is a local diff and refresh my repository before proceeding.
Surprised, I check what changed. The changed file is Cargo.lock.
This happened twice over the weekend.
(I updated the source tree from the M-C and C-C repository a few 
times. Each time the update worked OK. Only after a compilation and I 
tried to apply my local patch, this happened. My using hg MQUEE 
feature should not be a problem, though...)


The changes I noticed seem to be just the relocations of version 
information of some tools/packages in different part of Cargo.lock.

(Simple deletion/addition of same block in different parts of the file.)

This is so strange, and I wonder if there is something wrong with my 
setup.


I thought this is the first time it happened on my PC, but a close 
check of local patches revealed
something like this happened last August (Aug. 2019). Back then, I 
was trying very hard to accommodate the source tree layout change 
(C-C now having become the subtree of ./mozilla as mozilla/comm, and 
there were many local patches and locally crafted scripts  I needed 
to update and it seems that I simply accepted Cargo.lock change as 
part of the big tree layout and never bothered about it until today.)


Again, has anyone seen Cargo.lock being modified without direct user 
intervention on their PC?


TIA


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Cargo.lock in hg repository?

[Emilio Cobos Álvarez]

I see this too, I think it's a rebase messup between bug 1631630 and bug 
1636068.


 -- Emilio

On 5/17/20 2:44 PM, ISHIKAWA,chiaki wrote:

I am developing TB patches locally on my linux PC.

Have anyone noticed mozilla/Cargo.lock seems to be in mercurial 
repository and that it got updated

during development?
That is, as far as *I* am concerned, I never tough it directly.
But, it seems |mach clobber|, |mach configure|, |mach build| and other 
|mach| invocations and the subsequent commands invoked within during 
configure and compilation/build seemed to
change the file, mozilla/Cargo.lock. And during local hg update 
(applying my patches, etc.), hg commands suddenly states

that there is a local diff and refresh my repository before proceeding.
Surprised, I check what changed. The changed file is Cargo.lock.
This happened twice over the weekend.
(I updated the source tree from the M-C and C-C repository a few 
times. Each time the update worked OK. Only after a compilation and I 
tried to apply my local patch, this happened. My using hg MQUEE 
feature should not be a problem, though...)


The changes I noticed seem to be just the relocations of version 
information of some tools/packages in different part of Cargo.lock.

(Simple deletion/addition of same block in different parts of the file.)

This is so strange, and I wonder if there is something wrong with my 
setup.


I thought this is the first time it happened on my PC, but a close 
check of local patches revealed
something like this happened last August (Aug. 2019). Back then, I was 
trying very hard to accommodate the source tree layout change (C-C now 
having become the subtree of ./mozilla as mozilla/comm, and there were 
many local patches and locally crafted scripts  I needed to update and 
it seems that I simply accepted Cargo.lock change as part of the big 
tree layout and never bothered about it until today.)


Again, has anyone seen Cargo.lock being modified without direct user 
intervention on their PC?


TIA


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: :read-only / :read-write pseudo-classes

[Emilio Cobos Álvarez]

A clarification given this came up in chat.mozilla.org:

I'm keeping the support for parsing the old prefixed versions for 
backwards compat, aliased to the un-prefixed ones. We can potentially 
remove them, but probably at another time, specially given we're trying 
to minimize deprecations / breaking changes.


 -- Emilio

On 5/14/20 2:19 AM, Emilio Cobos Álvarez wrote:


*Summary: *Make our :-moz-read-only / :-moz-read-write pseudo-classes 
match the spec, and un-prefix them.


*Bug: *Bug 312971 <https://bugzil.la/312971>

*Standard: *https://html.spec.whatwg.org/#selector-read-only 
<https://html.spec.whatwg.org/#selector-read-only>


*Platform coverage: *All

*Preference: *None. We've shipped the prefixed version of this 
pseudo-class since forever.


*DevTools bug: *N/A

*Other browsers:* All other browsers ship it since a long time ago 
according to caniuse <https://caniuse.com/#feat=css-read-only-write>. 
Safari matches the spec. Chromium deviates from it 
<https://bugs.chromium.org/p/chromium/issues/detail?id=255351>.


*web-platform-tests: *There are some rather broken tests and some 
tests for dynamic changes. I'm fixing the tests to match the spec as 
part of this work.


*Secure contexts: *This will not be restricted to secure contexts, 
like many other CSS features. We ship the prefixed pseudo-class to 
non-secure contexts, and other browsers ship the unprefixed version to 
them as well.


*Is this feature enabled by default in sandboxed iframes? *Yes, like 
many other CSS features.


 -- Emilio


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: :read-only / :read-write pseudo-classes

[Emilio Cobos Álvarez]

*Summary: *Make our :-moz-read-only / :-moz-read-write pseudo-classes 
match the spec, and un-prefix them.


*Bug: *Bug 312971 

*Standard: *https://html.spec.whatwg.org/#selector-read-only 
//


*Platform coverage: *All

*Preference: *None. We've shipped the prefixed version of this 
pseudo-class since forever.


*DevTools bug: *N/A

*Other browsers:* All other browsers ship it since a long time ago 
according to caniuse . 
Safari matches the spec. Chromium deviates from it 
.


*web-platform-tests: *There are some rather broken tests and some tests 
for dynamic changes. I'm fixing the tests to match the spec as part of 
this work.


*Secure contexts: *This will not be restricted to secure contexts, like 
many other CSS features. We ship the prefixed pseudo-class to non-secure 
contexts, and other browsers ship the unprefixed version to them as well.


*Is this feature enabled by default in sandboxed iframes? *Yes, like 
many other CSS features.


 -- Emilio

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to prototype and ship: CSS :is() and :where() pseudo-classes.

[Emilio Cobos Álvarez]

On 4/18/20 1:49 AM, Emilio Cobos Álvarez wrote:
  * Safari: Implemented in TP. They have shipped since forever an 
outdated version of the spec (:matches instead of :is).


Clarification: It seems WebKit only supports :is(), not :where().

 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to prototype and ship: CSS :is() and :where() pseudo-classes.

[Emilio Cobos Álvarez]

Someone nerd-sniped me this week, sorry :)

Summary: Implements the :is() and :where() pseudo-classes from the CSS 
selectors level 4 spec. These allow to adjust the specificity of 
selectors and write selectors that weren't possible before.


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1509418

Standard:

 * https://drafts.csswg.org/selectors/#matches
 * https://drafts.csswg.org/selectors/#zero-matches

Platform coverage: All

Preference: layout.css.is-where-selectors.enabled

Devtools bug: N/A: Devtools doesn't have autocomplete or such features 
for selectors, and I think everything else should work out of the box. 
But let me know if you disagree.


Some better tools to visualize specificity or such would be great, but a 
bit unrelated to this.


Other browsers:

 * Safari: Implemented in TP. They have shipped since forever an 
outdated version of the spec (:matches instead of :is).


 * Chrome: They had a bogus implementation that never shipped.

web-platform-tests:

  There are a few in https://wpt.fyi/results/css/selectors and in the 
invalidation subdirectory, which is great because invalidation of these 
is tricky. But there are a few other tests missing which I want to add 
before enabling the pref in all channels.


Secure contexts: Like all other CSS selectors these are not restricted 
to secure contexts.


Is this feature enabled by default in sandboxed iframes?: Yes

 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Editor / IDE integration docs

[Emilio Cobos Álvarez]

So, Ting-Yu pointed me to [1], which I didn't find because I had the 
great idea of searching from within MDN, and those pages apparently 
don't show up in results at all[2] :/.


That also has a bunch of extra resources linked in like [3] and [4].

So I'll try to see what's relevant and what's not, and move most of that 
to the in-tree docs, assuming that there are no objections :)


 -- Emilio

[1]: 
https://developer.mozilla.org/en-US/docs/Developer_Guide/Editor_Configuration

[2]: https://developer.mozilla.org/en-US/search?q=editor+configuration
[3]: https://wiki.mozilla.org/DevTools/CodingStandards
[4]: https://wiki.mozilla.org/WebExtensions/Hacking#Vim

On 4/13/20 11:52 PM, Emilio Cobos Álvarez wrote:

Hey,

A semi-frequent question in #developers or #introduction is to ask about 
which IDE or editor people use, or how to get X working on Y editor, 
etc. I've sent a patch to document what I know to:


   https://bugzilla.mozilla.org/show_bug.cgi?id=1629445

Which is already on autoland. But I arguably don't know all that much, 
as my setup is fairly simple, just vim and ycm :)


If your favorite editor tweaks and such aren't listed there and you have 
some time to document them to help newcomers and lazy oldcomers[1] 
alike, please take a moment to document them in that page!


Thank you!

  -- Emilio

[1]: for example, I'd be curious to know if there's an easy way to show 
the clang-tidy / eslint diagnostics that Phabricator always shouts about 
inline in my editor :)

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Editor / IDE integration docs

[Emilio Cobos Álvarez]

Hey,

A semi-frequent question in #developers or #introduction is to ask about 
which IDE or editor people use, or how to get X working on Y editor, 
etc. I've sent a patch to document what I know to:


  https://bugzilla.mozilla.org/show_bug.cgi?id=1629445

Which is already on autoland. But I arguably don't know all that much, 
as my setup is fairly simple, just vim and ycm :)


If your favorite editor tweaks and such aren't listed there and you have 
some time to document them to help newcomers and lazy oldcomers[1] 
alike, please take a moment to document them in that page!


Thank you!

 -- Emilio

[1]: for example, I'd be curious to know if there's an easy way to show 
the clang-tidy / eslint diagnostics that Phabricator always shouts about 
inline in my editor :)

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Ignore navigation to unknown protocol

[Emilio Cobos Álvarez]

On 3/30/20 8:02 PM, Bobby Holley wrote:

Reading the post a few times, I'm still unclear on a few things, so would
appreciate clarification. Here's what I understand from the post:

On the user's machine, there is some entropy, i.e. the set of schemes for
which an external protocol handler is registered. This entropy is currently
retrievable via various mechanisms. For webcompat reasons, we want to make
a change to one of those mechanisms, but the entropy will remain accessible
after this change.

What's less clear to me is how the proposed change impacts the entropy
exposure by the mechanism it targets. It seems to me that using about:blank
for both the handled and unhandled case would not expose this entropy, but
the post implies otherwise.

In other words: does this change put us on a path to eventually making this
entropy non-observable, or would we need to undo this change if/when we
pursue that?


Yeah, you're right. I was not clear about this when I wrote the original 
email, but this patch makes things slightly better. It makes the known / 
unknown-ness of the protocol not observable in the navigation case.


That being said there are still a bunch of ways to get that information.

I just filed bug 1626068 to potentially try to minimize this.

 -- Emilio


Thanks!




On Sun, Mar 29, 2020 at 12:29 AM Emilio Cobos Álvarez 
wrote:


On 3/29/20 9:11 AM, Emilio Cobos Álvarez wrote:

Doing a bit of digging,
https://bugzilla.mozilla.org/show_bug.cgi?id=680300 contains some more
interesting context...

We apparently used to sync-throw when assigning location.href to an
unknown protocol URI in the past, there we changed it to silently fail,
and now it is navigating to an error page...

I'll try to look at when behavior changed around here... Though the
sync-throwing clearly makes no sense as it doesn't account for redirects
or what not.


Apparently the pre-firefox63 behavior was to both navigate and throw...

So not all that much to dig in, that was just obviously wrong, but
didn't address the fingerprinting angle other than patching one of the
holes.


On 3/29/20 8:23 AM, Emilio Cobos Álvarez wrote:

Hey, a quick web-observable change that may deserve a bit more
visibility / an intent.

I'd welcome some feedback, specially from the fingerprinting / privacy
angle (where I'm clearly not an expert).

Summary: A page redirecting / navigating to an unknown protocol will
be silently ignored (and logged to the DevTools console) instead of
showing an error page. This is not amazing, but it's needed because it
causes a bunch of compat issues (see the list of issues in the bug
below).

There are a few subtle problems here. Part of the issue is that
authors don't have a cross-browser way of detecting whether a protocol
will be handled externally (that is, whether an app is installed to
handle a given protocol).

They technically can in Firefox (see example below). It's unclear
whether we want to expose more than that, or that at all.

Given Chrome just ignores the navigation if they can't handle it, some
authors (who don't seem to test on other browsers ;)) just spam the
redirect (using various methods like the location href setter / meta
refresh / whatevs). This works just fine in Chromium-based browsers,
but not in Firefox or Safari, which will just show an error, which
causes a very frustrating experience for users.

As far as I know, this behavior doesn't really expose more information
than we were exposing before. In a test-case like:




we have different behavior also before this patch: the contentDocument
for the handled-protocol iframe will be accessible to content, and be
about:blank. The contentDocument for the unhandled protocol will be
the error page, which will not be accessible to content and thus be

null.


Other browsers seem to do about:blank for both iframes, but you can
also detect this in all browsers via window.open instead (there may be
other ways around it too, haven't dug all that much). Chrome
insta-closes the handled protocol window (so you can check
window.closed). Firefox / Safari will leave about:blank in that
window, and show an error document for the second (which will throw a
security error on access).

So I don't think this change introduces a new privacy hole. That being
said, this all seems a bit sad, and a somewhat-serious potential
fingerprinting factor. I was in fact a bit nervous about this change
before realizing we were already exposing this information in other
(even simpler to test) ways... But I'm clearly not an expert on this
matter.

There are mitigations possible both for the ignored-navigation case
(maybe only ignore the navigation to an unknown protocol once per
document or something, and only for browsing contexts that can't be
accessed by any ancestor JS? not sure) and the iframe case (probably
just not show error pages in frames?). Please let me know if I you
think I should file this and follow-up on it.

Bug: https://bugzilla.mozilla.org/show_bug.cgi

Re: Intent to implement and ship: Ignore navigation to unknown protocol

[Emilio Cobos Álvarez]

On 3/29/20 9:11 AM, Emilio Cobos Álvarez wrote:
Doing a bit of digging, 
https://bugzilla.mozilla.org/show_bug.cgi?id=680300 contains some more 
interesting context...


We apparently used to sync-throw when assigning location.href to an 
unknown protocol URI in the past, there we changed it to silently fail, 
and now it is navigating to an error page...


I'll try to look at when behavior changed around here... Though the 
sync-throwing clearly makes no sense as it doesn't account for redirects 
or what not.


Apparently the pre-firefox63 behavior was to both navigate and throw...

So not all that much to dig in, that was just obviously wrong, but 
didn't address the fingerprinting angle other than patching one of the 
holes.



On 3/29/20 8:23 AM, Emilio Cobos Álvarez wrote:
Hey, a quick web-observable change that may deserve a bit more 
visibility / an intent.


I'd welcome some feedback, specially from the fingerprinting / privacy 
angle (where I'm clearly not an expert).


Summary: A page redirecting / navigating to an unknown protocol will 
be silently ignored (and logged to the DevTools console) instead of 
showing an error page. This is not amazing, but it's needed because it 
causes a bunch of compat issues (see the list of issues in the bug 
below).


There are a few subtle problems here. Part of the issue is that 
authors don't have a cross-browser way of detecting whether a protocol 
will be handled externally (that is, whether an app is installed to 
handle a given protocol).


They technically can in Firefox (see example below). It's unclear 
whether we want to expose more than that, or that at all.


Given Chrome just ignores the navigation if they can't handle it, some 
authors (who don't seem to test on other browsers ;)) just spam the 
redirect (using various methods like the location href setter / meta 
refresh / whatevs). This works just fine in Chromium-based browsers, 
but not in Firefox or Safari, which will just show an error, which 
causes a very frustrating experience for users.


As far as I know, this behavior doesn't really expose more information 
than we were exposing before. In a test-case like:


   
   

we have different behavior also before this patch: the contentDocument 
for the handled-protocol iframe will be accessible to content, and be 
about:blank. The contentDocument for the unhandled protocol will be 
the error page, which will not be accessible to content and thus be null.


Other browsers seem to do about:blank for both iframes, but you can 
also detect this in all browsers via window.open instead (there may be 
other ways around it too, haven't dug all that much). Chrome 
insta-closes the handled protocol window (so you can check 
window.closed). Firefox / Safari will leave about:blank in that 
window, and show an error document for the second (which will throw a 
security error on access).


So I don't think this change introduces a new privacy hole. That being 
said, this all seems a bit sad, and a somewhat-serious potential 
fingerprinting factor. I was in fact a bit nervous about this change 
before realizing we were already exposing this information in other 
(even simpler to test) ways... But I'm clearly not an expert on this 
matter.


There are mitigations possible both for the ignored-navigation case 
(maybe only ignore the navigation to an unknown protocol once per 
document or something, and only for browsing contexts that can't be 
accessed by any ancestor JS? not sure) and the iframe case (probably 
just not show error pages in frames?). Please let me know if I you 
think I should file this and follow-up on it.


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1528305

Standard: https://html.spec.whatwg.org/#process-a-navigate-url-scheme 
allows for both the old and new behavior, as far as I (and Anne) can 
tell. This uses urls after redirect and so on so beforeunload and such 
will fire. This matches the behavior of Chromium browsers.


Preference: dom.no_unknown_protocol_error.enabled (I could've sweated 
it a bit more).


Devtools bug: N/A, ignored navigations get logged to the console.

Other browsers: Chromium browsers do this, but WebKit doesn't seem to. 
This was causing compat issues, specially on Android, but also desktop 
(see above).


web-platform-tests: Spec allows both behaviors, so I've added an 
internal test for now. Furthermore it's not clear if we want to do 
this for sub-windows, which my patch does, so I may need to tweak the 
test or add an internal switch depending on the outcome of the 
discussion here.


Secure contexts: not restricted to secure contexts, this is a compat 
hack, of sorts...


Is this feature enabled by default in sandboxed iframes? Not sure if 
the question quite applies to this, but we don't special-case 
sandboxed iframes here. This doesn't expose anything you couldn't do 
before, as discussed above.


Thanks for reading all the way until here

  -- Emilio

Re: Intent to implement and ship: Ignore navigation to unknown protocol

[Emilio Cobos Álvarez]

Doing a bit of digging, 
https://bugzilla.mozilla.org/show_bug.cgi?id=680300 contains some more 
interesting context...


We apparently used to sync-throw when assigning location.href to an 
unknown protocol URI in the past, there we changed it to silently fail, 
and now it is navigating to an error page...


I'll try to look at when behavior changed around here... Though the 
sync-throwing clearly makes no sense as it doesn't account for redirects 
or what not.


 -- Emilio

On 3/29/20 8:23 AM, Emilio Cobos Álvarez wrote:
Hey, a quick web-observable change that may deserve a bit more 
visibility / an intent.


I'd welcome some feedback, specially from the fingerprinting / privacy 
angle (where I'm clearly not an expert).


Summary: A page redirecting / navigating to an unknown protocol will be 
silently ignored (and logged to the DevTools console) instead of showing 
an error page. This is not amazing, but it's needed because it causes a 
bunch of compat issues (see the list of issues in the bug below).


There are a few subtle problems here. Part of the issue is that authors 
don't have a cross-browser way of detecting whether a protocol will be 
handled externally (that is, whether an app is installed to handle a 
given protocol).


They technically can in Firefox (see example below). It's unclear 
whether we want to expose more than that, or that at all.


Given Chrome just ignores the navigation if they can't handle it, some 
authors (who don't seem to test on other browsers ;)) just spam the 
redirect (using various methods like the location href setter / meta 
refresh / whatevs). This works just fine in Chromium-based browsers, but 
not in Firefox or Safari, which will just show an error, which causes a 
very frustrating experience for users.


As far as I know, this behavior doesn't really expose more information 
than we were exposing before. In a test-case like:


   
   

we have different behavior also before this patch: the contentDocument 
for the handled-protocol iframe will be accessible to content, and be 
about:blank. The contentDocument for the unhandled protocol will be the 
error page, which will not be accessible to content and thus be null.


Other browsers seem to do about:blank for both iframes, but you can also 
detect this in all browsers via window.open instead (there may be other 
ways around it too, haven't dug all that much). Chrome insta-closes the 
handled protocol window (so you can check window.closed). Firefox / 
Safari will leave about:blank in that window, and show an error document 
for the second (which will throw a security error on access).


So I don't think this change introduces a new privacy hole. That being 
said, this all seems a bit sad, and a somewhat-serious potential 
fingerprinting factor. I was in fact a bit nervous about this change 
before realizing we were already exposing this information in other 
(even simpler to test) ways... But I'm clearly not an expert on this 
matter.


There are mitigations possible both for the ignored-navigation case 
(maybe only ignore the navigation to an unknown protocol once per 
document or something, and only for browsing contexts that can't be 
accessed by any ancestor JS? not sure) and the iframe case (probably 
just not show error pages in frames?). Please let me know if I you think 
I should file this and follow-up on it.


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1528305

Standard: https://html.spec.whatwg.org/#process-a-navigate-url-scheme 
allows for both the old and new behavior, as far as I (and Anne) can 
tell. This uses urls after redirect and so on so beforeunload and such 
will fire. This matches the behavior of Chromium browsers.


Preference: dom.no_unknown_protocol_error.enabled (I could've sweated it 
a bit more).


Devtools bug: N/A, ignored navigations get logged to the console.

Other browsers: Chromium browsers do this, but WebKit doesn't seem to. 
This was causing compat issues, specially on Android, but also desktop 
(see above).


web-platform-tests: Spec allows both behaviors, so I've added an 
internal test for now. Furthermore it's not clear if we want to do this 
for sub-windows, which my patch does, so I may need to tweak the test or 
add an internal switch depending on the outcome of the discussion here.


Secure contexts: not restricted to secure contexts, this is a compat 
hack, of sorts...


Is this feature enabled by default in sandboxed iframes? Not sure if the 
question quite applies to this, but we don't special-case sandboxed 
iframes here. This doesn't expose anything you couldn't do before, as 
discussed above.


Thanks for reading all the way until here

  -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: Ignore navigation to unknown protocol

[Emilio Cobos Álvarez]

Hey, a quick web-observable change that may deserve a bit more 
visibility / an intent.


I'd welcome some feedback, specially from the fingerprinting / privacy 
angle (where I'm clearly not an expert).


Summary: A page redirecting / navigating to an unknown protocol will be 
silently ignored (and logged to the DevTools console) instead of showing 
an error page. This is not amazing, but it's needed because it causes a 
bunch of compat issues (see the list of issues in the bug below).


There are a few subtle problems here. Part of the issue is that authors 
don't have a cross-browser way of detecting whether a protocol will be 
handled externally (that is, whether an app is installed to handle a 
given protocol).


They technically can in Firefox (see example below). It's unclear 
whether we want to expose more than that, or that at all.


Given Chrome just ignores the navigation if they can't handle it, some 
authors (who don't seem to test on other browsers ;)) just spam the 
redirect (using various methods like the location href setter / meta 
refresh / whatevs). This works just fine in Chromium-based browsers, but 
not in Firefox or Safari, which will just show an error, which causes a 
very frustrating experience for users.


As far as I know, this behavior doesn't really expose more information 
than we were exposing before. In a test-case like:


  
  

we have different behavior also before this patch: the contentDocument 
for the handled-protocol iframe will be accessible to content, and be 
about:blank. The contentDocument for the unhandled protocol will be the 
error page, which will not be accessible to content and thus be null.


Other browsers seem to do about:blank for both iframes, but you can also 
detect this in all browsers via window.open instead (there may be other 
ways around it too, haven't dug all that much). Chrome insta-closes the 
handled protocol window (so you can check window.closed). Firefox / 
Safari will leave about:blank in that window, and show an error document 
for the second (which will throw a security error on access).


So I don't think this change introduces a new privacy hole. That being 
said, this all seems a bit sad, and a somewhat-serious potential 
fingerprinting factor. I was in fact a bit nervous about this change 
before realizing we were already exposing this information in other 
(even simpler to test) ways... But I'm clearly not an expert on this matter.


There are mitigations possible both for the ignored-navigation case 
(maybe only ignore the navigation to an unknown protocol once per 
document or something, and only for browsing contexts that can't be 
accessed by any ancestor JS? not sure) and the iframe case (probably 
just not show error pages in frames?). Please let me know if I you think 
I should file this and follow-up on it.


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1528305

Standard: https://html.spec.whatwg.org/#process-a-navigate-url-scheme 
allows for both the old and new behavior, as far as I (and Anne) can 
tell. This uses urls after redirect and so on so beforeunload and such 
will fire. This matches the behavior of Chromium browsers.


Preference: dom.no_unknown_protocol_error.enabled (I could've sweated it 
a bit more).


Devtools bug: N/A, ignored navigations get logged to the console.

Other browsers: Chromium browsers do this, but WebKit doesn't seem to. 
This was causing compat issues, specially on Android, but also desktop 
(see above).


web-platform-tests: Spec allows both behaviors, so I've added an 
internal test for now. Furthermore it's not clear if we want to do this 
for sub-windows, which my patch does, so I may need to tweak the test or 
add an internal switch depending on the outcome of the discussion here.


Secure contexts: not restricted to secure contexts, this is a compat 
hack, of sorts...


Is this feature enabled by default in sandboxed iframes? Not sure if the 
question quite applies to this, but we don't special-case sandboxed 
iframes here. This doesn't expose anything you couldn't do before, as 
discussed above.


Thanks for reading all the way until here

 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to prototype and ship: Make

[Emilio Cobos Álvarez]

This is more of a bugfix but I think an intent is warranted.

Summary: Defer 

Intent to prototype: :focus-visible pseudo-class.

[Emilio Cobos Álvarez]

Hi,

In bug 1617600 I plan to land a patch to implement :focus-visible, 
behind a pref, on by default on Nightly / Early Beta.


Summary: Implement the :focus-visible pseudo-class, which is like 
:focus, but with heuristics about when _not_ to show focus rings, for 
example.


This is similar in intent to :-moz-focusring, but not in behavior. In 
particular, :-moz-focusring is stateful, and all-or-nothing. Once you've 
tab-navigated in a window, _everything_ shows focus rings. See comments 
in bug 1445482 about why that doesn't match developers' expectations.


For now the heuristic I'm going to implement is quite simple: We don't 
match the pseudo-class if focused via mouse / touch, and we do 
otherwise. This heuristic will almost-surely need tweaking. Simple 
example: we probably want to match the pseudo-class unconditionally for 
editable elements and such. By providing an early implementation, the 
idea is for Nightly / Dev Edition users and developers to file bugs 
against it as needed.


We should consider also add a preference to always match focus-visible 
users with higher accessibility needs, etc... I'll make sure to check 
with the a11y team about this. This all should be pretty easy to implement.


The idea here is that we could eventually alias our :-moz-focusring 
pseudo-class to be :focus-visible.


Bug: Main bug for the feature is bug 1445482. Bug for the initial 
implementation is above.


Pref: layout.css.focus-visible.enabled

Standard: https://drafts.csswg.org/selectors-4/#the-focus-visible-pseudo

Platform coverage: all

DevTools bug: I filed bug 1617608 to allow toggling the pseudo-class. I 
don't think there's much else needed but let me know if you think otherwise.


Other browsers:

 * WebKit: Not implemented yet: 
https://bugs.webkit.org/show_bug.cgi?id=185859


 * Chromium: Behind a flag, work ongoing in 
https://bugs.chromium.org/p/chromium/issues/detail?id=817199


web-platform-tests: There are some basic tests in 
https://wpt.fyi/results/css/selectors?label=master=experimental=focus-visible 
(with some manual tests in that directory as well). This feature 
involves heuristics so not all the tests may qualify as non-tentative 
WPT (though I plan to land our tests for features that developers 
request with .tentative suffix).


Secure contexts: Not restricted to secure context, as many related CSS 
features.


Is this feature enabled by default in sandboxed iframes? Yes

 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to prototype and ship: CSS comparison functions: min() / max() / clamp()

[Emilio Cobos Álvarez]

On 2/21/20 11:46 AM, James Graham wrote:

On 21/02/2020 01:42, Emilio Cobos Álvarez wrote:
web-platform-tests: There's a variety of tests in: 
https://wpt.fyi/results/css/css-values?label=master=experimental=minmax%7Cclamp 



Do we have any sense of how good the test coverage is?


Pretty good, IMO.

Also, not having enabled causes some confusing (but technically 
correct!) behavior for developers[1][2], which is IMO worth 
addressing, and also kinda likely to show up as compat bugs (specially 
on mobile where env() is used the most).


I assume the word "env()" is missing between "having enabled" and "causes"?


Err, not quite. The issue is caused by env() being enabled and min() / 
max() not being enabled. That means that developers would usually write 
something like:


  padding: 10px;
  padding: max(env(safe-area-something-something), 10px);

Expecting that the 10px declaration would take effect if the browser 
doesn't support max().


But instead the declaration at the bottom parses and computes to zero 
(per spec). The right way to do that is to do something like @supports 
(padding: max(0px)) { ... } or such, but...


 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to prototype and ship: CSS comparison functions: min() / max() / clamp()

[Emilio Cobos Álvarez]

Hi,

In bug 1519519 I plan to enable the min() / max() / clamp() CSS 
functions by default.


Summary: These functions allow authors to do what their name says :-)

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1519519

Standard: https://drafts.csswg.org/css-values-4/#comp-func

Platform coverage: All

Preference: layout.css.comparison-functions.enabled

Devtools bug: N/A. I thought that devtools auto-completed "calc" (and 
thus that these functions would be a reasonable thing to add), but 
apparently they don't, so not much else to do.


Other browsers:

 * Safari: Shipped since ages ago 
(https://bugs.webkit.org/show_bug.cgi?id=167000)
 * Chrome: Shipped since v79 
(https://www.chromestatus.com/feature/5714277878988800)


web-platform-tests: There's a variety of tests in: 
https://wpt.fyi/results/css/css-values?label=master=experimental=minmax%7Cclamp


Note that some of those tests are not up-to-date with the latest spec 
and working group discussions regarding serialization / simplification. 
Still I think our implementation is closer to the spec than other 
browsers. Anyhow that testing issue is tracked in 
https://github.com/web-platform-tests/wpt/issues/21599.


Also, not having enabled causes some confusing (but technically 
correct!) behavior for developers[1][2], which is IMO worth addressing, 
and also kinda likely to show up as compat bugs (specially on mobile 
where env() is used the most).


Let me know if there's any concern with proceeding.

  -- Emilio

[1]: https://twitter.com/vincentriemer/status/1213244088998383620
[2]: https://twitter.com/ecbos_/status/1213622047206711296
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [blink-dev] Re: What to do about scroll anchoring?

[Emilio Cobos Álvarez]

A quick status update here:

I landed some heuristics to disable scroll anchoring in pathological 
cases in Firefox a long while ago. This stopped virtually all compat 
issues, though it's obviously not great.


Chris and other Chromium folks have been doing work to fix Chromium 
issues that were causing these interop problems, and improving the 
scroll anchoring spec.


So I'm going to try and peek up those spec changes in Firefox and then 
try to remove those heuristics on Nightly, and see how it goes.


 -- Emilio

On 11/7/19 12:07 AM, Chris Harrelson wrote:

HI Emilio,

I'll follow up on crbug.com/920289 <http://crbug.com/920289>. Let's 
discuss there.


On Tue, Oct 29, 2019 at 3:03 PM Emilio Cobos Álvarez <mailto:emi...@mozilla.com>> wrote:


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
<https://bugzilla.mozilla.org/show_bug.cgi?id=1592094#c15>
[2]: https://bugs.chromium.org/p/chromium/issues/detail?id=920289
<https://bugs.chromium.org/p/chromium/issues/detail?id=920289>

 > Thanks all,
 > Chris
 >
 >
 > On Thu, Oct 10, 2019 at 2:13 PM Rick Byers mailto:rby...@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 c

Re: Intent to ship: native rendering of outline-style: auto

[Emilio Cobos Álvarez]

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  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 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

Intent to ship: native rendering of outline-style: auto

[Emilio Cobos Álvarez]

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 (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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: You can use UTF8String from WebIDL

[Emilio Cobos Álvarez]

On 1/6/20 11:12 AM, Jan de Mooij wrote:
On Mon, Jan 6, 2020 at 2:51 AM Emilio Cobos Álvarez <mailto:emi...@mozilla.com>> wrote:


If it's not, it could be optimized teaching JSStrings to store UTF-8
instead of / on top of Latin1 or such, or returning more information
from the callee, but I don't know how easy would be the first (IIRC
we're out of JSString bits), and how worth it would be the second.
Feedback here from JS engine hackers would be much appreciated.


Supporting UTF8 JSStrings natively would be quite a lot of work. I added 
Latin1 strings a few years ago but Latin1 is a bit simpler than UTF8 
because most algorithms could be templatized to work with either char 
type. If most of your UTF8 strings are (7-bit) ASCII, it might make 
sense short-term to use a Latin1 external string to avoid copies.


Yeah, most of them are ASCII, but it's not easy to track that that the 
output is ASCII... It'd still be doable though.


One possible approach would be to treat UTF8 JSStrings somewhat similar 
to ropes: initially most places working with JSString characters would 
end up converting from UTF8 to Latin1/TwoByte but after that we could 
(incrementally) optimize these functions to work with UTF8 strings 
directly where possible.


Yeah, I suspect the most common operations that are done on CSS strings 
are comparing them, passing them back to the OM, appending to them, and 
parse{Int,Float} them (with various variants of split(), substr() and 
such involved), so yeah that sounds viable...


Anyhow I need to do some profiling for various cases here to see what 
amount of complexity is worth taking for this.


Thanks a lot!

 -- Emilio


Jan

___
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

PSA: You can use UTF8String from WebIDL

[Emilio Cobos Álvarez]

If you need UTF-8 inputs from WebIDL (for example if you are passing the 
input to Rust), chances are you're doing an extra copy from JS.


In bug 1449861 I've added an UTF8String so that you can convert a 
JSString to UTF-8 in a single operation, instead of going through UTF-16.


I can't think if any reason not to use it in places where you take a 
USVString / DOMString argument and you turn it internally to utf-8 via 
NS_ConvertUTF16toUTF8.


I'd be a bit more wary of stuff that _returns_ UTF-8 output for now, at 
least for very-performance-sensitive code. I need to do some profiling 
and such to see if it's worth it as-is for CSSOM.


If it's not, it could be optimized teaching JSStrings to store UTF-8 
instead of / on top of Latin1 or such, or returning more information 
from the callee, but I don't know how easy would be the first (IIRC 
we're out of JSString bits), and how worth it would be the second. 
Feedback here from JS engine hackers would be much appreciated.


It'd be pretty great to eventually be able to share UTF-8 strings with 
JS the same way we can share strings with C++ via nsStringBuffer... But 
again that's probably follow-up work.


Anyhow, I hope you find it useful. This is built on top of various great 
work by Henri Sivonen, Jeff Walden and others, and the always-helpful 
reviews of Boris Zbarsky when dealing with WebIDL. So in the end I 
mostly took care of doing the plumbing :-).


Cheers,

 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: @media (-moz-touch-enabled)

[Emilio Cobos Álvarez]

On 10/17/19 9:22 AM, Emilio Cobos Álvarez wrote:

Hi all,

In bug 1588737 I plan to remove access to the -moz-touch-enabled media 
feature.


This is a non-standard media-query feature that predates the standard 
hover and any-hover media features. It seems that Modernizr (a fairly 
popular library to do feature detection) bogusly uses it to assume that 
touch events are enabled on a given device, which confuses websites like 
the one in the bug.


There's no reason these days to use it, and even our frontend doesn't 
even use it anymore, so I'm going to try to disable it for Nightly / 
Early beta for now, and assuming there's no compat fallout I'll disable 
it everywhere eventually (I'll send a follow-up email to this list when 
that happens).


This follow-up is happening now in:

  https://bugzilla.mozilla.org/show_bug.cgi?id=1486964

 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Ship: CSS Shadow Parts.

[Emilio Cobos Álvarez]

As of soon (whenever the patches are reviewed) I intend to turn CSS 
Shadow Parts on by default on all platforms.


It has been developed behind the layout.css.shadow-parts.enabled preference.

Blink has shipped it for a while and Safari implements it in the latest 
TP and is enabled by default on trunk, afaict.


We had an incomplete implementation (without part forwarding) for a 
while enabled, to support our front-end code, which has been using it 
quite heavily, so I'm pretty sure it's solid.


I implemented the missing bits in bug 1559076 and related.

Bug to turn on by default: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1559074


Standard: https://drafts.csswg.org/css-shadow-parts/

Platform coverage: All

DevTools bug: N/A, Devtools works fine with this feature already, parts 
show up correctly in the inspector and their rules work fine.


web-platform-tests: We'll be passing all tests in 
https://wpt.fyi/results/css/css-shadow-parts


Secure contexts: Other browsers are shipping this in non-secure 
contexts, but even with that I'd be somewhat skeptic of the value of 
restricting this CSS feature to secure contexts.


Is this feature enabled by default in sandboxed iframes? Yes
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: changes to numerous DOM components on Bugzilla

[Emilio Cobos Álvarez]

On 11/8/19 10:26 AM, Anne van Kesteren wrote:

Heya,

In https://bugzilla.mozilla.org/show_bug.cgi?id=1594717 the DOM team
requested quite a number of changes to their various components in
Mozilla's Bugzilla. Those components are now prefixed with either
"DOM:" or "Storage:". Please keep this in mind if you can't find a
component in its usual place.


Thanks for the PSA.

I sent https://github.com/mozilla-frontend-infra/codetribute/pull/358 to 
update the codetribute site so that good-first-bugs from those 
components appear there.


 -- Emilio


Thanks to everyone who helped with this cleanup and please let me know
if you have any questions or further suggestions.

Kind regards,

Anne
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Upcoming changes to hg.mozilla.org access

[Emilio Cobos Álvarez]

On 11/2/19 12:53 PM, Andreas Tolfsen wrote:

Documentation changes have historically been well served by a “wiki
editing”/micro adjustments approach.  I wonder if there is anything
we can do with Phabricator to ease review requirements for documentation
changes from peers?


I think you can land patches without review even with Lando. I 
personally think that's acceptable for typo fixes / documentation 
updates / etc.


It's certainly a few more clicks than `git push` / `hg push` though.

 -- Emilio



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [blink-dev] Re: What to do about scroll anchoring?

[Emilio Cobos Álvarez]

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  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  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+unsubscr...@chromium.org.
To view this 

Intent to unship: window.mozPaintCount.

[Emilio Cobos Álvarez]

In bug 1591968 I'm trying to add a default-off preference for 
window.mozPaintCount.


This Gecko-only API returns the amount of times that a page has been 
painted to the window (sorta, it's a bit unclear what it is exactly 
counting, given the point of the code where the count is incremented[1], 
at least to me, or how would it interact with Fission).


I don't think this API should be exposed to content as it exposes stuff 
that we generally don't want to expose (and makes some information that 
a page would otherwise need to obtain via side-channels readily available).


The preference will be dom.mozPaintCount.enabled. I don't really expect 
anyone to be using this with any legit purpose (there were only internal 
tests, and a quick search only yields various types of fps-counters that 
deal with the lack of the property). But let me know if you want me to 
add a use-counter and such for a few releases before doing this, 
probably would be better.


Thanks,

 -- Emilio

[1]: 
https://searchfox.org/mozilla-central/rev/74cc0f4dce444fe0757e2a6b8307d19e4d0e0212/layout/base/PresShell.cpp#6055

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: To what extent is sccache's distributed compilation usable?

[Emilio Cobos Álvarez]

On 10/25/19 2:54 AM, Marcos Caceres wrote:

Do you know if it's possible to cross compile on one of those for to target 
MacOS? I'd like to build on, and for, MacOS.


Our official mac builds are cross-compiled from Linux, IIRC. So yeah, it 
should be possible to do that.


Cross-compiling to target MacOS is a bit involved, requiring getting the 
relevant SDKs in the Linux box, the relevant mozconfig flags, and what 
not. But probably nothing too bad? I've done it in the past, mostly 
cargo-culting from the official mozconfigs in the tree. Not sure if 
there are official docs somewhere though.


I also know that sccache-dist can be used somewhat painlessly from Mac, 
unlike icecc (requires some setup as described here[1], but doesn't seem 
too bad).


So you have two options, I think:

 * Setup a Linux box as an sccache-dist scheduler and builder. This 
should require no SDKs or what not, but requires some setup in your mac 
as described here[1]. Then you'd just do regular sccache-enabled ./mach 
build from your Mac, which would then distribute work to your Linux box.


 * Setup a Linux box with a full cross-compilation setup, build there, 
and somehow pull the objdir from there back to your mac (not sure what's 
best here for incremental builds, rsync or something?).


If you only have one builder, and your Mac is slow, the second option is 
probably a bit faster to get a clobber build than sccache (as you don't 
need to do network stuff for every compilation unit and such). But 
obviously I haven't measured, so it may be the case that the sccache 
overhead is low and the extra cores from your mac add up for it.


Some caveats about the second setup:

 * I don't know how to best do the objdir / incremental builds with 
such a setup (some people in this list probably know though, and I'd be 
interested in knowing too!).


 * You need to do your changes over ssh, or have a setup where you also 
sync the src directories or something.


The first option should also be relatively straight-forward, hopefully, 
looking at the docs here[2], though I haven't set up an sccache 
scheduler myself.


Again there's people in this list that know more than me, so probably 
they can help more :)


Cheers,

 -- Emilio

[1]: 
https://firefox-source-docs.mozilla.org/build/buildsystem/sccache-dist.html
[2]: 
https://github.com/mozilla/sccache/blob/master/docs/DistributedQuickstart.md#configure-a-scheduler

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using MozPhab without Arcanist

[Emilio Cobos Álvarez]

On 10/23/19 10:24 PM, Emma Humphries wrote:

Will this make it easier for non-staff contributors to get their change
sets reviewed and landed?

What else should we be doing for that.

I have some ideas I'm working on for views in Bugzilla to help with that so
that contributors can see what's going on, and where they can take action
to help.


Somewhat unrelatedly, I think the most common issue I see with new 
contributors is they failing to set a reviewer. That means that their 
patch goes completely unnoticed... In that case not sure what can help, 
other than some of us noticing :/


I'm sure this is not a new problem though... That being said, it's a 
legit use-case, IMO, to update a WIP patch to phabricator without a 
reviewer, for example, to avoid spamming...


Maybe tools like moz-phab could suggest reviewers, or have a warning for 
the "no reviewers" case?


 -- Emilio



-- Emma

On Wed, Oct 23, 2019 at 8:56 AM glob  wrote:


It's available now - make sure you're running the latest version by
running `moz-phab self-update`.


-glob

Henrik Skupin wrote on 23/10/19 11:49 pm:

Piotr Zalewa wrote on 22.10.19 17:25:


Since today MozPhab does not require Arcanist to submit patches in all
supported VCS's. It's an optional and experimental feature. Add the
`--no-arc` option to switch it on.

Great to hear, but is there also an ETA when this mode will be available
for users of Mercurial? When I use this option I get:


NotImplementedError: Mercurial revisions can't be submitted without

Arcanist

Thanks



--
glob — engineering workflow — moz://a

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS subgrid

[Emilio Cobos Álvarez]

On 10/18/19 12:31 AM, ikilpatr...@chromium.org wrote:

::marker (which seems like it was only shipped recently) probably should have 
been restricted to secure contexts by this policy?


FWIW (regardless of my opinion about the policy which I've stated on 
another post) Safari does ship ::marker since long time ago.


 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS subgrid

[Emilio Cobos Álvarez]

On 10/17/19 10:02 PM, ikilpatr...@chromium.org wrote:

On Thursday, October 17, 2019 at 12:47:27 PM UTC-7, Mats Palmgren wrote:

On 10/17/19 8:12 PM, ikilpatr...@chromium.org wrote:

On Thursday, October 17, 2019 at 11:06:48 AM UTC-7, Mats Palmgren
wrote:

As far as I know, we never constrain new CSS features to secure
contexts. At least not on the property/value level.


According to
https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/
you should be?

"Effective immediately, all new features that are web-exposed are to be
restricted to secure contexts. Web-exposed means that the feature is
observable from a web page or server, whether through JavaScript, CSS,
HTTP, media formats, etc."


True, but we have never applied that policy for CSS features
as far as I know.  Just recently we've added 'column-span',
the ::marker pseudo, new 'display' syntax with values like
'inline list-item', 'block ruby' etc, 'clip-path: path()',
and a long list of other CSS features since 2018.


These features (broadly speaking) are different however. According to the above 
policy:
"Exceptions to requiring secure contexts"
" - other browsers already ship the feature insecurely"

Most (all?) of the non-trivial features above have shipped in other browsers 
insecurely before shipping in Firefox, hence the above exception applies.

"subgrid" is different as Firefox is shipping this feature first.


As far as I know we don't even have a mechanism that I could
have used to restrict subgrid to secure contexts.  And to be
clear: I have no intention of blocking subgrid on waiting for
such a mechanism.


This should just involve passing a isSecureContext flag into the your CSS 
parser?



Kinda. For this case that'd probably be enough, since you are not 
introducing a new property... The general case (handle different 
properties being exposed differently in different contexts) is quite a 
bit more work, since stuff like serialization of shorthands in a 
declaration block could change depending on whether you're in a secure 
context or not, for example.


I'm not particularly convinced of the value of restricting subgrid to 
secure contexts (specially given no other CSS feature like that actually 
is, and that it makes the feature harder to use by stuff like frameworks 
or what not). But if people like Anne or Boris think it's valuable I'm 
ok making this change. As people have pointed out, the policy is a bit 
ambiguous as this could be seen as extending an existing feature or a 
new feature.


AFAICT, modulo paint() in Chrome, which has an associated 
[SecureContext] JS API, nobody has shipped such a restriction for any 
new CSS feature whatsoever. For new features we've implemented:


 * @supports selector(): 
https://groups.google.com/d/msg/mozilla.dev.platform/JNLPcIZRd2w/r6Boq0h2BQAJ 
(I included my rationale for not doing this)


 * The syntax changes to the display property: 
https://groups.google.com/d/msg/mozilla.dev.platform/0WFI1WvBbic/2yVDD9_UCwAJ


 * clip-path: path(): 
https://groups.google.com/d/msg/mozilla.dev.platform/RM5O36MZ4x4/FV5Tp9y4EQAJ


 * Various text-decoration bits: 
https://groups.google.com/d/msg/mozilla.dev.platform/Xsts-2ORpRY/j96vHsIRAAAJ



I guess the last two were implemented by safari at that point so we have 
that escape hatch.


Chromium hasn't been doing any better either, which I guess it's not 
necessarily an excuse... From a quick test, CSS.registerProperty and all 
 of Typed OM is available in non-secure contexts.


If people decide that following that post to the letter for the specific 
case of subgrid is worth it I'm happy to do that, but in general (and 
based on the above data) I think the post you linked too aggressive, and 
having a hard mode switch between secure / non-secure contexts, 
specially for "regular" CSS features that don't have associated 
Javascript APIs, doesn't sound particularly appealing to me.


And finally, thanks for starting this discussion Ian, I think it's worth 
clarifying the situation here.


 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: @media (-moz-touch-enabled)

[Emilio Cobos Álvarez]

Hi all,

In bug 1588737 I plan to remove access to the -moz-touch-enabled media 
feature.


This is a non-standard media-query feature that predates the standard 
hover and any-hover media features. It seems that Modernizr (a fairly 
popular library to do feature detection) bogusly uses it to assume that 
touch events are enabled on a given device, which confuses websites like 
the one in the bug.


There's no reason these days to use it, and even our frontend doesn't 
even use it anymore, so I'm going to try to disable it for Nightly / 
Early beta for now, and assuming there's no compat fallout I'll disable 
it everywhere eventually (I'll send a follow-up email to this list when 
that happens).


Let me know if there's any concerns with doing this.

Thanks,

 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Finding windows and docshells leaked until shutdown

[Emilio Cobos Álvarez]

Not an expert in leak-hunting, but generally this happens every time you 
leave something like an observer or such registered and you don't 
de-register it where the page goes away. It'd keep all the window alive. 
Probably can also happen with some native event listeners or what not...


A recent example if it may help: This patch got backed out due to 
leaking the layout debugger window:


  https://hg.mozilla.org/integration/autoland/rev/3f8c2c77cd63

This is the fixed version:

  https://hg.mozilla.org/integration/autoland/rev/ddfb38a12cdf

And this the interdiff:

  https://phabricator.services.mozilla.com/D47715?vs=170954=171025

That one was pretty obvious to fix, but yeah, tracking pre-existing ones 
is tricky... I think the best way to do that is using:


  https://github.com/amccreight/heapgraph

On the logs generated using:


https://developer.mozilla.org/en-US/docs/Mozilla/Performance/GC_and_CC_logs

(There are docs there about how to generate those from automation)

This is useful to find leaks of individual objects too, where you may 
want to find where the object is allocated rather than what keeps it alive:


  https://developer.mozilla.org/en-US/docs/Mozilla/Performance/BloatView

But I guess that's not all that useful for chasing window leaks.

I'm not an expert on these tools myself, hopefully Andrew or one of the 
people with more experience with them can help more...


Hope it helps,

 -- Emilio

On 10/2/19 11:29 PM, Geoff Lankow wrote:

Hi all, I need some advice.

I'm trying to enable Mochitest on debug builds of Thunderbird. It works 
fine, except for the leak check, which finds a number of leaked windows 
and docshells. Obviously we don't want to leak these things, but I can't 
find what's holding onto them.


I've ruled out a number of likely candidates and I'm quickly running out 
of ideas. Can you offer any tips or tricks that might help?


Here's an example log: 
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=267576044=try-comm-central=8051 



GL
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Range-based for and STL-style iterators for nsClassHashtable, nsDataHashtable, nsInterfaceHashtable

[Emilio Cobos Álvarez]

When trying to port some of the usage in layout/style to this, I 
realized that there's no way to remove entries while iterating, so you 
can't port [1] to this for example.


Is there something I've missed? Should I file a bug about it?

Or should we just keep using old style iterators for that?

Cheers,

 -- Emilio

[1]: 
https://searchfox.org/mozilla-central/rev/f372e8a46ef7659ef61be9938ec2a3ea34d343c6/layout/style/Loader.cpp#673


On 10/2/19 3:02 PM, Emilio Cobos Álvarez wrote:

This is great, thanks for doing this!

  -- Emilio

On 10/2/19 12:15 PM, Simon Giesecke wrote:

Hi,

I recently [1] added STL-style iterators and begin/cbegin/end/cend
member functions to nsBaseHashtable. This means that it is now
possible to use range-based for and STL algorithms operating on
iterators with all of its subclasses, which include nsClassHashtable,
nsDataHashtable, nsInterfaceHashtable, nsJSThingHashtable and
nsRefPtrHashtable.

I also added an overview on existing support for range-based for and
STL-style iterators in Mozilla data structures on MDN  at [2].

If you have any questions or issues, please let me know or NI me on 
Bugzilla.


Best wishes
Simon

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1575479
[2] 
https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code#Mozilla_data_structures_and_standard_C_ranges_and_iterators 


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Range-based for and STL-style iterators for nsClassHashtable, nsDataHashtable, nsInterfaceHashtable

[Emilio Cobos Álvarez]

This is great, thanks for doing this!

 -- Emilio

On 10/2/19 12:15 PM, Simon Giesecke wrote:

Hi,

I recently [1] added STL-style iterators and begin/cbegin/end/cend
member functions to nsBaseHashtable. This means that it is now
possible to use range-based for and STL algorithms operating on
iterators with all of its subclasses, which include nsClassHashtable,
nsDataHashtable, nsInterfaceHashtable, nsJSThingHashtable and
nsRefPtrHashtable.

I also added an overview on existing support for range-based for and
STL-style iterators in Mozilla data structures on MDN  at [2].

If you have any questions or issues, please let me know or NI me on Bugzilla.

Best wishes
Simon

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1575479
[2] 
https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code#Mozilla_data_structures_and_standard_C_ranges_and_iterators
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: Infer aspect-ratio from img width and height attributes.

[Emilio Cobos Álvarez]

Hi,

As of today I intend to turn this feature on for release and beta 
channels (it was enabled only on Nightly until now).


It's been developed behind the 
layout.css.width-and-height-map-to-aspect-ratio.enabled pref.


Bug to turn on by default: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1585637


This was implemented in bug 1547231.

Spec link is 
https://html.spec.whatwg.org/multipage/rendering.html#attributes-for-embedded-content-and-images 
(spec PR: https://github.com/whatwg/html/pull/4952).


Platform coverage: All

web-platform-tests: 
https://github.com/web-platform-tests/wpt/blob/abb820ae83ffb82ccd8380ce61685b51329a7b07/html/rendering/replaced-elements/attributes-for-embedded-content-and-images/img-aspect-ratio.tentative.html 
(which I guess I should rename now that there's a spec).


Relevant browser bugs:

Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=979891
Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1547231
Safari: https://bugs.webkit.org/show_bug.cgi?id=201641

Secure contexts: not restricted to secure contexts, as many layout features.

Is this feature enabled by default in sandboxed iframes? Yes

Let me know if there's any concern with this.

Thanks,

 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: Negative radii in radial gradients.

[Emilio Cobos Álvarez]

These were always invalid per spec, but every browser parsed them.

Chromium was fixing a few of their bugs in the area (see 
https://github.com/w3c/csswg-drafts/issues/4042), and they made the 
change to reject negative lengths as well in:


 * https://bugs.chromium.org/p/chromium/issues/detail?id=1008112
 * https://bugs.chromium.org/p/chromium/issues/detail?id=978790

I think it makes sense, and somebody else independently filed:

 * https://bugzilla.mozilla.org/show_bug.cgi?id=1583736

So I think it's worth trying to get the change here.

Note that this affects both prefixed and modern gradient syntax.

Relatedly, recently people found interesting compat bugs in legacy 
gradients [1]... I may land a fix for that in the near future but that's 
not the point of this intent (that has ~no potential of breaking sites 
so I don't think it's worth an intent, so it's basically a bugfix).


There are WPTs for this change, and I didn't see a WebKit bug so I filed 
one at https://bugs.webkit.org/show_bug.cgi?id=202412.


Cheers,

 -- Emilio

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1583746
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [blink-dev] Re: What to do about scroll anchoring?

[Emilio Cobos Álvarez]

On 9/29/19 5:07 AM, Rick Byers wrote:
On Fri, Sep 27, 2019 at 10:16 AM Emilio Cobos Álvarez 
mailto:emi...@mozilla.com>> wrote:


Hi Steve,

On 9/27/19 4:03 PM, Steve Kobes wrote:
 > Hi Emilio,
 >
 > My recollection is that scroll anchoring was, in fact, a mess.  I
do not
 > personally have any opinion about whether scroll anchoring should be
 > removed from Gecko.
 >
 > We (Chrome) decided to accept some compat issues for the sake of
 > launching the feature.  This was a judgment call and could
reasonably
 > have gone the other way.

Right, my concern is that taking compat fallout with Chrome's market
share may be acceptable, because people will likely fix their websites
if they misbehave.

But web developers may not take the same time to fix their site if it's
broken on Firefox for Android, for example, which in turn drives
Firefox
users away (and you know this is a vicious cycle, the less users you
have, the less people will care about fixing their websites in your
browser).

That being said, more generally, I care about being interoperable /
predictable here for web developers, and seems like that ship may have
sailed if we need to fix some Gecko-specific issues by tweaking our
heuristics, but Chromium / Blink doesn't change them in the same way
(which is understandable, I guess, though I've filed spec issues for
our
reasoning behind these changes, which I think would apply to Chrome as
well).


FWIW, I agree with this principle. I'm sorry you've had to do a lot of 
compat work on this Emilio. Are you saying you've found many cases where 
chromium's behavior doesn't match the spec / web-platform-tests and the 
different is relevant to real-world website compat (forcing you to 
invest in "bug-for-bug compatibility")? That would definitely make me 
very sad. Or is the issue more about compat with sites which have 
UA-conditional behavior (either explicit or implicit based on some other 
Gecko/blink difference?).


Well, part of it is that. The initial implementation took a lot of just 
figuring out what Chromium was doing rather than implementing the spec, 
because the spec had clear issues (like referencing the DOM rather than 
layout stuff).


Some of them like [1] were pretty obvious and were caught during our 
initial implementation of the feature. Others like [2] Ryan probably 
found by testing Chromium's behavior.


Some other still pretty significant behavior differences were only 
caught later by me and people finding compat issues in the wild, like 
[3]. I was sad that the spec reflected absolutely nothing like what 
Blink implements. For this issue in particular, Blink roughly uses 
"whatever inherits from LayoutBox can be an anchor", which is obviously 
not something that you can reasonably spec, and definitely not "block 
boxes and text", which is what the spec said.


Those are off the top of my head, Ryan probably has more examples.

IMHO In general, either an initially chromium-only feature is valuable 
enough that we should continue to invest as necessary to achieve interop 
with other engines when they implement (eg. adding web-platform-tests 
and improving the spec for the inevitable cases that appear with a 
second implementation), or we should decide the feature isn't worth the 
cost to properly support on the web at large and remove it from chromium.


Steve is the expert and can probably elaborate on details, but IIRC the 
real world web compat constraints of scroll anchoring ended up requiring 
a number of tough tradeoffs. If you're learning about new web compat 
constraints, then it's entirely possible that the cost/benefit equation 
is now different and we should be re-evaluating whether it still makes 
sense to keep scroll anchoring in chromium. Like David I like the 
feature - but only to the extent that it works alright for most of the 
web as it exists today, and developers can reliably reason about it (eg. 
by replacing any heuristics designed under the constraints of web-compat 
with explicit APIs).


Can you give us a week or so to chat about this within the Chrome team 
and get back to you?


Thanks, and sorry again for the frustration. When we ship a feature 
first in chromium, it's always our intent that subsequent compatible 
implementations should be MUCH easier to ship (it's one of the main 
reasons we invest so much in web-platform-tests).


Sure, no worries, and thanks for the reply.

 -- Emilio

[1]: https://github.com/w3c/csswg-drafts/issues/3480
[2]: https://github.com/w3c/csswg-drafts/issues/3319
[3]: https://github.com/w3c/csswg-drafts/issues/4247



   -- Emilio

 > On Fri, 27 Sep 2019 at 09:09, Emilio Cobos Álvarez
mailto:emi...@mozilla.com>
 > <mailto:emi...@mozilla.com <mailto:emi...@mozilla.com>>> wrote:
 >
 >     And, 

Re: What to do about scroll anchoring?

[Emilio Cobos Álvarez]

On 9/27/19 3:30 PM, twisniew...@mozilla.com wrote:

I suspect that if we can give our compat addon an easy way to specify sites 
which need an opt-out, that might ease the pain. Likewise, as obnoxious as the 
thought is, perhaps giving sites a standard way to opt out of anchoring could 
be a reasonable compromise, depending on developer feedback.


To be clear there is a standard way to opt out of scroll anchoring 
(overflow-anchor: none).


  -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [blink-dev] What to do about scroll anchoring?

[Emilio Cobos Álvarez]

On 9/27/19 3:02 PM, Kenji Baheux wrote:
Are these compat issues specific to Firefox, or do they also trigger 
weird behaviors on Chrome? Do you have a sense of the size and 
convergence for the problematic cases?


Some of the ones we've seen reported are specific to Firefox in the 
sense that they only happen in Firefox because we block some tracking 
code on the page, for example.


But test-cases without that difference like [1] do happen on Chrome as 
well. Fixing that in turn causes other interop issues.


Other sites for which I've investigated scroll anchoring issues just 
eternally burn CPU (this is fixed in Firefox, but still happens in 
Chrome). STR for example:


 * Go to http://lembarsaham.com/
 * Scroll to the middle of the page.
 * On the devtools console, do: window.addEventListener("scroll", () => 
console.log("scroll"))
 * In Chrome, you'll see scroll event listeners being fired constantly, 
each of those trashing layout to do literally nothing and burning CPU.


I don't think the size of the compat issues is spectacularly big, it's 
just somewhat frustrating because fixing some of them causes others to 
break, and is just a very thin line to walk.


If heuristics between Chrome and Firefox differ, sites that only test on 
Chrome (specially on mobile) will break on Firefox, and the failure mode 
is terrible.


If the heuristics are the same, then Firefox still gets compat issues 
for those sites, because of stuff like tracking protection.


 -- Emilio

[1]: https://bugzilla.mozilla.org/attachment.cgi?id=9087497

On Fri, Sep 27, 2019, 21:23 Emilio Cobos Álvarez <mailto:emi...@mozilla.com>> wrote:


Hi,

(cc'ing webkit-dev@ and blink-dev@ in case they have feedback or
opinions, as WebKit is the only engine which does not implement scroll
anchoring, though I don't know if they plan to, and Blink is the only
other engine that does implement it. Please reply to dev-platform@
though.)

TLDR: Scroll anchoring is really a mess.

I didn't do the initial implementation of the feature in Gecko, but
I've
done a ton of work over the last few months to fix compat issues in our
implementation (see all the bugs blocking [1]).

At this point, our implementation is mostly compatible with Blink, but
even with a bug-for-bug compatible implementation, we did get compat
issues because of different content being served for different
browsers,
or because our anti-tracking protections changing the final content of
the page slightly ([2] is an example of bug which only reproduces with
ETP enabled only, but whose reduced test-case renders the site unusable
in Chrome as well).

If you hit one of the broken cases as a user you think the browser is
completely broken, and the site is just unusable.

I've fixed those by tweaking the heuristics Gecko uses. Those extra
heuristics have also caused other compat issues, like [3], reported
today, which will require other adjustments to the heuristics, etc...

On top of that, the spec is not in a good state, with ton of open
issues
without feedback from the editors [4].

So right now I'm at a stage where I think that the feature is just not
worth it. It doesn't behave predictably enough for developers, and you
have no guarantee of it behaving consistently unless you test a
particular browser, with a particular content in a particular viewport
size... That's not great given the current dominant position of
Chromium-based browsers.

On top, issues with scroll anchoring are pretty hard to diagnose unless
you're aware of the feature.

All in all, it doesn't seem like the kind of feature that benefits a
diverse web (nor web developers for that matter), and I think we should
remove the feature from Gecko.

Does anyone have strong opinions against removing scroll anchoring from
Gecko, based on the above?

Thanks,

   -- Emilio

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1519644
<https://bugzilla.mozilla.org/show_bug.cgi?id=1519644>
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1561450
<https://bugzilla.mozilla.org/show_bug.cgi?id=1561450>
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1584499
<https://bugzilla.mozilla.org/show_bug.cgi?id=1584499>
[4]:
https://github.com/w3c/csswg-drafts/labels/css-scroll-anchoring-1
<https://github.com/w3c/csswg-drafts/labels/css-scroll-anchoring-1>

-- 
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+unsubscr...@chromium.org
<mailto:blink-dev%2bunsubscr...@chromium.org>.
To view this discussion on the web visit

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/83f17f7c-6b68-b7dd-0761-2

Re: What to do about scroll anchoring?

[Emilio Cobos Álvarez]

And, to be clear, we _can_ fix these compat issues, some way or another.

One thought is to limit the amount of scroll adjustments without user 
scrolling or stuff like that, which would prevent the "you get stuck on 
the page".


Making anchoring opt-in rather than opt-out is another option, but that 
defeats most of the purpose of the feature, I guess.


See also some of the Chromium docs on the compat issues they found[1] 
and how were they trying to fix them before adding the 
"layout-affecting-property changed" heuristic, which is what is on the 
spec right now and what they implement.


I just think that these are very hacky heuristics that are just going to 
bring a lot of compat pain and developer confusion.


It doesn't help that all these things can break or not depending on the 
speed at which the user scrolls, the amount of scroll events that the 
user dispatches, the timing of these events relative to other events, etc...


 -- Emilio

[1]: 
https://docs.google.com/document/d/1nQAO4MYCDMn0rTkn_-WI6gjumk3Qi2Bn-MGuB3NlVxE/edit


On 9/27/19 2:23 PM, Emilio Cobos Álvarez wrote:

Hi,

(cc'ing webkit-dev@ and blink-dev@ in case they have feedback or 
opinions, as WebKit is the only engine which does not implement scroll 
anchoring, though I don't know if they plan to, and Blink is the only 
other engine that does implement it. Please reply to dev-platform@ though.)


TLDR: Scroll anchoring is really a mess.

I didn't do the initial implementation of the feature in Gecko, but I've 
done a ton of work over the last few months to fix compat issues in our 
implementation (see all the bugs blocking [1]).


At this point, our implementation is mostly compatible with Blink, but 
even with a bug-for-bug compatible implementation, we did get compat 
issues because of different content being served for different browsers, 
or because our anti-tracking protections changing the final content of 
the page slightly ([2] is an example of bug which only reproduces with 
ETP enabled only, but whose reduced test-case renders the site unusable 
in Chrome as well).


If you hit one of the broken cases as a user you think the browser is 
completely broken, and the site is just unusable.


I've fixed those by tweaking the heuristics Gecko uses. Those extra 
heuristics have also caused other compat issues, like [3], reported 
today, which will require other adjustments to the heuristics, etc...


On top of that, the spec is not in a good state, with ton of open issues 
without feedback from the editors [4].


So right now I'm at a stage where I think that the feature is just not 
worth it. It doesn't behave predictably enough for developers, and you 
have no guarantee of it behaving consistently unless you test a 
particular browser, with a particular content in a particular viewport 
size... That's not great given the current dominant position of 
Chromium-based browsers.


On top, issues with scroll anchoring are pretty hard to diagnose unless 
you're aware of the feature.


All in all, it doesn't seem like the kind of feature that benefits a 
diverse web (nor web developers for that matter), and I think we should 
remove the feature from Gecko.


Does anyone have strong opinions against removing scroll anchoring from 
Gecko, based on the above?


Thanks,

  -- Emilio

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1519644
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1561450
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1584499
[4]: https://github.com/w3c/csswg-drafts/labels/css-scroll-anchoring-1
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

What to do about scroll anchoring?

[Emilio Cobos Álvarez]

Hi,

(cc'ing webkit-dev@ and blink-dev@ in case they have feedback or 
opinions, as WebKit is the only engine which does not implement scroll 
anchoring, though I don't know if they plan to, and Blink is the only 
other engine that does implement it. Please reply to dev-platform@ though.)


TLDR: Scroll anchoring is really a mess.

I didn't do the initial implementation of the feature in Gecko, but I've 
done a ton of work over the last few months to fix compat issues in our 
implementation (see all the bugs blocking [1]).


At this point, our implementation is mostly compatible with Blink, but 
even with a bug-for-bug compatible implementation, we did get compat 
issues because of different content being served for different browsers, 
or because our anti-tracking protections changing the final content of 
the page slightly ([2] is an example of bug which only reproduces with 
ETP enabled only, but whose reduced test-case renders the site unusable 
in Chrome as well).


If you hit one of the broken cases as a user you think the browser is 
completely broken, and the site is just unusable.


I've fixed those by tweaking the heuristics Gecko uses. Those extra 
heuristics have also caused other compat issues, like [3], reported 
today, which will require other adjustments to the heuristics, etc...


On top of that, the spec is not in a good state, with ton of open issues 
without feedback from the editors [4].


So right now I'm at a stage where I think that the feature is just not 
worth it. It doesn't behave predictably enough for developers, and you 
have no guarantee of it behaving consistently unless you test a 
particular browser, with a particular content in a particular viewport 
size... That's not great given the current dominant position of 
Chromium-based browsers.


On top, issues with scroll anchoring are pretty hard to diagnose unless 
you're aware of the feature.


All in all, it doesn't seem like the kind of feature that benefits a 
diverse web (nor web developers for that matter), and I think we should 
remove the feature from Gecko.


Does anyone have strong opinions against removing scroll anchoring from 
Gecko, based on the above?


Thanks,

 -- Emilio

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1519644
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1561450
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1584499
[4]: https://github.com/w3c/csswg-drafts/labels/css-scroll-anchoring-1
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Ship: line-height returns normal as a resolved value.

[Emilio Cobos Álvarez]

Summary: Return "normal" for line-height's resolved value (the value 
returned from getComputedStyle()) rather than a concrete pixel value, if 
the computed value is "normal".


This aligns us with Blink, and seems the best option according to 
various working group discussions, see below. In particular, normal maps 
to something that is not completely representable by pixel values.


This change has been on Nightly and Beta 69 without any known issues 
other than internal consumers (the fonts panel and thunderbird).


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1579624

Standard: CSSWG resolution in 
https://github.com/w3c/csswg-drafts/issues/4249


Platform coverage: All

Preference: layout.css.line-height.normal-as-resolved-value.enabled

DevTools bug: N/A, this works fine in inspector, and required a fix to 
the fonts panel that landed long ago.


Other browsers: Blink matches this change, WebKit matches (some version 
of) current Gecko behavior.


WPT: Added with the implementation in bug 1536871.

Secure contexts: N/A

Is this feature enabled by default in sandboxed iframes? Yes

 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: Naming parameters in lambda expressions

[Emilio Cobos Álvarez]

Yeah, let's not add a new prefix please.

I don't like aFoo either, though it's everywhere so consistency is 
better than nothing :/.


That being said, it shouldn't be hard to write some clang plugin or such 
that automatically renames function arguments to stop using aFoo, should 
we want to do that... Just throwing it in the air, and volunteering if 
we agreed to do that ;)


 -- Emilio

On 9/5/19 10:55 PM, Jeff Gilbert wrote:

I remain against aFoo style. I still think it's low-signal-high-noise, and
doesn't provide value that modern syntax highlighting doesn't provide for
those who find it useful.

I'm absolutely opposed to adding a new prefix. That would be moving even
further down the path of our proprietary code-smell.

On Thu, Sep 5, 2019 at 6:15 AM Simon Giesecke  wrote:


Hi,

we encountered the question of how to name parameters in lambda
expressions.

For regular functions, the coding style implies that parameter naming
should use camelCase with an "a" prefix, and this is also widely done
this way. The coding style does not say anything specifically
concerning lambda expressions at the moment. Actual uses differ at
least between using the a prefix and using no prefix.

Since in most cases, lambda expressions occur within a regular
function, using the a prefix leads to some ambiguity when reading the
code, as one cannot immediately tell whether an a-prefixed identifier
is a parameter to the lambda expression or to the enclosing function
(which may be captured).

For example, one might have:

bool MyFunction(const nsTArray& aFoos, const nsCString ) {
   if (std::any_of(aFoos.begin(), aFoos.end(), [aId](const Foo& aFoo) {
  return aFoo.Id() == aId;
   }) {
 // do something more...
 return true;
   }
   return false;
}

This is a simple case, where this might not be particularly
problematic, but I find it quite confusing to use aFoo as a lambda
parameter name. Obviously, when not using a prefix, similar
ambiguities with local variable names in the enclosing function may
arise. For some subjective reason, I find this less confusing, but
this may be different for others. Using a different prefix, e.g. l,
leading to calling the lambda parameter lFoo, would resolve this
ambiguity, but one might feel there are too many different prefixes.

While I have some personal preference against the a prefix here, I
think any of these options were acceptable. Maybe this has already
been discussed and concluded before, but not put into the coding style
document?

Simon
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: multi-keyword values on the CSS 'display' property

[Emilio Cobos Álvarez]

On 8/22/19 11:28 AM, 一丝 wrote:
Is there a plan to implement multi-valued table | flex | grid? E.g 
display: inline flex.


That should work, afaict.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: mozilla::Result is about to understand move semantics

[Emilio Cobos Álvarez]

On 8/12/19 10:38 PM, Bryce Seager van Dyk wrote:

On Monday, August 12, 2019 at 8:41:26 AM UTC-7, Emilio Cobos Álvarez wrote:

Neat! Thanks for doing this. It should allow for broader use of Result in media 
code.

Are there any footguns to watch out for when moving into the Result? Looking at the 
changes it appears that if my return type is Result then I can just 
return a BigStruct? I.e. I don't need to do explicitly invoke anything else to avoid 
unintended copies.


I think you need to use `return std::move(bigStruct);`, since otherwise 
you peek the `const T&` constructor rather than the `T&&` constructor. 
Before my patch, you always get a copy when returning it (because Result 
only took const references).


With my patch, if you `return bigStruct;`, your code will compile and do 
the same copy, but you'll get a warning from the compiler with 
-Wreturn-std-move, such as:


> In file included from 
z:/build/build/src/obj-firefox/toolkit/mozapps/extensions/Unified_cpp_mozapps_extensions0.cpp:11:
> 
z:/build/build/src/toolkit/mozapps/extensions/AddonManagerStartup.cpp(197,10): 
error: local variable 'result' will be copied despite being returned by 
name [-Werror,-Wreturn-std-move]

>   return result;
>  ^~
> 
z:/build/build/src/toolkit/mozapps/extensions/AddonManagerStartup.cpp(197,10): 
note: call 'std::move' explicitly to avoid copying

>   return result;
>  ^~
>  std::move(result)
> 
z:/build/build/src/toolkit/mozapps/extensions/AddonManagerStartup.cpp(197,10): 
error: local variable 'result' will be copied despite being returned by 
name [-Werror,-Wreturn-std-move]

>   return result;
>  ^~
> 
z:/build/build/src/toolkit/mozapps/extensions/AddonManagerStartup.cpp(554,20): 
note: in instantiation of function template specialization 
'mozilla::EncodeLZ4' requested here

>   MOZ_TRY_VAR(lz4, EncodeLZ4(scData, STRUCTURED_CLONE_MAGIC));
>^
> 
z:/build/build/src/toolkit/mozapps/extensions/AddonManagerStartup.cpp(197,10): 
note: call 'std::move' explicitly to avoid copying

>   return result;
>  ^~
>  std::move(result)

Note that this does not -Werror everywhere on automation right now[1], 
but I think we should make it so, per that LLVM bug.


But anyhow the compiler will tell you to do the fast thing once my patch 
lands.


 -- Emilio

[1]: 
https://searchfox.org/mozilla-central/rev/ec806131cb7bcd1c26c254d25cd5ab8a61b2aeb6/build/moz.configure/warnings.configure#144




dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: mozilla::Result is about to understand move semantics

[Emilio Cobos Álvarez]

If you don't use mozilla::Result, then you can stop reading now.

Result always returned the ok / errors by value. That's fine when the ok 
or error values are cheap / small, like integers, but over time we've 
been using Result> / Result / Result, etc.


Furthermore Result never worked with move-only types, so you couldn't 
use Result> or such.


In bug 1418624 I'm about to change mozilla::Result so that:

 * unwrap() / unwrapErr() / unwrapOr() / map() / andThen() move rather 
than copy the result.


 * inspect() and inspectErr() return a reference to the ok / error 
values respectively.


The first change allows the usage of move-only types, and is closer to 
the Rust semantics (though C++ doesn't have the borrow-checker to 
prevent use after moves).


The second change allows having big Result<>s on the stack, while not 
paying extra stack space to inspect them.


I audited and changed all callers that were calling the now-moving 
methods multiple times on the same error to use inspect() / 
inspectErr(). Most of them shouldn't matter, as moving trivial types 
doesn't do anything, but for some cases like some usages of std::wstring 
it should have a positive impact on performance.


Let me know if there's any concerns with this or what not.

Cheers,

 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: Ensure your favorite components are up-to-date in codetribute

[Emilio Cobos Álvarez]

I was wondering why some of the bugs which I mark as good first bugs / 
mentored weren't appearing in codetribute[1].


Turns out that the recent (ish, :/) reorg of the Layout and DOM 
components made them just silently disappear from the tool, which is 
pretty unfortunate (as it both makes bugs unfindable, and the lack of 
activity on existing bugs discourage people to mark more bugs as 
good-first-bugs / mentored).


I've fixed the stuff that I found broken in this PR[2]. Basically, fixed 
all the "Web Platform" / Core submodules that were missing, and added 
the build system product / components to "Internals", along with other 
nits. But please double-check me if you have the time :)


If you tag yourself as a mentor of a bug, or tag a bug as a 
good-first-bug, or similar, please double-check that it shows up in 
codetribute, and fix it otherwise.


Similarly, please try to remember when renaming or updating bugzilla 
components that it'll affect the tool.


I wish the tool could do a bit better. If we could auto-include some of 
the components like "Layout: *" or such, the recent reorgs wouldn't have 
caused so much breakage. For that I filed [3].


Cheers,

 -- Emilio

[1]: https://codetribute.mozilla.org/
[2]: https://github.com/mozilla-frontend-infra/codetribute/pull/320
[3]: https://github.com/mozilla-frontend-infra/codetribute/issues/321
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Make elements always unvisited.

[Emilio Cobos Álvarez]

On 8/9/19 1:29 PM, Anne van Kesteren wrote:

On Thu, Aug 8, 2019 at 8:39 PM Emilio Cobos Álvarez  wrote:

Standard: https://drafts.csswg.org/selectors-4/#location (though note
https://github.com/w3c/csswg-drafts/issues/3817).


So the real standard for this is
https://html.spec.whatwg.org/#pseudo-classes as CSS tries to be
host-agnostic (somewhat). It seems okay to me to get rid of this as
the  feature set always mismatched that of  and  a bit
and practically nobody would display a  anyway. Would you file
an issue against HTML to make it so?


So the spec says that it should always match either :link or :visited, 
and that's still true with my patch (which just never makes it match 
:visited). I filed an issue about having interop / never make them 
navigate away from the page, probably:


 https://github.com/whatwg/html/issues/4831

And this to consider whether almost all MathML elements should really be 
links:


  https://github.com/mathml-refresh/mathml/issues/125

(Because they are now).

 -- Emilio


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: Make elements always unvisited.

[Emilio Cobos Álvarez]

Summary: Make HTML  elements not query the browser history. This 
is unnecessary work, and matches other browsers (kinda, see below in the 
"Other browsers" section).


The TLDR is that even though this is technically required per spec as of 
today, it's a fairly obscure feature where there's no interop, and it 
causes issues unnecessarily, and extra history queries for no good reason.


Long term we should probably aim for  to not be traversable (even 
if you force-show it).


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1572246

Standard: https://drafts.csswg.org/selectors-4/#location (though note 
https://github.com/w3c/csswg-drafts/issues/3817).


Platform coverage: All

Preference: none

Devtools bug: N/A

Other browsers:

Behavior here is all over the place. We used to match the current spec 
text and WebKit, until 
http://trac.webkit.org/projects/webkit/changeset/244642 landed not long ago.


With this change, we'd match Edge and WebKit. Chrome is the only browser 
which doesn't consider  a :link to begin with, and you can't click 
on force-showed links.


We may want to aim for this behavior in the long run to simplify the 
code, since force-showing a  element doesn't seem useful over-all. 
That may or may not require changes in the HTML spec 
(https://html.spec.whatwg.org/#links).


 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: font-size: xxx-large

[Emilio Cobos Álvarez]

Summary:

Expose the xxx-large value for the font-size property, as resolved in 
https://github.com/w3c/csswg-drafts/issues/3907.


This value was previously accessible only via `` 
in HTML.


Sending an intent on behalf of the patch author.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1553545

Standard: 
https://drafts.csswg.org/css-fonts-4/#valdef-font-size-absolute-size


Platform coverage: All

Preference: None

DevTools bug: N/A

Other browsers:

  Blink: Fixed on trunk 
(https://bugs.chromium.org/p/chromium/issues/detail?id=966249)

  WebKit: Proposed the feature, but hasn't implemented yet AFAIK.

web-platform-tests: They exist, and a new reftest is added. See the patch.

Secure contexts: Not restricted, as all the other CSS font-size keywords.

Is this feature enabled by default in sandboxed iframes? Yes

 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Implement: CSS backdrop-filter

[Emilio Cobos Álvarez]

On 7/10/19 11:01 PM, Connor Brewster wrote:

Hi David,


It's not clear to me what this option means in terms of what you're
proposing to implement and ship.  @supports is a feature that web
developers can use -- and it should clearly match whether the
feature is supported.  However, I think what you're suggesting here
is that you might ship the feature only when WebRender is enabled --
I think that's something that requires further discussion, given the
confusion it would cause in the web development world.  It also
seems (?) like you're suggesting something else about limiting which
filters are usable to only those that have a GPU implementation in
WebRender -- but it's not clear to me if that's for backdrop-filter
only, or also for the filter property -- when WebRender is enabled.


The idea here is that @supports would reflect whether or not
backdrop-filter and WebRender are enabled. This would allow web
authors to add a fallback style if needed. I do agree that this would
cause some confusion and needs more discussion.


This seems pretty hard to do right / pretty awkward. @supports must 
reflect whether the property parses. Not enabling the property if 
webrender is not enabled seems hacky, but doable.


But if you have WebRender enabled and your GPU process crashes, going 
all the way back to the style system to invalidate everything doesn't 
seem trivial / worth the effort. It seems pretty hard actually.


In particular, right now we don't re-parse stylesheets when you toggle 
prefs for example (you need to reload or such). But the properties keep 
working. In this case the feature would stop working completely, while 
you have declarations on the page that set it and can read it via 
`cssText` (not via CSSOM anymore though, presumably), and existing 
@supports rules would keep matching true.


 -- Emilio


With regard to limiting the filters available for backdrop-filter, I was
trying to say that we would need to make sure that support is added to
WebRender for all currently unsupported filters. I do not think it would
be a good idea to ship backdrop-filter with only a subset of filters working.
Currently, the filter property will fallback to the software renderer if an
unsupported filter is encountered, this isn't an option for backdrop-filter if
it is not implemented in the other backends.

-Connor
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to experiment: infer aspect-ratio from width and height attributes in images

[Emilio Cobos Álvarez]

Hi,

In bug 1547231 I've landed a change to how we determine the intrinsic 
aspect ratio of an image so that it's used from the width and height 
attributes, even if the width and height are overridden via CSS.


This means that we can get a proper intrinsic size while the image is 
loading, for example, instead of giving it a 0x0 size, which avoids 
layout instability.


This change is enabled on nightly and early-beta, with the hope of 
proving it's web-compatible.


See the following for related discussion:

 * https://github.com/WICG/intrinsicsize-attribute/issues/16
 * https://github.com/WICG/intrinsicsize-attribute/issues/4
 * https://github.com/mozilla/standards-positions/issues/129

Note that, as implemented, the mapped aspect ratio trumps the actual 
image aspect-ratio, but this can probably be changed if it breaks 
content as discussed in the issues above.


Anyhow, let me know / file bugs if you see broken stuff :)

 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Ship: @supports selector()

[Emilio Cobos Álvarez]

Err, sorry, forgot to link to the bug:

  https://bugzilla.mozilla.org/show_bug.cgi?id=1513643

 -- Emilio

On 6/27/19 12:31 AM, Emilio Cobos Álvarez wrote:

I plan to turn on @supports selector() function for all release channels.

See the following link for the intent to implement and relevant discussion:


https://groups.google.com/d/msg/mozilla.dev.platform/JNLPcIZRd2w/r6Boq0h2BQAJ 



There are various WPT tests for this in css/css-conditional and 
css/cssom. Spec lives at:


   https://drafts.csswg.org/css-conditional-4/#at-supports-ext

The CSSWG discussed this F2F at the beginning of June, and was fine with 
shipping this. Spec-wise conditional-4 and conditional-3 should be 
merged and such as discussed in:


  https://log.csswg.org/irc.w3.org/css/2019-06-07/#e1190776

I'll get to that. But I don't see a reason for not doing this.

I filed bugs on other engines:

  * https://bugs.webkit.org/show_bug.cgi?id=199237
  * https://bugs.chromium.org/p/chromium/issues/detail?id=979041

  -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Ship: @supports selector()

[Emilio Cobos Álvarez]

I plan to turn on @supports selector() function for all release channels.

See the following link for the intent to implement and relevant discussion:


https://groups.google.com/d/msg/mozilla.dev.platform/JNLPcIZRd2w/r6Boq0h2BQAJ

There are various WPT tests for this in css/css-conditional and 
css/cssom. Spec lives at:


  https://drafts.csswg.org/css-conditional-4/#at-supports-ext

The CSSWG discussed this F2F at the beginning of June, and was fine with 
shipping this. Spec-wise conditional-4 and conditional-3 should be 
merged and such as discussed in:


 https://log.csswg.org/irc.w3.org/css/2019-06-07/#e1190776

I'll get to that. But I don't see a reason for not doing this.

I filed bugs on other engines:

 * https://bugs.webkit.org/show_bug.cgi?id=199237
 * https://bugs.chromium.org/p/chromium/issues/detail?id=979041

 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Unprefix -moz-user-select, unship mozilla-specific values.

[Emilio Cobos Álvarez]

Just as a PSA, I did a bunch of work a while ago to align better with 
other UAs, and the Gecko-specific values are gone as a result of that work.


The CSSWG resolved in our behavior regarding `auto` in:

  https://github.com/w3c/csswg-drafts/issues/3344

So I plan to land the changes in 69 now that the soft-freeze is over.

 -- Emilio

On 11/11/2018 18:57, Emilio Cobos Álvarez wrote:
Summary: Unprefix the -moz-user-select property, so that it works 
without the -moz- prefix.


We happen to be supporting the -webkit- prefixed version of the 
property, but other browsers support it also unprefixed, which causes a 
lot of confusion.


As part of this work I'm also unshipping the following values from 
content (or entirely, if they have no internal usage):


  * -moz-all: Was meant to behave as an alias of `all`, but in practice 
that's not true. Plus all external usage I found was followed by a 
-webkit-user-select: all which would override it.


  * -moz-text: It's an internal value which was introduced in bug 
1181130. It's only used from contenteditable.css and I haven't 
investigated removing it completely, but I'm restricting it to 
user-agent stylesheets. I found no relevant external usage.


  * tri-state, element, elements, toggle: We parse these but do nothing 
with them (lol, I know, right?). They're no longer in the spec so should 
be removed.


We also have a non-standard '-moz-none' alias to 'none' which I haven't 
investigated removing yet, but probably should in a followup to this bug.


Bug: 1492958 for the removal of non-standard values, 1492739 for the 
unprefixing.


Link to standard: https://drafts.csswg.org/css-ui-4/#propdef-user-select

Platform coverage: All

Estimated or target release: FF65

Preference behind which this will be implemented: None

Is this feature enabled by default in sandboxed iframes? Yes

DevTools bug: N/A

Do other browser engines implement this?

This is an interesting question. The current status is:

  * Blink supports user-select unprefixed and -webkit- prefixed, with 
the same values we'd support after this bug (except our non-standard 
-moz-none alias).


  * Edge supports the -ms- prefixed version of the property, and the 
-webkit- prefixed version. Edge is the only engine to support the 
'contain' value.


  * WebKit only supports the -webkit- prefixed version.

So all browsers support as of today the -webkit- prefixed version of the 
property, which is a fun state of affairs, with a slightly different set 
of values.


I think we should try to unprefix sooner than later so this doesn't end 
up being something similar to '-webkit-apperance'. Given Chrome supports 
the same thing as us unprefixed, I think it's reasonable to do this.


web-platform-tests: Test coverage for all the values is pre-existing. 
There's unfortunately little coverage in WPT, but a lot in our selection 
and contenteditable tests.


Is this feature restricted to secure contexts? No, as this is merely 
unprefixing an existing property.


Thoughts?

  -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Implement and Ship: CSSStyleSheet.rules, CSSStyleSheet.removeRule, CSSStyleSheet.addRule

[Emilio Cobos Álvarez]

Summary: Implement and spec some non-standard CSSOM APIs to converge 
with every other browser, since they're unlikely to ever remove their 
implementations and the lack of them causes compat issues for us, see 
the bug, the CSSWG issue [1] and everything cross-linked from there.


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1545823

Link to standard: https://github.com/w3c/csswg-drafts/pull/3900

Platform coverage: All

Estimated or target release: 68

Preference behind which this will be implemented: None

Is this feature enabled by default in sandboxed iframes? Yes

DevTools bug: N/A

Do other browser engines implement this? Yes, all of them, since 
basically forever (see https://github.com/whatwg/compat/issues/98).


Only know difference is that Blink and my implementation returns a live 
object for CSSStyleSheet.rules, while WebKit returns a static list of 
rules. I've filed a bug on WebKit to consider simplifying their code and 
making this just an alias to converge: https://webkit.org/b/197725.


web-platform-tests: Added as part of the implementation.

Is this feature restricted to secure contexts? No, it's a legacy API, 
mostly aliases of already-non-restricted APIs.


As always, let me know if you think there's any concerns with proceeding.

 -- Emilio

[1]: https://github.com/w3c/csswg-drafts/issues/3814
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Implement and Ship: , reflected by HTMLLinkElement.disabled

[Emilio Cobos Álvarez]

Summary: Make the disabled attribute on link elements do something
useful, and the disabled IDL attribute reflect this attribute instead of
forwarding to the style sheet object (if present). This is mostly compat
work, but should also do less work in pages that use it already. See
below for the long story.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1281135

Link to standard: https://github.com/whatwg/html/pull/4519

There are two parts of this proposal. One is "implementing the disabled
attribute". That's what that HTML spec PR is about. The other is about
changing the behavior of HTMLLinkElement.disabled, which we do
implement, to reflect the content attribute. This used to be spec'd like
what Gecko does, but was removed from the spec. New thing matches WebKit
/ Blink. See the "Do other browser engines implement this?" for all
details you may want to know (and probably more) about this situation.

Platform coverage: All

Estimated or target release: 68

Preference behind which this will be implemented:
dom.link.disabled_attribute.enabled

Is this feature enabled by default in sandboxed iframes? Yes

DevTools bug: I don't think it's needed, but please file if you think
otherwise.

Do other browser engines implement this?

All other engines implement the disabled attribute in one way or
another. See below for the details of what WebKit and Blink do. Edge
looks like they implemented the `disabled` attribute as a "default value
for the stylesheet disabled flag" kind of thing. That has the downside
of still downloading the stylesheet in a case where WebKit and Blink
don't right now, and thus I don't think WebKit or Blink would be
interested in switching to such a model.

Regarding HTMLLinkElement.disabled, also all engines implement it, with
two different behaviors right now:

 * Gecko (before my patch) and Edge implement the old spec for this,
where it forwards to the stylesheet's disabled flag.
 * Blink / WebKit implement it as reflecting the disabled attribute (I'm
not aware of any spec reference, historical or not, for this behavior,
but I'd be interested in knowing about it).

Now the long story, which is mostly in [1]. The TL;DR: is written in
[2], and that contains the proposed behavior that my change implements.
Feel free to skip to the "web-platform-tests" section below if you're
not interested on the details.

Blink and WebKit implement the `disabled` attribute on stylesheets, and
it's the only way to enable alternate stylesheets there. There's no spec
for that of course, and the behavior of this attribute in those engines
is quite bizarre (see [1] for reference).

Separately, there's the HTMLLinkElement.disabled setter and getters,
which were removed from the spec, but that everyone still implements
(and I'm pretty sure it'd not be compatible to remove it).

Spec-wise, the spec says that alternate stylesheets are supposed to be
implemented using the disabled flag on the stylesheet [3]. Edge and
Gecko do that, and make HTMLLinkElement.disabled forward to the stylesheet.

In WebKit / Blink, this is not the case. An alternate stylesheet is not
disabled (as in `link.sheet` is non-null, `link.sheet.disabled` returns
false, but still magically does not apply to the page). The only way to
enable such an stylesheet in Blink and WebKit is removing the `disabled`
attribute on the link.

This means that the only way to have a cross-browser alternate
stylesheet is:

  

And the cross-browser way to enable is using `link.disabled`:

 * In Gecko and Edge, that setter will forward to the stylesheet, object
(it's the same as saying `if (link.sheet) link.sheet.disabled = false;`.
And given they implement alternate sheets according to the standard,
then it'd enable the already loaded and parsed stylesheet.

 * In Blink and WebKit, this will remove the disabled attribute, which
will load the stylesheet, and set a magic "explicitly enabled" bit that
will make the stylesheet apply when it loads.

Separately, some websites are starting to use:

  

And it's a common cause of confusion when people find that it doesn't
work on Firefox. The disabled attribute on its own does nothing in Gecko
and thus we apply the stylesheet when other browsers don't, and thus the
website breaks.

This is all quite sad and bizarre, and other that this move I don't see
many other paths forwards to achieve interop in all this mess. Blink and
WebKit could probably fix their alternate stylesheet implementation to
properly use the disabled flag, but given their use counters [4][5]
they'll probably not remove the disabled attribute regardless. Also,
they have other incentives to keep the disabled attribute, like the fact
that  for them it's a performance boost (they don't have to download and
parse potentially large stylesheets).

So my proposed model aligns with WebKit and Blink as much as possible
without implementing obvious bugs. The disabled attribute also causes
the stylesheet to not be present / loaded at all. This makes sense, and

Re: To what extent is sccache's distributed compilation usable?

[Emilio Cobos Álvarez]

On 01/04/2019 21:40, Bobby Holley wrote:
> My (possibly outdated) understanding is that the sccache distributed
> compilation stuff is restricted to the build machines we control. Naively,
> I'm not sure there's a secure way to have machines in the wild contribute
> build artifacts, given the risk of malicious code.
> 
> It seems plausible that we could at least allow read-only access to the
> artifacts generated by the build machines, but that would presumably only
> be useful if the developer's system configuration exactly matched that of
> the build machine.

Oh, the setup I was thinking of would be similar to how icecc works now,
on a local network. So, for example, N developers in the Berlin office
sharing a scheduler and build resources in the same network.

I'm not 100% sure whether the distributed compilation part of sccache is
only about sharing compilation artifacts, or also compiling stuff in
remote machines (like icecc does), or both, but afaik even in a local
network it could still be a pretty nice build-time / productivity
improvement.

 -- Emilio

> On Mon, Apr 1, 2019 at 12:23 PM Emilio Cobos Álvarez 
> wrote:
> 
>> Hi,
>>
>> Over in #layout people were ranting about how much of a pain it was to
>> set up icecc on MacOS. I pointed out that sccache in theory does support
>> distributed compilation[1] and in theory also supports MacOS clients.
>>
>> Does anybody know to what extent is it in a usable state? Can it replace
>> icecc? I'm a Linux user, and icecc works pretty well, but if sccache
>> supports Rust as well that's a huge plus.
>>
>> Are people encouraged to try it out? Or only experimentally? Or should
>> we wait?
>>
>> I know Ted encouraged me to try it in Berlin, and I still have to do
>> that (d'oh :/). So given that I suspect the answer is "it's worth trying
>> out and report bugs". But worth knowing if it's more generally usable or
>> mostly experimental.
>>
>> Thanks,
>>
>>  -- Emilio
>>
>> [1]:
>>
>> https://github.com/mozilla/sccache/blob/master/docs/DistributedQuickstart.md
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

To what extent is sccache's distributed compilation usable?

[Emilio Cobos Álvarez]

Hi,

Over in #layout people were ranting about how much of a pain it was to
set up icecc on MacOS. I pointed out that sccache in theory does support
distributed compilation[1] and in theory also supports MacOS clients.

Does anybody know to what extent is it in a usable state? Can it replace
icecc? I'm a Linux user, and icecc works pretty well, but if sccache
supports Rust as well that's a huge plus.

Are people encouraged to try it out? Or only experimentally? Or should
we wait?

I know Ted encouraged me to try it in Berlin, and I still have to do
that (d'oh :/). So given that I suspect the answer is "it's worth trying
out and report bugs". But worth knowing if it's more generally usable or
mostly experimental.

Thanks,

 -- Emilio

[1]:
https://github.com/mozilla/sccache/blob/master/docs/DistributedQuickstart.md
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Unship: -moz-block-height value for line-height

[Emilio Cobos Álvarez]

Hi,

In bug 1536871, where I'm sorting out various interop issues related to
line-height (intents for those coming probably in a couple weeks when
issues with the CSSWG and other implementors are sorted out) I plan to
make the -moz-block-height value of the line-height property not
available to content.

The -moz-block-height value makes the line-height the height of the
containing block (except when it's auto / unresolved, in which case it
behaves like normal).

It's an internal value used for some internal elements in form controls,
and it's fairly undertested for the general case. As such, I don't think
it has a reason to be exposed to content.

The risk of this removal causing issues is fairly small (specially since
we don't expose the -moz-block-height value in the computed style, we
return the resolved value), but I've implemented it under the
"layout.css.line-height-moz-block-height.content.enabled" just to be on
the safe side.

Let me know or comment in the bug if there's any concern with doing this.

Cheers,

 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: built-in CSS counter 'list-item'

[Emilio Cobos Álvarez]

On 25/03/2019 06:21, Domenic Denicola wrote:
> Some time ago we spent some effort documenting a cross-browser 
> mostly-interoperable behavior for list-item-like behaviors, in 
> https://github.com/whatwg/html/pull/2002 and linked threads. The result is 
> the spec at 
> https://html.spec.whatwg.org/multipage/grouping-content.html#list-owner and 
> the tests at 
> https://github.com/web-platform-tests/wpt/tree/master/html/semantics/grouping-content/the-ol-element
>  .
> 
> The spec at https://drafts.csswg.org/css-lists/#declaring-a-list-item seems 
> to contradict that hard-fought consensus. It states simply that
> 
>> Additionally, list items automatically increment the special list-item 
>> counter. Unless the counter-increment property manually specifies a 
>> different increment for the list-item counter, it must be incremented by 1 
>> on every list item, at the same time that counters are normally incremented.
> 
> This omits all the details at 
> https://html.spec.whatwg.org/multipage/grouping-content.html#ordinal-value , 
> e.g. reversed="", the collection of owned list items, value="" attribute 
> parsing, etc.
> 
> It seems like a regression to implement list item numbering according to that 
> spec, instead of according to HTML.

FWIW, the check-in fixing this[1] fixed multiple WPT tests related to
this, and regressed none, see the .ini file changes.

>> web-platform-tests: 
> 
> An important thing to test here is the result of getComputedStyle on list 
> items as a result of this change. HTML specifies that ordinal values are 
> displayed on list items without any counter CSS properties involved, and from 
> what I can tell, https://drafts.csswg.org/css-lists/ does not change that. 
> (The appendix at https://drafts.csswg.org/css-lists/#ua-stylesheet is 
> informative, not normative.) So, including tests that getComputedStyle 
> continues to return no results for the counter-related properties or 
> pseudo-elements seems important to maintaining interop on this front.

I agree that testing this seems useful, but I disagree on it being
ignored in computed style serialization of all counter-* properties,
that feels rather magical.

I agree that the counter-increment should be ignored in computed style
serialization (I filed
https://bugzilla.mozilla.org/show_bug.cgi?id=1539171 to fix that).

Note that  attribute parsing hasn't changed, and it's just
a mapped attribute mapping to counter-set. I don't think this conflicts
with the HTML spec, and I think that we should keep 
serializing counter-set in getComputedStyle. I don't think there are
interop concerns for counter-set since counter-set is not implemented in
other engines, but attribute mapping is straight-forward and works
similarly everywhere.

 -- Emilio

[1]: https://hg.mozilla.org/mozilla-central/rev/ae4e4daebdc4

> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: Some Shadow DOM v0 APIs

[Emilio Cobos Álvarez]

Hi,

In bug 1535438 I intend to remove three Shadow DOM v0 APIs that slipped
through when we shipped Shadow DOM v1:

 * ShadowRoot.getElementsByTagName
 * ShadowRoot.getElementsByTagNameNS
 * ShadowRoot.getElementsByClassName

These were implemented in bug 806506 as part of the initial Shadow DOM
v0 implementation by William Chen, and they remained there as we updated
to v1, looks like :)

No other browser is shipping these, so the earlier we remove it the
better, but let me know if you disagree.

The code implementing them remains untouched, since it's the same for
ShadowRoot and Document, so resurrecting them should we need that would
be trivial.

 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Ship: Ignore custom cursors over 32 pixels intersecting UI

[Emilio Cobos Álvarez]

On 13/03/2019 01:46, flor...@rivoal.net wrote:
> On Wednesday, March 13, 2019 at 8:36:17 AM UTC+9, Emilio Cobos Álvarez wrote:
>> On 13/03/2019 00:22, Florian Rivoal wrote:
>>> Given that this is not merely setting a limit because you find that 
>>> implementation more convenient, but actually a case of considering it 
>>> desirable to ignore large cursors in certain cases (and for security 
>>> reasons even), I wonder if this is something that we should consider 
>>> including in the specification. What do you tink?
>>
>> I think a note or such in the spec would be nice, yeah. FWIW some
>> platforms already had pre-existing cursor limits for similar reasons[1]
>> since forever.
>>
>> I probably wouldn't bother specifying a concrete limit, though not sure
>> how you feel about that. Seems like depending how big the browser's UI
>> is, a browser could make different tradeoffs without compromising security.
> 
> Could you raise it to the CSSWG, and we can see there what's appropriate, 
> taking into account what others browsers do?

Filed https://github.com/w3c/csswg-drafts/issues/3728. Thanks!

 -- Emilio

> Thanks,
> —Florian
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Ship: Ignore custom cursors over 32 pixels intersecting UI

[Emilio Cobos Álvarez]

On 13/03/2019 00:22, flor...@rivoal.net wrote:
> Given that this is not merely setting a limit because you find that 
> implementation more convenient, but actually a case of considering it 
> desirable to ignore large cursors in certain cases (and for security reasons 
> even), I wonder if this is something that we should consider including in the 
> specification. What do you tink?

I think a note or such in the spec would be nice, yeah. FWIW some
platforms already had pre-existing cursor limits for similar reasons[1]
since forever.

I probably wouldn't bother specifying a concrete limit, though not sure
how you feel about that. Seems like depending how big the browser's UI
is, a browser could make different tradeoffs without compromising security.

 -- Emilio

[1]:
https://searchfox.org/mozilla-central/rev/89414a1df52d06cfc35529afb9a5a8542a6e4270/widget/gtk/nsWindow.cpp#1465

> —Florian
> 
> On Wednesday, March 13, 2019 at 4:50:01 AM UTC+9, Emilio Cobos Álvarez wrote:
>> Hi, just some email I forgot to send a while ago.
>>
>> Summary: Block cursor images larger than 32 pixels wide that intersect
>> the Browser UI, by falling back to the default cursor (as if no cursor
>> image could be loaded).
>>
>> This prevents malware sites from hijacking the cursor and look as if the
>> cursor was on top of the browser UI. See the bug for test-cases and
>> examples.
>>
>> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1445844
>>
>> Link to standard: N/A (this is more of an intervention)
>>
>> Platform coverage: All desktop platforms.
>>
>> Estimated target release: 67
>>
>> Preference behind which this will be implemented: Two prefs control this
>> behavior. `layout.cursor.block.enabled` controls whether we block
>> cursors at all. `layout.cursor.block.max-size` controls the maximum size
>> in either axis that the cursor can have without being blocked.
>>
>> Devtools bug: I don't think any particular devtools support is needed.
>>
>> web-platform-tests: Can't really test this.
>>
>> Do other browser engines implement this? Blink is doing the same change
>> in https://bugs.chromium.org/p/chromium/issues/detail?id=880863.
>>
>> Their data estimates that 0.1% of page visits hit this, and they're
>> going with the same cursor size of 32 (I was going initially for 64, see
>> bug for discussion).
>>
>> I made sure that should any surprise come up turning this off this is
>> trivial, but I think it's worth doing, and the change has been in
>> Nightly for quite a while without any surprise.
>>
>>  -- Emilio
> 
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Ship: Ignore custom cursors over 32 pixels intersecting UI

[Emilio Cobos Álvarez]

Hi, just some email I forgot to send a while ago.

Summary: Block cursor images larger than 32 pixels wide that intersect
the Browser UI, by falling back to the default cursor (as if no cursor
image could be loaded).

This prevents malware sites from hijacking the cursor and look as if the
cursor was on top of the browser UI. See the bug for test-cases and
examples.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1445844

Link to standard: N/A (this is more of an intervention)

Platform coverage: All desktop platforms.

Estimated target release: 67

Preference behind which this will be implemented: Two prefs control this
behavior. `layout.cursor.block.enabled` controls whether we block
cursors at all. `layout.cursor.block.max-size` controls the maximum size
in either axis that the cursor can have without being blocked.

Devtools bug: I don't think any particular devtools support is needed.

web-platform-tests: Can't really test this.

Do other browser engines implement this? Blink is doing the same change
in https://bugs.chromium.org/p/chromium/issues/detail?id=880863.

Their data estimates that 0.1% of page visits hit this, and they're
going with the same cursor size of 32 (I was going initially for 64, see
bug for discussion).

I made sure that should any surprise come up turning this off this is
trivial, but I think it's worth doing, and the change has been in
Nightly for quite a while without any surprise.

 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Implement and Ship: CSS revert keyword.

[Emilio Cobos Álvarez]

Summary: The CSS `revert` wide-keyword allows authors to ignore all CSS
rules in a given cascade origin[1], while applying rules from other
cascade origins. Trivial example would be:


div {
  display: inline;
}

// somewhere further down...
div {
  display: revert; /* Goes back to display: block */
}


Authors already have the `unset`, `initial` and `inherit` wide-keywords.
Unfortunately, none of them would turn the  to its "default" style
(display: block), since that rule is in a user-agent stylesheet that
would be overridden by the declaration. `revert` allows authors to do that.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1215878

Spec: https://drafts.csswg.org/css-cascade/#default

Platforms: all

Estimated or target release: 67

Preference behind which this will be implemented: None, the
css-wide-keyword parsing code is hot, and I don't think there's a way
for this to backfire. But happy to add one if wanted I guess.

Is this feature enabled by default in sandboxed iframes?: Yes

DevTools bug: Devtools autocompletion would work the same way it works
for other wide keywords, so I don't think any special devtools
integration is needed.

Do other browser engines implement this?
Safari has shipped this for quite a while (9.1 on desktop, 9.3 on
mobile, according to MDN[2]). No other engine implements this, however.
Relevant crbug for Blink is [3].

web-platform-tests: There's a very basic WPT test for revert's
functionality. It's not that complex of a (user-facing, at least)
functionality to begin with. It's a bit hard to test much further than
that because you depend on which particular declarations are on the UA
stylesheet (I used the internal property_database.js to test it using a
mochitest).

Any bugfixes or such that I need to do will be added to WPT if possible.

Is this feature restricted to secure contexts? No, like other CSS syntax
features.


 -- Emilio

[1]: https://drafts.csswg.org/css-cascade/#cascade-origins
[2]: https://developer.mozilla.org/en-US/docs/Web/CSS/revert
[3]: https://bugs.chromium.org/p/chromium/issues/detail?id=579788
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Min clang / libclang requirement was updated not long ago...

[Emilio Cobos Álvarez]

I don't think so, but it should. This changed a couple weeks ago[1], and
only somebody which had a bunch of old clang installations has complained.

I'll file a bug to add this check.

 -- Emilio

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1394825

On 2/26/19 10:00 AM, David Major wrote:
> Does configure warn about this?
> 
> The link between this error and needing to bootstrap is not super
> clear (and a surprising number of people don't read dev-platform) so
> I'm not looking forward to answering the same question in #build for
> the rest of the week. :)
> 
> On Tue, Feb 26, 2019 at 12:23 PM Emilio Cobos Álvarez  
> wrote:
>>
>> ... so if you don't use the mozilla-provided libclang (or are using a
>> very old one), and you see an error like:
>>
>>> error[E0277]: the trait bound
>> `values::generics::rect::Rect> f32>>:
>> std::convert::From,
>>
>> Please re-run mach bootstrap, or update your libclang.
>>
>> Thanks!
>>
>>  -- Emilio
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: Min clang / libclang requirement was updated not long ago...

[Emilio Cobos Álvarez]

... so if you don't use the mozilla-provided libclang (or are using a
very old one), and you see an error like:

> error[E0277]: the trait bound
`values::generics::rect::Rect>:
std::convert::From,

Please re-run mach bootstrap, or update your libclang.

Thanks!

 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform