android-em-4-3-armv7-api16 possibly falsy timeout

[violet . bugreport]

Hi,

There are some strange intermittent timeout reports on 
android-em-4-3-armv7-api16 platform, I suspect there is something wrong on this 
test platform.

https://bugzilla.mozilla.org/show_bug.cgi?id=1533737
https://bugzilla.mozilla.org/show_bug.cgi?id=1535286
https://bugzilla.mozilla.org/show_bug.cgi?id=1534079

All of the tests are recently added, they are completely unrelated to each 
other, and there are no other failures on these tests.

But they have one or two intermittent failure on "android-em-4-3-armv7-api16". 
I'm familiar with 2 of the testcases, they are impossible to cause a timeout. 
Especially Bug 1535286 is just a patch to remove a bogus assertion with a 
trivial testcase ``, which literally is impossible to timeout.

Could anyone investigate whether there are some problems on 
"android-em-4-3-armv7-api16" to cause newly added testcase to timeout?

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

Re: Intent to ship: CSS Containment

[Daniel Holbert]

On Mon, Mar 18, 2019 at 12:52 PM Daniel Holbert 
wrote:

> Summary:
>   CSS Containment gives web developers several ways of indicating that a
> subtree isn't influenced by the rest of the page. This may allow UAs to
> perform certain optimizations that they otherwise wouldn't be able to do.
>

Sorry, I slightly mis-stated that.  Closer to the truth:
"CSS Containment gives web developers several ways of indicating that a
subtree *does not influence the rest of the page*"

(The feature's design is mostly focused on preventing side effects from
*leaking out* of a subtree, rather than preventing outside things from
having side effects that leaking into a subtree.)


> Bug:
>   https://bugzilla.mozilla.org/show_bug.cgi?id=1150081
>
> Link to standard:
>   https://drafts.csswg.org/css-contain/
>
> Platform coverage:
>   All platforms
>
> Estimated or target release:
>   Firefox 68
>
> Preference behind which this will be implemented:
>   layout.css.contain.enabled (probably enabled by default in Nightly as of
> tomorrow, March 19)
>
> 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?
>   Enabled by default everyhwere. It has no impact on what sandboxed
> iframes can do -- it's purely a way of constraining sizing/painting
> behavior.
>
> DevTools bug:
>   None at the moment. This feature has subtle effects and I don't know of
> any useful devtools work to be done for it.
>
> Do other browser engines implement this?
>   Chrome (Blink) implements it as of version 52. Their
> intent-to-implement:
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/9W80Kw-z3ss
>
> web-platform-tests:
>  https://wpt.fyi/results/css/css-contain
>
> https://wpt.fyi/results/css/vendor-imports/mozilla/mozilla-central-reftests/contain
>
> Is this feature restricted to secure contexts?
>  No, not currently. Note that Chrome doesn't restrict it, so it could
> conceivably create interop issues if we restricted it without getting them
> to also commit to restricting it.
>
> On Mon, Mar 18, 2019 at 12:39 PM Daniel Holbert 
> wrote:
>
>> Yeah, sorry - our earlier intent-to-implement thread predated our current
>> boilerplate (which includes stuff like test coverage).  And for
>> intent-to-ship, our boilerplate text is pretty minimal.
>>
>> Answering your direct question: yes, there is good web platform test
>> coverage for this feature.  I'll post a followup with answers to our other
>> typical intent-to-implement fields, too.
>>
>> On Mon, Mar 18, 2019 at 12:07 PM James Graham 
>> wrote:
>>
>>> On 18/03/2019 19:01, Daniel Holbert wrote:
>>> > As of today (March 18th 2019), I intend to turn CSS Containment
>>> >  on by default on all
>>> platforms, in
>>> > Firefox Nightly 68. It has been developed behind the
>>> > 'layout.css.contain.enabled' preference.
>>>
>>> Apologies if I've missed it, but I can't see any mention of whether this
>>> feature has — meaningful — cross browser (i.e. wpt) tests in the ItI
>>> thread or here.
>>> ___
>>> 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 Containment

[Daniel Holbert]

Summary:
  CSS Containment gives web developers several ways of indicating that a
subtree isn't influenced by the rest of the page. This may allow UAs to
perform certain optimizations that they otherwise wouldn't be able to do.

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

Link to standard:
  https://drafts.csswg.org/css-contain/

Platform coverage:
  All platforms

Estimated or target release:
  Firefox 68

Preference behind which this will be implemented:
  layout.css.contain.enabled (probably enabled by default in Nightly as of
tomorrow, March 19)

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?
  Enabled by default everyhwere. It has no impact on what sandboxed iframes
can do -- it's purely a way of constraining sizing/painting behavior.

DevTools bug:
  None at the moment. This feature has subtle effects and I don't know of
any useful devtools work to be done for it.

Do other browser engines implement this?
  Chrome (Blink) implements it as of version 52. Their intent-to-implement:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/9W80Kw-z3ss

web-platform-tests:
 https://wpt.fyi/results/css/css-contain

https://wpt.fyi/results/css/vendor-imports/mozilla/mozilla-central-reftests/contain

Is this feature restricted to secure contexts?
 No, not currently. Note that Chrome doesn't restrict it, so it could
conceivably create interop issues if we restricted it without getting them
to also commit to restricting it.

On Mon, Mar 18, 2019 at 12:39 PM Daniel Holbert 
wrote:

> Yeah, sorry - our earlier intent-to-implement thread predated our current
> boilerplate (which includes stuff like test coverage).  And for
> intent-to-ship, our boilerplate text is pretty minimal.
>
> Answering your direct question: yes, there is good web platform test
> coverage for this feature.  I'll post a followup with answers to our other
> typical intent-to-implement fields, too.
>
> On Mon, Mar 18, 2019 at 12:07 PM James Graham 
> wrote:
>
>> On 18/03/2019 19:01, Daniel Holbert wrote:
>> > As of today (March 18th 2019), I intend to turn CSS Containment
>> >  on by default on all
>> platforms, in
>> > Firefox Nightly 68. It has been developed behind the
>> > 'layout.css.contain.enabled' preference.
>>
>> Apologies if I've missed it, but I can't see any mention of whether this
>> feature has — meaningful — cross browser (i.e. wpt) tests in the ItI
>> thread or here.
>> ___
>> 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 Containment

[Daniel Holbert]

Yeah, sorry - our earlier intent-to-implement thread predated our current
boilerplate (which includes stuff like test coverage).  And for
intent-to-ship, our boilerplate text is pretty minimal.

Answering your direct question: yes, there is good web platform test
coverage for this feature.  I'll post a followup with answers to our other
typical intent-to-implement fields, too.

On Mon, Mar 18, 2019 at 12:07 PM James Graham 
wrote:

> On 18/03/2019 19:01, Daniel Holbert wrote:
> > As of today (March 18th 2019), I intend to turn CSS Containment
> >  on by default on all platforms,
> in
> > Firefox Nightly 68. It has been developed behind the
> > 'layout.css.contain.enabled' preference.
>
> Apologies if I've missed it, but I can't see any mention of whether this
> feature has — meaningful — cross browser (i.e. wpt) tests in the ItI
> thread or here.
> ___
> 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 Containment

[James Graham]

On 18/03/2019 19:01, Daniel Holbert wrote:

As of today (March 18th 2019), I intend to turn CSS Containment
 on by default on all platforms, in
Firefox Nightly 68. It has been developed behind the
'layout.css.contain.enabled' preference.


Apologies if I've missed it, but I can't see any mention of whether this 
feature has — meaningful — cross browser (i.e. wpt) tests in the ItI 
thread or here.

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

Intent to ship: CSS Containment

[Daniel Holbert]

As of today (March 18th 2019), I intend to turn CSS Containment
 on by default on all platforms, in
Firefox Nightly 68. It has been developed behind the
'layout.css.contain.enabled' preference.

Other UAs shipping this or intending to ship it are:
* Chrome & other Blink-based UAs (Chrome has supported since Chrome 52,
released in 2016, according to caniuse 
).

Bug to turn on by default:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1532471 is where I'll be
turning it on in Nightly by default (with a guard to only let it ship as
far as early-beta)
* https://bugzilla.mozilla.org/show_bug.cgi?id=1487493 is where I'll be
removing the guard & letting it ride the trains to release, assuming
everything goes well. (I anticipate that this will happen for the Firefox
68 release cycle.)

This feature was previously discussed in this "intent to implement" thread:
https://groups.google.com/d/msg/mozilla.dev.platform/q-uXVVClcU4/WswhXtlWqFIJ
(though the spec and the feature have evolved a good deal since then)

Note: we don't currently intend to ship support for one of the keywords
mentioned in the spec & which Chrome sort-of supports -- "contain:style".
Chrome doesn't implement this keyword properly/robustly, and we have doubts
about whether the complexity & maintenance burden of a correct
implementation would be justified by this keyword's limited use cases. See
https://github.com/w3c/csswg-drafts/issues/3280 for more on this. The CSS
Working group has marked this keyword as "at-risk", as a result of the
discussion around these concerns.

Many thanks to former-interns Morgan Reschenberg, Yusuf Sermet, and Kyle
Zentner for their hard work on this feature!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Define and share |mach try| presets in-tree

[Kartikaya Gupta]

This is really nice! Thanks!

On Mon, Mar 18, 2019 at 11:57 AM Andrew Halberstadt  wrote:
>
> Hello all,
>
> Just a quick heads up that you can now define and share try presets
> in-tree by adding them to this file:
> https://searchfox.org/mozilla-central/source/tools/tryselect/try_presets.yml
>
> There are a few presets in there that make it easy to copy from, but
> the gist is any name defined in that file will be runnable via:
>
> $ ./mach try --preset 
>
> For example:
>
> $ ./mach try --preset perf
>
> will run all talos and raptor tasks. You can further filter presets like
> this:
>
> $ ./mach try --preset perf -xq "windows"
>
> This will restrict the tasks returned by the perf preset to Windows only.
> See more documentation on presets here:
> https://firefox-source-docs.mozilla.org/tools/try/presets.html
>
> Note when creating presets:
> If you wish to create a new preset, please use the fuzzy selector.
> While there are no technical reasons you can't use try syntax, fuzzy
> allows you to be much more precise which helps save resources. It also
> allows post-filtering for the users of your preset, which is not possible
> with try syntax. If you are unfamiliar with the fzf query syntax, feel free
> to reach out and tell me what tasks you need and I'll help you craft a
> preset.
>
> Cheers,
> Andrew
>
> ___
> 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

PSA: Define and share |mach try| presets in-tree

[Andrew Halberstadt]

Hello all,

Just a quick heads up that you can now define and share try presets
in-tree by adding them to this file:
https://searchfox.org/mozilla-central/source/tools/tryselect/try_presets.yml

There are a few presets in there that make it easy to copy from, but
the gist is any name defined in that file will be runnable via:

$ ./mach try --preset 

For example:

$ ./mach try --preset perf

will run all talos and raptor tasks. You can further filter presets like
this:

$ ./mach try --preset perf -xq "windows"

This will restrict the tasks returned by the perf preset to Windows only.
See more documentation on presets here:
https://firefox-source-docs.mozilla.org/tools/try/presets.html

*Note when creating presets:*
If you wish to create a new preset, please use the *fuzzy* selector.
While there are no technical reasons you can't use try syntax, fuzzy
allows you to be much more precise which helps save resources. It also
allows post-filtering for the users of your preset, which is not possible
with try syntax. If you are unfamiliar with the fzf query syntax, feel free
to reach out and tell me what tasks you need and I'll help you craft a
preset.

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

[desktop] Bugs logged by Desktop Release QA in the last 7 days

[Mihai Boldan]

Hello,

Here's the list of new issues found and filed by the Desktop Release QA 
team in the last 7 days.
Additional details on the team's priorities last week, as well as the 
plans for the current week are available at: https://tinyurl.com/y3crqxqj.

Bugs logged by Desktop Release QA in the last 7 days:

Firefox: Preferences
VERIFIED FIXED - https://bugzil.la/1534218 - Can't set as Home Page the 
Other Bookmarks folder


Firefox: Site Identity and Permission Panels
NEW - https://bugzil.la/1534219 - The blockautoplay icon isn't show 
again after switching back to http://arcticmonkeys.com/


Firefox: Preferences
VERIFIED FIXED - https://bugzil.la/1534256 - Wrong support webpage is 
displayed after clicking the about:preferences help buttons


Firefox: Theme
NEW - https://bugzil.la/1534289 - Downloads Panel message is hardly readable

Firefox: Search
NEW - https://bugzil.la/1534317 - Ebay search engine is inserted as 
default even if is not region specific


Firefox: Session Restore
NEW - https://bugzil.la/1534622 - Using about:crashparent before the 
page fully loads and is "saved" brings up an empty tab after restore


Firefox: Search
NEW - https://bugzil.la/1534652 - Google search engine gets removed 
after deleting the foo.js default preferences file


Firefox: Sync
NEW - https://bugzil.la/1534699 - Synced Tabs panel is blank after using 
Forget about some browsing history


Firefox: General
NEW - https://bugzil.la/1535307 - Querry displayed instead of error code 
if Trigger update in about:url-clasifier page without internet access


Firefox: Distributions
NEW - https://bugzil.la/1535592 - [WIN] About Firefox window - custom 
text cause issues in frame


Core: CSS Parsing and Computation
NEW - https://bugzil.la/1534231 - [win] menulist-button no longer 
displays the triangle icon


Core: Audio/Video: Playback
NEW - https://bugzil.la/1535539 - Mute/Unmute context menu option is not 
working by following specific steps


Core: Graphics: Text
NEW - https://bugzil.la/1535583 - [Youtube] Unsubscribed channel popup 
changes slightly its size on tab navigation


Toolkit: Safe Browsing
ASSIGNED - https://bugzil.la/1535289 - [Safe Browsing] If the provider 
has no update triggered, warnings are not displayed for harmful websites 
using a Latin non ascii character profile


Toolkit: Safe Browsing
NEW - https://bugzil.la/1535304 - Can't trigger update for google in 
about:url-classifier


Toolkit: Safe Browsing
NEW - https://bugzil.la/1535313 - The fields in about:url-classifier are 
empty if Firefox in started in Safe Mode


This is available as a Bugzilla bug list as well: 
https://tinyurl.com/y5h8e8m7.


Regards,
Mihai Boldan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform