Re: Intent to prototype and ship: CSS `quotes: auto`

[fantasai]

On 7/8/19 3:53 AM, Jonathan Kew wrote:

Summary:
Adding a new `auto` value as the initial value of CSS `quotes` property, with 
the behavior that language-sensitive quotation marks (derived from CLDR) are 
used for quote-open/close generated content.


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

Standard:
https://drafts.csswg.org/css-content-3/#quotes (not yet updated to reflect 
recent WG resolution)


Updated spec, and requested publication so hopefully should hit 
http://www.w3.org/TR/css-content-3/ later this week.


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

Intent to ship: Percentage opacity

[Boris Chiou]

Hi,

Summary: Per the recent discussion of the spec, we would like to add
 to opacity related properties. The following properties will
support not only  but also :
1. opacity 
2. flood-opacity

3. fill-opacity  (also
in SVG2 )
4. stroke-opacity 
(also in SVG2 )
5. stop-opacity (in SVG2
)
6. -moz-window-opacity
Basically, the percentage value is always converted into the equivalent
number.

Example: if opacity = "50%", the serializations of its specified value and
computed value are both "0.5".

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1562086
Standard:
1. : https://drafts.csswg.org/css-color/#typedef-alpha-value
2. Discussion: https://github.com/w3c/csswg-drafts/issues/3342
3. Decision: https://github.com/mozilla/wg-decisions/issues/69

Platform coverage: All.
Preference: No.
DevTools bug: No.

Other browsers:
  * Chrome issue:
https://bugs.chromium.org/p/chromium/issues/detail?id=907787  (intent to
implement and ship doc)

  * WebKit: Nope (I didn't find the opened WebKit issue.)

Web-platform-tests: I will add web-platform-tests for those properties in
the same bug. (It seems Chrome would like to add them, but I didn't see any
update in the Chrome issue recently, so I may add them first.)
1. opacity:
testing/web-platform/tests/css/css-color/parsing/opacity-valid.html

2. flood-opacity:
testing/web-platform/tests/css/filter-effects/parsing/flood-opacity-valid.svg

3. fill-opacity:
testing/web-platform/tests/svg/painting/parsing/fill-opacity-valid.svg

4. stroke-opacity:
testing/web-platform/tests/svg/painting/parsing/stroke-opacity-valid.svg

5. stop-opacity:
testing/web-platform/tests/svg/pservers/parsing/stop-opacity-valid.svg


Secure contexts: No. Just let parser support percentage value on `Opacity`
type.

Thanks.

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

Re: Coding style  : `int` vs `intX_t` vs `unsigned/uintX_t`

[Bobby Holley]

On Tue, Jul 9, 2019 at 3:23 PM Mike Hommey  wrote:

> On Tue, Jul 09, 2019 at 10:39:37AM -0400, Ehsan Akhgari wrote:
> > On Mon, Jul 8, 2019 at 11:00 PM Gerald Squelart 
> > wrote:
> >
> > > Thank you all for some very interesting discussions so far.
> > >
> > > Even if we don't take blanket steps to avoid unsigned types in
> > > non-bitfield/modulo cases (as suggested by our newly-adopted Google
> style),
> > > at least hopefully we're now aware of their subtleties, and we can be
> more
> > > careful and deliberate in our choice of integer types in our respective
> > > domains.
> > >
> > > Coming back to my original questions, I think the first part has not
> been
> > > categorically answered yet:
> > >
> > > Do we have style rules (or folklore) against naked `int`s/`unsigned`s,
> in
> > > favor of explicitly-sized `(u)intXX_t` everywhere?
> > >
> >
> > For new code, the style guide for this question can be found here:
> > https://google.github.io/styleguide/cppguide.html#Integer_Types.  For
> > existing code, consistency with surrounding code should take precedence
> for
> > now.  I hope this answers your question.
>
> I thought we only adopted the Google style guide for formatting. Does
> everything from the guide apply now? Or only parts of it? If the latter,
> which parts? I'm surprised because I don't remember having seen a mail
> about this, and surely, I should have noticed something that'd be
> saying that class member variables names would stop beginning with m,
> and would instead finish with an underscore and be all lowercase.
>

>From the original announcement [1]:

> We will automatically enforce restrictions on formatting of whitespace
(such as indentation and braces).
> For stylistic features other than that (such as naming of functions and
#include order), Google C++ style
> will be permitted but not initially enforced, and consistency with
surrounding code should take precedence.

In other words, we should default to using Google C++ style when doing so
would not be massively more disruptive or inconsistent than the
alternative. So we're not boiling the ocean over mFoo, but preferring the
explicit integer types and citing the Google style guide is a reasonable
thing to do.

[1]
https://docs.google.com/document/d/1CTaWucldHxEri5BUB1kL4faF4prwPlBa31yHFd-l8uc/edit


>
> Mike
> ___
> 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: Coding style  : `int` vs `intX_t` vs `unsigned/uintX_t`

[Mike Hommey]

On Tue, Jul 09, 2019 at 10:39:37AM -0400, Ehsan Akhgari wrote:
> On Mon, Jul 8, 2019 at 11:00 PM Gerald Squelart 
> wrote:
> 
> > Thank you all for some very interesting discussions so far.
> >
> > Even if we don't take blanket steps to avoid unsigned types in
> > non-bitfield/modulo cases (as suggested by our newly-adopted Google style),
> > at least hopefully we're now aware of their subtleties, and we can be more
> > careful and deliberate in our choice of integer types in our respective
> > domains.
> >
> > Coming back to my original questions, I think the first part has not been
> > categorically answered yet:
> >
> > Do we have style rules (or folklore) against naked `int`s/`unsigned`s, in
> > favor of explicitly-sized `(u)intXX_t` everywhere?
> >
> 
> For new code, the style guide for this question can be found here:
> https://google.github.io/styleguide/cppguide.html#Integer_Types.  For
> existing code, consistency with surrounding code should take precedence for
> now.  I hope this answers your question.

I thought we only adopted the Google style guide for formatting. Does
everything from the guide apply now? Or only parts of it? If the latter,
which parts? I'm surprised because I don't remember having seen a mail
about this, and surely, I should have noticed something that'd be
saying that class member variables names would stop beginning with m,
and would instead finish with an underscore and be all lowercase.

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

Re: Intent to Implement: CSS backdrop-filter

[L. David Baron]

On Monday 2019-07-08 15:21 -0700, Connor Brewster wrote:
> Hi Ehsan,
> 
> Currently, the plan is to develop this feature behind a pref flag that will
> be off by default. We haven't decided the best way forward for enabling
> this feature by default yet. We have two possible options:
>  1. Add backdrop filter support to the other render backends.

This seems like a reasonable option.

>  2. Rely on an @supports media query to determine if backdrop-filter is
> supported (this would check for the backdrop-filter pref flag and check if
> WebRender is enabled). If we choose this route, we need to remove any
> dynamic fallbacks to the software renderer that may occur when using
> backdrop-filter. Currently WebRender does not support all SVG filters, so
> these would need to be fully implemented for this approach to work.

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.

-David

> 
> >  * Do we have other web-exposed features that are only supported when
> WebRender is enabled?
> 
> I don't believe we have any other web-exposed features only supported by
> WebRender at the moment.
> 
> > * How do we plan to communicate to web developers (who may not
> necessarily know/care what WebRender is) where this feature is usable?
> 
> This is a good thing to keep in mind when determining the right approach.
> If we decide to implement backdrop-filter on all backends, this won't be an
> issue; otherwise, if we go with approach 2, we would need to tell web
> developers to rely on the @supports media query.
> 
> > * What happens to the DevTools integration a) when WebRender is disabled
> on the target Firefox instance, and b) when WebRender is disabled on the
> target Firefox instance but enabled on the host instance (e.g. when
> debugging Fennec on Windows with the right NVIDIA GPU driver).
> 
> Currently, DevTools only checks if the backdrop-filter pref is enabled and
> doesn't check if WebRender is enabled. If we decide on approach 2, we would
> need to check for the cases that you mentioned.
> 
> Thanks,
> Connor
> 
> 
> On Fri, Jul 5, 2019 at 7:23 AM Ehsan Akhgari 
> wrote:
> 
> > On Mon, Jul 1, 2019 at 8:54 PM Connor Brewster 
> > wrote:
> >
> >> Platform coverage: All platforms using the Gecko rendering engine
> >> (WebRender enabled only)
> >>
> >> Target release: Firefox 71 (WebRender enabled only)
> >>
> >> DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1561060
> >>
> >
> > Hi Connor,
> >
> > Since this feature is only enabled based on WebRender being enabled, I
> > have a few questions for you:
> >
> > * Do we have other web-exposed features that are only supported when
> > WebRender is enabled?
> >
> > * How do we plan to communicate to web developers (who may not necessarily
> > know/care what WebRender is) where this feature is usable?
> >
> > * What happens to the DevTools integration a) when WebRender is disabled
> > on the target Firefox instance, and b) when WebRender is disabled on the
> > target Firefox instance but enabled on the host instance (e.g. when
> > debugging Fennec on Windows with the right NVIDIA GPU driver).
> >
> > Thanks,
> > --
> > Ehsan
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Implement: CSS backdrop-filter

[Connor Brewster]

Hi Tom,

> In particular, this one looks like it has all the same
> concerns/problems with filters being applied to sensitive third party
> content, and attacks that use timing to read that content. Are these
> going to be tested for/addressed during implementation?

We are not aware of any new attacks that will be introduced by
backdrop-filter that are not already possible via the filter property as
both properties will share the same filtering implementation. This feature
will be preferenced off by default and we will have some time to experiment
and check for these kinds of attacks before enabling the feature by default.

-Connor

On Fri, Jul 5, 2019 at 7:11 AM Tom Ritter  wrote:

> Just a note: we have a new template for Intent to X here:
> https://wiki.mozilla.org/ExposureGuidelines
>
> In particular, this one looks like it has all the same
> concerns/problems with filters being applied to sensitive third party
> content, and attacks that use timing to read that content. Are these
> going to be tested for/addressed during implementation?
>
> -tom
>
> On Thu, Jul 4, 2019 at 7:09 PM Connor Brewster 
> wrote:
> >
> > Clarification: backfrop-filter will *not* be restricted to secure
> contexts.
> >
> > On Tue, Jun 25, 2019 at 4:30 PM Connor Brewster 
> > wrote:
> >
> > > Summary: The CSS backdrop-filter property allows web authors to
> specify a
> > > filter to be applied to an element's backdrop. It can be used to create
> > > interesting visual effects that are commonly used in UI design.
> > >
> > > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1178765
> > >
> > > Standard:
> https://drafts.fxtf.org/filter-effects-2/#BackdropFilterProperty
> > >
> > > Platform coverage: All platforms using the Gecko rendering engine
> > > (WebRender enabled only)
> > >
> > > Target release: Firefox 71 (WebRender enabled only)
> > >
> > > Preference behind which this will be implemented:
> > > layout.css.backdrop-filter.enabled
> > >
> > > Is this feature enabled by default in sandboxed iframes? Yes
> > >
> > > DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1561060
> > >
> > > Do other browser engines implement this? WebKit (since version 9,
> behind
> > > -webkit- prefix), Blink (since version 47, Behind "Enable Experimental
> Web
> > > Platform Features" preference)
> > >
> > > web-platform tests:
> > >
> https://searchfox.org/mozilla-central/source/testing/web-platform/tests/css/filter-effects
> > >
> > > Is this feature restricted to secure contexts? Yes
> > >
> > > Connor Brewster
> > >
> > ___
> > 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: Revising the frequency threshold for disabling intermittents?

[Maher（ 馬羅成 ）Joel]

One thing we could do is exclude try runs from the counts, that would make
the bugzilla comments less confusing.

As for actual number of runs, we would need to ingest the raw logs in a
reliable more deterministic way- that is a few TB/week.  There are plans to
take ActiveData (which ingests all the raw logs) and put it into BigQuery
which should give us the support we need for a reliable service.  That will
probably be finished near the end of the year.  There are a lot of edge
cases with the current implementation of activedata when we have tests that
don't output .json logs or they don't have unique or useful testnames (like
reftests that output the testname but the test path).

All of these things have been on our plans for a few years, we keep getting
newer higher priority things to do which delays our plans to work on things
like this.  I think once we have a data warehouse in bigquery we should
revisit this topic and look at what remains to be done.


On Mon, Jul 8, 2019 at 2:23 PM Botond Ballo  wrote:

> On Mon, Jul 8, 2019 at 1:29 PM Maher（ 馬羅成 ）Joel 
> wrote:
> > Here you can see the pushes we have over time:
> > https://sql.telemetry.mozilla.org/dashboard/firefox-ci
> >
> > looking at a monthly level, I see these numbers for (autoland, inbound,
> central):
> > July 2018 - 2049
> > June 2019 - 2376
>
> Ok, I guess I was misled by the numbers in the "X failures in Y
> pushes" figures in the Intermittent Failures Robot comments. Perhaps
> we could fix those / tweak them to be more reflective of the actual
> failure rate?
>
> Thanks,
> Botond
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style  : `int` vs `intX_t` vs `unsigned/uintX_t`

[Ehsan Akhgari]

On Mon, Jul 8, 2019 at 11:00 PM Gerald Squelart 
wrote:

> Thank you all for some very interesting discussions so far.
>
> Even if we don't take blanket steps to avoid unsigned types in
> non-bitfield/modulo cases (as suggested by our newly-adopted Google style),
> at least hopefully we're now aware of their subtleties, and we can be more
> careful and deliberate in our choice of integer types in our respective
> domains.
>
> Coming back to my original questions, I think the first part has not been
> categorically answered yet:
>
> Do we have style rules (or folklore) against naked `int`s/`unsigned`s, in
> favor of explicitly-sized `(u)intXX_t` everywhere?
>

For new code, the style guide for this question can be found here:
https://google.github.io/styleguide/cppguide.html#Integer_Types.  For
existing code, consistency with surrounding code should take precedence for
now.  I hope this answers your question.

Cheers,
Ehsan


>
> On Thursday, July 4, 2019 at 3:11:27 PM UTC+10, Gerald Squelart wrote:
> > Recently I coded something with a not-very-important slow-changing
> rarely-used positive number: `unsigned mGeneration;`
> > My reviewer commented: "Please use a type with an explicit size, such as
> uint32_t. (General mozilla style; you don't see a bare "unsigned" around
> much)"
> >
> > I had never heard of this (in 4+ years), so I did a bit of research:
> >
> > - I found plenty of `unsigned`s around, more than `uint32_t`s.
> >
> > - I can't see anything about that in our coding style guides [1, 2].
> >
> > - Our latest coding style [1] points at Google's, which has a section
> about Integer Types [3], and the basic gist is: Use plain `int` for
> "not-too-big" numbers, int64_t for "big" numbers, intXX_t if you need a
> precise size; never use any unsigned type unless you work with bitfields or
> need 2^N overflow (in particular, don't use unsigned for always-positive
> numbers, use signed and assertions instead).
> >
> > So, questions:
> > 1. Do we have a written style I missed somewhere?
> > 2. Do we have an unwritten style? (In which case I think we should write
> it down.)
> > 3. What do we think of the Google style, especially the aversion to
> unsigned?
> >
> > Cheers,
> > Gerald
> >
> >
> > [1]
> https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style
> > [2]
> https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code
> > [3] https://google.github.io/styleguide/cppguide.html#Integer_Types
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>


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

Re: Intent to Implement: CSS backdrop-filter

[Ehsan Akhgari]

On Mon, Jul 8, 2019 at 6:22 PM Connor Brewster 
wrote:

> Hi Ehsan,
>
> Currently, the plan is to develop this feature behind a pref flag that
> will be off by default. We haven't decided the best way forward for
> enabling this feature by default yet. We have two possible options:
>  1. Add backdrop filter support to the other render backends.
>  2. Rely on an @supports media query to determine if backdrop-filter is
> supported (this would check for the backdrop-filter pref flag and check if
> WebRender is enabled). If we choose this route, we need to remove any
> dynamic fallbacks to the software renderer that may occur when using
> backdrop-filter. Currently WebRender does not support all SVG filters, so
> these would need to be fully implemented for this approach to work.
>

Thanks, this all sounds good!


> >  * Do we have other web-exposed features that are only supported when
> WebRender is enabled?
>
> I don't believe we have any other web-exposed features only supported by
> WebRender at the moment.
>
> > * How do we plan to communicate to web developers (who may not
> necessarily know/care what WebRender is) where this feature is usable?
>
> This is a good thing to keep in mind when determining the right approach.
> If we decide to implement backdrop-filter on all backends, this won't be an
> issue; otherwise, if we go with approach 2, we would need to tell web
> developers to rely on the @supports media query.
>
> > * What happens to the DevTools integration a) when WebRender is disabled
> on the target Firefox instance, and b) when WebRender is disabled on the
> target Firefox instance but enabled on the host instance (e.g. when
> debugging Fennec on Windows with the right NVIDIA GPU driver).
>
> Currently, DevTools only checks if the backdrop-filter pref is enabled and
> doesn't check if WebRender is enabled. If we decide on approach 2, we would
> need to check for the cases that you mentioned.
>
> Thanks,
> Connor
>
>
> On Fri, Jul 5, 2019 at 7:23 AM Ehsan Akhgari 
> wrote:
>
>> On Mon, Jul 1, 2019 at 8:54 PM Connor Brewster 
>> wrote:
>>
>>> Platform coverage: All platforms using the Gecko rendering engine
>>> (WebRender enabled only)
>>>
>>> Target release: Firefox 71 (WebRender enabled only)
>>>
>>> DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1561060
>>>
>>
>> Hi Connor,
>>
>> Since this feature is only enabled based on WebRender being enabled, I
>> have a few questions for you:
>>
>> * Do we have other web-exposed features that are only supported when
>> WebRender is enabled?
>>
>> * How do we plan to communicate to web developers (who may not
>> necessarily know/care what WebRender is) where this feature is usable?
>>
>> * What happens to the DevTools integration a) when WebRender is disabled
>> on the target Firefox instance, and b) when WebRender is disabled on the
>> target Firefox instance but enabled on the host instance (e.g. when
>> debugging Fennec on Windows with the right NVIDIA GPU driver).
>>
>> Thanks,
>> --
>> Ehsan
>>
>

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