Re: Intent To Ship: backdrop-filter

[Martin Thomson]

On Wed, Jun 10, 2020 at 8:01 AM L. David Baron  wrote:
> It's also something that I think we shouldn't be doing, at least not
> without a clear and relatively short timeline for having the feature
> available across all graphics backends (whether by implementing it
> for more backends or by no longer shipping those backends).

I agree with David's reasoning here about this being potentially
harmful, but I do recognize the value of prototyping or experimenting.
This doesn't seem to be either of those though.

To that end, is there a plan for making this capability uniformly available?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent To Ship: backdrop-filter

[L. David Baron]

On Friday 2020-05-29 12:50 -0700, Erik Nordin wrote:
> Intent:
> 
> As of Nightly 79 (shipping in release 7/28) I intend to turn
> backdrop-filter on by default for all systems on which WebRender is enabled.
> 
> Here is a list of systems and their current status with regard to shipping
> WebRender:
> 
> https://wiki.mozilla.org/Platform/GFX/WebRender_Where
...
> More Information:
> 
> The backdrop-filter pref will be set to true on all systems, but
> backdrop-filter’s functionality will not be available unless WebRender is
> also enabled and available.
> 
> Developers can check for backdrop-filter’s availability via CSS.supports()
> or @supports. Developers can still explicitly turn off backdrop-filter by
> disabling its pref in about:config.
> 
> If WebRender were to crash and become unavailable, backdrop-filter will
> also become unavailable. Subsequent calls to CSS.supports() will reflect
> this change, as will subsequent parses of CSS StyleSheets that use @supports
> rules.
> 
> Note, however, that any backdrop-filter-related information that was
> collected prior to this event may now be incorrect until the page is
> refreshed.

It's worth calling out here that shipping platform features for only
some of our graphics backends is something new for us.  (It's
possible we've done it in the past, but I'm not aware of us doing it
*intentionally*.)

It's also something that I think we shouldn't be doing, at least not
without a clear and relatively short timeline for having the feature
available across all graphics backends (whether by implementing it
for more backends or by no longer shipping those backends).

I think it's bad for the following reasons:

  1. It makes the idea of targeting and testing on Firefox more
  complicated for Web developers.  We're at risk of being ignored by
  Web developers; being a more complicated and fragmented target
  increases that risk, especially for the smaller fragment(s), and
  also makes Web developers dislike us for creating more complexity
  for them.

  2. We risk creating Web compatibility problems for our own users.
  While shipping the feature to some of our users will probably
  reduce web compatibility problems for that subset of users, it
  will also probably *increase* Web compatibility problems for the
  remaining users, since many developers who *do* care about testing
  on Firefox may produce content that's broken for those users.

(I'd note that I've expressed this concern to Erik, Sean, and others
in the past, but also encouraged them to send this intent because I
think this should be a broader discussion.)

-David

-- 
턞   L. David Baronhttps://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 Ship: Require user interaction for session history entries

[Johann Hofmann]

I didn't initially add it to Fenix/GV because I wanted to keep the bug
focused on the session history pieces and also wanted to give the mobile
team a chance to evaluate this independently (the back button might work
slightly differently on mobile). As mentioned, it should in theory be easy
to add once this is available on central. I filed bug 1644595 for
continuing that discussion.

Thanks for calling that out!

On Tue, Jun 9, 2020 at 11:30 PM  wrote:

> On Tuesday, June 9, 2020 at 2:17:02 PM UTC-7, Johann Hofmann wrote:
> > In bug 1515073  I
> > plan to land an intervention that is aimed to reduce user frustration
> from
> > an issue with malfunctioning or malicious websites which is commonly
> known
> > as the “broken back button”.
> >
> > For user-initiated session history interactions, such as pressing the
> back
> > button or opening the back/forward menu, we want to only consider the
> first
> > session history entries that were created after the associated document
> > received a user interaction event. This means that when a document has
> user
> > interaction and a new session history entry is added, that entry
> “consumes”
> > the user interaction from the document and the next entry will again
> > require a new user interaction on the document.
> >
> > Both the first (earliest) and last (latest) session history entries will
> > always be available for navigation.
> >
> > Note that this explicitly does not change the behavior of any web-exposed
> > APIs such as history.back().
> >
> > Some more details can be found in this document
> > <
> https://docs.google.com/document/d/1eK5xcWo1T7M-SguRshahy53zHMvkvVzxIjVWZm34o-U/edit#
> >
> > .
> >
> > I’m planning to land and enable this in Nightly 79, but want to leave
> > sufficient bake time to be confident that it’s not breaking any critical
> > functionality. We're expecting this to ride the trains with at least
> > version 80 or later.
> >
> > Standard: This feature is not standardized though there has been a public
> > discussion in https://github.com/WICG/interventions/issues/21
> >
> > Platform coverage: This will land enabled in desktop only for now, but
> it’s
> > built in a way that should make it easy for Android browsers to add
> support.
> >
> > Preference: On desktop this is behind the preference
> > “browser.navigation.requireUserInteraction”. It will be set to true in
> > Nightly by default.
> >
> > DevTools: This is not yet integrated into devtools though we should
> > consider logging a warning to the console when we skip an entry.
> >
> > Other browsers:
> >
> > Chrome: Shipped last year
> > <
> https://groups.google.com/a/chromium.org/forum/?#!msg/blink-dev/T8d4_BRb2xQ/WSdOiOFcBAAJ
> >.
> > Our implementation is following their approach and we’ve seen several web
> > compat bugs from sites relying on this behavior from Chrome.
> >
> > Safari: No public signals
> >
> > Let me know if you have any questions or concerns,
> >
> > Thanks!
> >
> > Johann
>
> This is really nice!
>
> > Platform coverage: This will land enabled in desktop only for now, but
> it’s
> built in a way that should make it easy for Android browsers to add
> support.
>
> I'm wondering why this is landing as Desktop only? Could you share the bug
> for supporting this on mobile?
>
> Thanks,
> Agi
> ___
> 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: Precise test scheduling with |mach try auto|

[Bobby Holley]

This is very exciting on a number of fronts: reduced CI spend, detecting
more defects, and reduced cognitive overhead for developers. Thanks to
Andrew and everyone else involved for getting us here!

On Mon, Jun 8, 2020 at 9:14 AM Andrew Halberstadt  wrote:

> *tl;dr**: Your |mach try auto| pushes can now precisely schedule relevant
> manifests, catching more regressions with fewer resources.*
>
> I'm happy to announce an important new capability that has been added to
> our CI infrastructure: scheduling specific test manifests.
>
> We've been building a machine learning algorithm to determine which tests
> are most relevant to a given push. This is now running on autoland, as well
> as when you push to try with |mach try auto|. Previously, the biggest
> limitation of this system was that test manifests were already assigned to
> tasks by the time we could run the ML algorithm. So we'd have a list of
> important manifests, then run the chunks that contain those manifests. The
> drawback was we'd also run all the other unimportant manifests that
> happened to be in the same chunk as the important one.
>
> As of late last week, |mach try auto| is now running in "manifest
> scheduling" mode. This means the ML algorithm is running earlier in the
> process and is actually creating the test chunks based on how many
> important manifests there are. Therefore we are only running manifests that
> are relevant to your push and are avoiding the collateral damage caused by
> all the "unimportant" ones. As part of this change I've tweaked the minimum
> importance threshold downward, meaning the algorithm classifies a greater
> number of manifests as "important". So |mach try auto| pushes will schedule
> a greater number of relevant manifests, while simultaneously scheduling
> fewer manifests over all.
>
> One thing to note is that the chunks in your |mach try auto| pushes will
> not bear any resemblance to the chunks that are created on autoland. In
> fact, they may bear no resemblance to the previous |mach try auto| push you
> made, even with similar changes. If you need to figure out where a given
> test ran you can use Treeherder's test path filter:
>
> 1. Click the filter icon near the top right in Treeherder (next to
> coloured circles)
> 2. Select "test path" from the drop down
> 3. Type out the test path you are looking for
> 4. Click "Add"
>
> Please note that reftest isn't supported in this filter yet, and WPT
> requires test identifiers (e.g `/foo` instead of
> `testing/web-platform/tests/foo`).
>
> *What's Next?*
>
> There is a lot of work still coming down the pipeline. First and foremost,
> we want to enable "manifest scheduling" on autoland in addition to |mach
> try auto|. There are certain problems that exist on autoland (like sheriff
> backfilling) that we didn't need to worry about on try. Next we'll support
> manifest scheduling on all test suites (the major ones that are missing
> include reftest and derivatives, WPT reftests and mochitest-webgl). Last
> but not least, we're going to continue working through all of the feedback
> we've been gathering over the past weeks. Thanks to everyone who has left
> feedback around |mach try auto|, it's been invaluable!
>
> In case this post prompts you to try it out (or to revisit it again), then
> please file bugs and suggestions under `Firefox Build System :: Try`, or
> ping us in #test-selection on Matrix.
>
> Cheers!
> ___
> 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

Re: Intent to Ship: Require user interaction for session history entries

[asferro]

On Tuesday, June 9, 2020 at 2:17:02 PM UTC-7, Johann Hofmann wrote:
> In bug 1515073  I
> plan to land an intervention that is aimed to reduce user frustration from
> an issue with malfunctioning or malicious websites which is commonly known
> as the “broken back button”.
> 
> For user-initiated session history interactions, such as pressing the back
> button or opening the back/forward menu, we want to only consider the first
> session history entries that were created after the associated document
> received a user interaction event. This means that when a document has user
> interaction and a new session history entry is added, that entry “consumes”
> the user interaction from the document and the next entry will again
> require a new user interaction on the document.
> 
> Both the first (earliest) and last (latest) session history entries will
> always be available for navigation.
> 
> Note that this explicitly does not change the behavior of any web-exposed
> APIs such as history.back().
> 
> Some more details can be found in this document
> 
> .
> 
> I’m planning to land and enable this in Nightly 79, but want to leave
> sufficient bake time to be confident that it’s not breaking any critical
> functionality. We're expecting this to ride the trains with at least
> version 80 or later.
> 
> Standard: This feature is not standardized though there has been a public
> discussion in https://github.com/WICG/interventions/issues/21
> 
> Platform coverage: This will land enabled in desktop only for now, but it’s
> built in a way that should make it easy for Android browsers to add support.
> 
> Preference: On desktop this is behind the preference
> “browser.navigation.requireUserInteraction”. It will be set to true in
> Nightly by default.
> 
> DevTools: This is not yet integrated into devtools though we should
> consider logging a warning to the console when we skip an entry.
> 
> Other browsers:
> 
> Chrome: Shipped last year
> .
> Our implementation is following their approach and we’ve seen several web
> compat bugs from sites relying on this behavior from Chrome.
> 
> Safari: No public signals
> 
> Let me know if you have any questions or concerns,
> 
> Thanks!
> 
> Johann

This is really nice!

> Platform coverage: This will land enabled in desktop only for now, but it’s
built in a way that should make it easy for Android browsers to add support. 

I'm wondering why this is landing as Desktop only? Could you share the bug for 
supporting this on mobile?

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

Intent To Ship: backdrop-filter

[Erik Nordin]

Intent:

As of Nightly 79 (shipping in release 7/28) I intend to turn
backdrop-filter on by default for all systems on which WebRender is enabled.

Here is a list of systems and their current status with regard to shipping
WebRender:

https://wiki.mozilla.org/Platform/GFX/WebRender_Where

The feature has been developed behind the preference:
layout.css.backdrop-filter.enabled

Status in Other Browsers:

https://developer.mozilla.org/en-US/docs/Web/CSS/backdrop-filter

   Edge: 17
  Opera: 34 (feature-flagged)
Chrome: 76
Safari:  9 (vendor-prefix)
Firefox: 70 (feature-flagged)

Product Manager:

Martin Balfanz

Bug:

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

Intent To Implement:

https://groups.google.com/forum/#!searchin/mozilla.dev.platform/backdrop-filter%7Csort:date/mozilla.dev.platform/7tgkiUSa70w/iruXob5jAQAJ

More Information:

The backdrop-filter pref will be set to true on all systems, but
backdrop-filter’s functionality will not be available unless WebRender is
also enabled and available.

Developers can check for backdrop-filter’s availability via CSS.supports()
or @supports. Developers can still explicitly turn off backdrop-filter by
disabling its pref in about:config.

If WebRender were to crash and become unavailable, backdrop-filter will
also become unavailable. Subsequent calls to CSS.supports() will reflect
this change, as will subsequent parses of CSS StyleSheets that use @supports
rules.

Note, however, that any backdrop-filter-related information that was
collected prior to this event may now be incorrect until the page is
refreshed.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Ship: Require user interaction for session history entries

[Johann Hofmann]

In bug 1515073  I
plan to land an intervention that is aimed to reduce user frustration from
an issue with malfunctioning or malicious websites which is commonly known
as the “broken back button”.

For user-initiated session history interactions, such as pressing the back
button or opening the back/forward menu, we want to only consider the first
session history entries that were created after the associated document
received a user interaction event. This means that when a document has user
interaction and a new session history entry is added, that entry “consumes”
the user interaction from the document and the next entry will again
require a new user interaction on the document.

Both the first (earliest) and last (latest) session history entries will
always be available for navigation.

Note that this explicitly does not change the behavior of any web-exposed
APIs such as history.back().

Some more details can be found in this document

.

I’m planning to land and enable this in Nightly 79, but want to leave
sufficient bake time to be confident that it’s not breaking any critical
functionality. We're expecting this to ride the trains with at least
version 80 or later.

Standard: This feature is not standardized though there has been a public
discussion in https://github.com/WICG/interventions/issues/21

Platform coverage: This will land enabled in desktop only for now, but it’s
built in a way that should make it easy for Android browsers to add support.

Preference: On desktop this is behind the preference
“browser.navigation.requireUserInteraction”. It will be set to true in
Nightly by default.

DevTools: This is not yet integrated into devtools though we should
consider logging a warning to the console when we skip an entry.

Other browsers:

Chrome: Shipped last year
.
Our implementation is following their approach and we’ve seen several web
compat bugs from sites relying on this behavior from Chrome.

Safari: No public signals

Let me know if you have any questions or concerns,

Thanks!

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

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

[camelia badau]

Hello,

Here's the list of new issues found and filed by the Desktop Release QA
team in the last 8 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/y9jss354.
Bugs logged by Desktop Release QA in the last 8 days:

Firefox: Address Bar
* NEW - https://bugzil.la/1643687 - Search bar becomes unresponsive if
using paste and go context menu option with a string while search tip is
displayed

Firefox: Theme
* NEW - https://bugzil.la/1643245 - Dark theme - addons icon on
SessionRestore needs color change to improve visibility

Firefox: Migration
* RESOLVED FIXED - https://bugzil.la/1643321 - Missing labels inside Import
wizard for the Edge browser

Firefox: Preferences
* RESOLVED WONTFIX - https://bugzil.la/1643626 - Yellow arrows when
searching for firefox string in about:preferences on Firefox will remember
history drop-down

Core: Printing: Setup
* VERIFIED FIXED - https://bugzil.la/1643418 - [macOS] Selected range is
ignored and Firefox prints all the pages

Core: mozglue
* NEW - https://bugzil.la/1642626 - Error thrown in console when running
target.cppunittest.tests

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

Regards,

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