[IMPORTANT] Submit your PI Requests for Skyline/Firefox 70 QA feature testing by July 19

[Tom Grabowski]

Similar to what QA did for previous Firefox feature testing prioritization
,
we would like to do the same for Fx70/Skyline. In order to help with the
process, please *submit your pi-request
*
by *July 19*. This is
needed to assure QA will be involved in your feature development work for
the 70 cycle. Please ensure to update the *Priority of the PI request
*(Highest,
High, Medium, Low, Lowest) since during feature prioritization process,
this will be factored in to ensure critical features have sufficient
resources assigned. For Skyline related requests, please mention "*Skyline*"
in description or summary.

Please note that the *Feature technical documentation* for *features that
require Nightly testing* needs to be ready before *July 26*. For features
requiring just *Beta testing*, the *due date *is* August 2nd*. Please
follow the Feature Technical Documentation Guidelines Template

and share the information with the QA owners or add the link in the PI
request in JIRA. QA cannot start working on your feature without
documentation.


*Q: What happens after the deadline?*
A: After the deadline QA will come back with a prioritized list of work
that represents what we are committing to for the next cycle. We want to
ensure this list matches eng and product expectations.

* Q: What if I miss the deadline?*
A: We reserve the right to say that we can't pick up work for late requests
in the current cycle. You can still develop and execute your own test plan
or defer the work to the following cycle. If the work is critical please
follow the Exception approval process


* Q: What about unknown or unexpected requests? What if there is a business
reason for a late request? What do we do with experiments and System
Add-ons?*
A: In order to remain flexible, we will keep some percentage of time open
for requests like these. Such requests need to follow the Exception
approval process


*Q: There's no way I'm going to remember to do this.*
A: Do it now! I'll also send out a reminder next week.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Implement: CSS backdrop-filter

[Jeff Muizelaar]

On Thu, Jul 11, 2019 at 11:28 AM L. David Baron  wrote:
> I don't think having a CSS feature that stops working if the GPU
> process crashes is acceptable.  It's not a coherent story to web
> developers, and it means that once sites start relying on the
> feature (which they'll think they can do because it looks like it
> works), pages will be broken for some portion of our users.

I believe there's some precedent for this. I have a vague memory of a
browser which didn't have working 3d transforms if not run with a GPU.
Further, I'm not sure that having a broken backdrop filter is that
much worse an experience than the performance degradation that comes
from disabling GPU acceleration. That being said, I agree it's not an
ideal situation.

I think we can probably postpone making a decision about this until we
have a working implementation on top of WebRender. We'll then be in a
better spot to evaluate the work needed to make this work with
non-WebRender vs waiting for WebRender everywhere vs the weirdness of
partially shipping it as proposed here.

-Jeff
___
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 Thursday 2019-07-11 10:59 -0400, Jeff Muizelaar wrote:
> On Thu, Jul 11, 2019 at 10:46 AM Emilio Cobos Álvarez  
> wrote:
> > 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.
> 
> I feel like having the wrong results from @supports in this case is
> probably acceptable.
> I suspect background-filter is rarely used in ways that lying in
> @supports causes a website to become unusable.
> 
> I see disabling it in @supports as sort a best effort kind of thing as
> opposed to needing to be perfect.

I don't think having a CSS feature that stops working if the GPU
process crashes is acceptable.  It's not a coherent story to web
developers, and it means that once sites start relying on the
feature (which they'll think they can do because it looks like it
works), pages will be broken for some portion of our users.

-David

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

[Jeff Muizelaar]

On Thu, Jul 11, 2019 at 10:46 AM Emilio Cobos Álvarez  wrote:
> 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.

I feel like having the wrong results from @supports in this case is
probably acceptable.
I suspect background-filter is rarely used in ways that lying in
@supports causes a website to become unusable.

I see disabling it in @supports as sort a best effort kind of thing as
opposed to needing to be perfect.

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