Re: Intent to ship: CSS subgrid

[Tantek Çelik]

Agreed with clarification. Declarative text/css stylesheets not
restricted. Imperative new APIs (like Houdini APIs) should be
restricted to secure contexts by default. Thanks, Tantek

On Fri, Oct 18, 2019 at 4:53 PM Daniel Veditz  wrote:
>
> On Fri, Oct 18, 2019 at 4:27 PM Tantek Çelik  wrote:
>>
>> Based on your reasoning, and our consistent intent emails and shipping
>> behavior, I think we should consider updating the blog post on this
>> matter regarding all CSS features (cc: annevk), or posting a separate
>> update post accordingly, using the reasoning you've provided as our
>> guidance.
>
>
> Just to be clear I was not talking about "all" CSS features but mainly the 
> ones specified in text/css stylesheets. New CSS features that are implemented 
> through JavaScript APIs (like CSS Painting API) ought to be restricted, and 
> exemptions should require an explicit compelling argument. Browsers have 
> already invented mechanisms to expose properties conditionally so it's not an 
> implementation burden, and it's possible for web developers to do feature 
> detection and deal with it. The calculus comes out differently.
>
> [I note the CSS Painting API spec doesn't mention such restrictions 
> currently, but Chrome's implementation seems to have done so anyway.]
>
> -Dan Veditz
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS subgrid

[Daniel Veditz]

On Fri, Oct 18, 2019 at 4:27 PM Tantek Çelik  wrote:

> Based on your reasoning, and our consistent intent emails and shipping
> behavior, I think we should consider updating the blog post on this
> matter regarding all CSS features (cc: annevk), or posting a separate
> update post accordingly, using the reasoning you've provided as our
> guidance.


Just to be clear I was not talking about "all" CSS features but mainly the
ones specified in text/css stylesheets. New CSS features that are
implemented through JavaScript APIs (like CSS Painting API) ought to be
restricted, and exemptions should require an explicit compelling argument.
Browsers have already invented mechanisms to expose properties
conditionally so it's not an implementation burden, and it's possible for
web developers to do feature detection and deal with it. The calculus comes
out differently.

[I note the CSS Painting API spec doesn't mention such restrictions
currently, but Chrome's implementation seems to have done so anyway.]

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

Re: Intent to ship: CSS subgrid

[Tantek Çelik]

Thanks Dan. I concur with the priorities, impacts, and conclusions
you've outlined.

In practice I believe 100% of the CSS features we have shipped (Intent
to Implement/Ship emails) in the past year+ have been exposed to
insecure contexts.

Based on your reasoning, and our consistent intent emails and shipping
behavior, I think we should consider updating the blog post on this
matter regarding all CSS features (cc: annevk), or posting a separate
update post accordingly, using the reasoning you've provided as our
guidance. I'd prefer the former as many have linked to that blog post.

Thanks,
Tantek




On Fri, Oct 18, 2019 at 10:32 AM Daniel Veditz  wrote:
>
> From my (personal) security-team perspective this is a fine pragmatic
> approach. Our overriding primary concern is whether exposing these new CSS
> features over insecure transport puts our users at additional risk. I don't
> see any meaningful privacy exposure here since these new features will be
> in a stylesheet that's already insecure, and style doesn't typically
> contain user data. There will be additional "attack surface" of course
> (more features ~= more bugs) but it's trivially easy for an attacker to use
> a secure stylesheet instead if that's required to access a buggy feature.
>
> Coercing site authors into better behavior is a secondary concern (user
> safety, once removed), and some amount of pragmatism is acceptable. These
> features are being standardized through the W3C, and given W3C statements
> about the importance of  switching the web to secure transport we should
> give those standards bodies a chance to do the appropriate thing. Web
> compatibility with other browsers is important given Mozilla's market
> share, and while we can take a stand against compatibility (and have) when
> there's demonstrable user harm from a feature, these incremental additions
> to CSS don't appear to come anywhere close to that bar.
>
> -Dan Veditz
> ___
> 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: PSA: Android test environments

[Bobby Holley]

This is a great summary, and reflects a ton of hard work over the past year
to improve our mobile testing story and reduce our CI spend. Thanks gbrown
and everyone else who helped make it happen!

On Fri, Oct 18, 2019 at 11:52 AM Geoffrey Brown  wrote:

> The Android test environments used for continuous integration have been
> through many changes over the last year or two; here's a review of what we
> have today. [1]
>
> Most of our Android tests run on emulators. Some run on hardware: real
> phones.
>
> Our Android hardware tests run on physical devices -- Motorola G5 and Pixel
> 2 phones currently -- and those phones are physically managed by bitbar, a
> device farm provider. These test platforms appear on treeherder as "Android
> 7.0 MotoG5" and "Android 8.0 Pixel2".  Running tests on hardware is
> relatively expensive so we make deliberate choices about which tests run on
> hardware. All of our performance (raptor) tests, architecture-sensitive
> tests like jittest and jsreftest, and select tests requiring special
> capabilities run on hardware.
>
> All other tests -- web-platform tests, most mochitests, reftests, xpcshell
> tests, etc -- run on emulators. The emulator test platform appears on
> treeherder as "Android 7.0 x86-64". These tests run in the Android x86_64
> emulator on a Linux host. Unlike previous generations of our emulator test
> environment, today's emulator tests are fast: Thanks to hardware
> acceleration, tests run at about the same rate as they do on our desktop
> platforms.
>
> The Android tests running on trunk today are testing geckoview apps (Fennec
> tests continue to run on the esr68 branch). Most raptor tests run in the
> geckoview_example app; additional raptor tests run in Fenix and the
> Reference Browser; most other tests run in the geckoview test app.
>
> Both emulator and hardware tests have a fixed pool of instances: Regardless
> of load, we can only run N emulator tasks, or M hardware tasks at a time.
> Release Engineering Operations monitors backlog for both pools, but
> temporary backlogs are expected and tolerated.
>
> Since our hardware testing capacity is particularly limited, to run Android
> hardware tests on try, you must use the --full option with 'mach try fuzzy'
> [2]. For instance, you can see the available tests with 'mach try fuzzy
> --no-push --full --query "android-hw"' and you could run android-hw
> mochitest-media tests with 'mach try fuzzy --full --query "android-hw
> mochitest-media"'.
>
> There are no similar restrictions on try runs for emulator tests -- but
> please use responsibly!
>
>
> [1]
>
> https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&searchStr=android%2Ctest
> [2] https://firefox-source-docs.mozilla.org/tools/try/selectors/fuzzy.html
> ___
> 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: Android test environments

[Geoffrey Brown]

The Android test environments used for continuous integration have been
through many changes over the last year or two; here's a review of what we
have today. [1]

Most of our Android tests run on emulators. Some run on hardware: real
phones.

Our Android hardware tests run on physical devices -- Motorola G5 and Pixel
2 phones currently -- and those phones are physically managed by bitbar, a
device farm provider. These test platforms appear on treeherder as "Android
7.0 MotoG5" and "Android 8.0 Pixel2".  Running tests on hardware is
relatively expensive so we make deliberate choices about which tests run on
hardware. All of our performance (raptor) tests, architecture-sensitive
tests like jittest and jsreftest, and select tests requiring special
capabilities run on hardware.

All other tests -- web-platform tests, most mochitests, reftests, xpcshell
tests, etc -- run on emulators. The emulator test platform appears on
treeherder as "Android 7.0 x86-64". These tests run in the Android x86_64
emulator on a Linux host. Unlike previous generations of our emulator test
environment, today's emulator tests are fast: Thanks to hardware
acceleration, tests run at about the same rate as they do on our desktop
platforms.

The Android tests running on trunk today are testing geckoview apps (Fennec
tests continue to run on the esr68 branch). Most raptor tests run in the
geckoview_example app; additional raptor tests run in Fenix and the
Reference Browser; most other tests run in the geckoview test app.

Both emulator and hardware tests have a fixed pool of instances: Regardless
of load, we can only run N emulator tasks, or M hardware tasks at a time.
Release Engineering Operations monitors backlog for both pools, but
temporary backlogs are expected and tolerated.

Since our hardware testing capacity is particularly limited, to run Android
hardware tests on try, you must use the --full option with 'mach try fuzzy'
[2]. For instance, you can see the available tests with 'mach try fuzzy
--no-push --full --query "android-hw"' and you could run android-hw
mochitest-media tests with 'mach try fuzzy --full --query "android-hw
mochitest-media"'.

There are no similar restrictions on try runs for emulator tests -- but
please use responsibly!


[1]
https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&searchStr=android%2Ctest
[2] https://firefox-source-docs.mozilla.org/tools/try/selectors/fuzzy.html
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS subgrid

[Daniel Veditz]

>From my (personal) security-team perspective this is a fine pragmatic
approach. Our overriding primary concern is whether exposing these new CSS
features over insecure transport puts our users at additional risk. I don't
see any meaningful privacy exposure here since these new features will be
in a stylesheet that's already insecure, and style doesn't typically
contain user data. There will be additional "attack surface" of course
(more features ~= more bugs) but it's trivially easy for an attacker to use
a secure stylesheet instead if that's required to access a buggy feature.

Coercing site authors into better behavior is a secondary concern (user
safety, once removed), and some amount of pragmatism is acceptable. These
features are being standardized through the W3C, and given W3C statements
about the importance of  switching the web to secure transport we should
give those standards bodies a chance to do the appropriate thing. Web
compatibility with other browsers is important given Mozilla's market
share, and while we can take a stand against compatibility (and have) when
there's demonstrable user harm from a feature, these incremental additions
to CSS don't appear to come anywhere close to that bar.

-Dan Veditz
___
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?

[Chris Harrelson]

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.

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 discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-DPW4tXA_R-c0WAj76Qtj4TYdjwHai3odyNdWYVfJhZA%40mail.gmail.com
> 
> .
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to prototype: JavaScript weak references

[Jonathan Coppeard]

Summary:

This feature allows developers to create weak references to JavaScript objects. 
 Finalizers are also provided that allow developers to perform actions when an 
object is garbage collected, without keeping that object alive.

This is an advanced feature that is not expected to be widely used but is 
necessary for some use important use cases such as exposing WebAssembly memory 
to JavaScript.

Bug:

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

Standard:

Proposal: https://github.com/tc39/proposal-weakrefs
JS spec changes: https://tc39.es/proposal-weakrefs/
HTML spec changes: https://github.com/whatwg/html/pull/4571

The proposal is at stage 3.

Platform coverage:

This is a new JavaScript language feature and will be available in all contexts.

Preference:

This feature will be controlled by the javascript.options.weakrefs pref, which 
will be off by default.

DevTools bug:

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

Other browsers:

  Chrome: implemented behind a flag
  Safari: believed to have an implementation

web-platform-tests:

There are test262 tests covering this feature:

https://github.com/tc39/test262/tree/master/test/built-ins/WeakRef
https://github.com/tc39/test262/tree/master/test/built-ins/FinalizationGroup

Web platform tests will be added in the following bug:

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

Secure contexts: 

This is a JS language feature and is thus present in all contexts where scripts 
are executed.

Is this feature enabled by default in sandboxed iframes? If not, is there a 
proposed sandbox flag to enable it? If allowed, does it preserve the current 
invariants in terms of what sandboxed iframes can do?

Where enabled, this feature will be allowed by default in sandboxed iframes. It 
does not change the invariants in terms of what sandboxed iframes can do.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nsIPermissionManager Permission Isolation by OriginAttributes

[pzuhlcke]

On Thursday, 17 October 2019 15:31:50 UTC+2, Matthew N.  wrote:
> On 2019-10-16 7:15 a.m., Paul Zühlcke wrote:
> > I plan to land a patch next week which will disable OriginAttribute
> > stripping in the permission manager. This will result in private browsing
> > windows and containers having isolated permissions.
> 
> Are we still planning to strip origin attributes before insertion into 
> the permission manager for permissions that have management UI (e.g. in 
> about:preferences)? If not, how do we plan to represent the origins 
> there? I think we wouldn't want to expose the originSuffix directly to 
> our users e.g. something like https://www.facebook.com^userContextId=7 
> when using the Facebook container.
> 
> Thanks,
> Matthew N. (:MattN)

Thanks for bringing this up! I think we should not strip the permissions for 
the preferences UI. Rather than exposing the origin suffix to the user, we need 
custom indicators in the permission list.
I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1589608
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to remove: nsStackFrame aka. `display: -moz-stack` and related features

[Tim Nguyen]

Hi folks,

I’m planning to remove nsStackFrame in bug 1576946 [0]. This is part of a
larger effort to make the browser stop using XUL layouts and align on more
standard CSS layouts such as CSS grid or flexbox instead. The removal is
targeted for Firefox 72.

The removal includes these two non web-exposed features:
- `display: -moz-stack` and the `-moz-stack-sizing` property
- support for XUL absolute positioning attributes
(left/top/bottom/right/start/end XUL attributes), that only worked in
display: -moz-stack contexts

Note that the  element is not going away. It will instead be
implemented using a single-area CSS grid, so those usages won’t need to be
rewritten. However, if you were planning to use XUL absolute positioning
attributes, you’ll need to look into alternatives:
- `align-self: start` or `align-self: end` can be used to position the
element on the vertical axis if you were using `top="0"` or `bottom="0"`
- `justify-self: start` or `justify-self: end` can be used to position the
element on the horizontal axis if you were using `start="0"` or `end="0"`
- If you were using non-zero values in the attributes and the element is
using `display: block;` or a non-XUL block-level display value, you can use
CSS absolute positioning instead.
- If you were using non-zero values in the attributes with a XUL display
value, you can use a combination of `margin` and
`justify-self`/`align-self`, see this code change [1] as a reference.

Regarding `-moz-stack-sizing`, this property was used to determine whether
a certain element would influence the size of its parent. The current
usages in mozilla-central were only used for children of  [2] and
those usages didn’t seem to change visually with the new CSS grid-based
implementation of  which ignores the `-moz-stack-sizing` property,
so it made sense to remove it.

[0]: https://bugzilla.mozilla.org/show_bug.cgi?id=1576946
[1]: https://i.imgur.com/8hUDUDS.png
[2]:
https://searchfox.org/mozilla-central/search?q=-moz-stack-sizing&case=false®exp=false&path=

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