Intent to ship: Return pixel deltas in wheel event if deltaMode is not checked by authors

[Emilio Cobos Álvarez]

Hi,

In bug 1696384, I plan to enable 
dom.event.wheel-deltaMode-lines.disabled on all channels.


This is a compat intervention for sites that check 
WheelEvent.delta{X,Y,Z} before checking WheelEvent.deltaMode, generally 
assuming that the deltas are going to be pixels.


These deltas are environment-specific, generally, and authors are always 
expected to check the deltaMode to determine how to scroll, see:


  https://w3c.github.io/uievents/#events-wheelevents

But other browsers historically have always returned pixels, and some 
websites depend on that behavior. That makes Firefox feel super-slow on 
those websites (as the site scrolls by e.g. 3 pixels rather than the 
equivalent 3 lines of content). See bug 1392460 and webcompat issues 
linked from there.


The behavior is the following, decided per event:

 * If deltaMode has been accessed, or the feature is disabled, then 
return the original delta mode and deltas (no behavior change from 
current release).


 * If deltaMode has _not_ been accessed, and it's DOM_DELTA_LINE, 
accessing any of the deltas cause the event to always report 
DOM_DELTA_PIXELS, and the deltas get appropriately converted to pixels too.


There are three prefs involved in controlling the behavior:

 * dom.event.wheel-deltaMode-lines.disabled: This is the global switch 
and if false the behavior doesn't change. If true, it implements the 
behavior described above.


 * dom.event.wheel-deltaMode-lines.always-disabled: This implements the 
behavior of converting lines to pixels unconditionally (without 
depending on event ordering etc). Mostly intended for debugging.


 * dom.event.wheel-deltaMode-lines.always-enabled: This is a domain 
list for domains that might need to switch to the previous behavior. I 
really think that given how this is implemented it shouldn't cause 
trouble for most websites (the pref has been on on nightly for 4 months, 
with no serious regressions), so it should hopefully remain empty.


Let me know if you have any concerns with this or what not.

Cheers,

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

Re: Intent to ship: Return pixel deltas in wheel event if deltaMode is not checked by authors

[Anne van Kesteren]

On Tue, Mar 9, 2021 at 4:45 PM Emilio Cobos Álvarez  wrote:
> Let me know if you have any concerns with this or what not.

So if I understand it correctly we'll have a getter with side effects.
Is the expectation that we can eventually remove this? Are other
browsers on board with this model?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Return pixel deltas in wheel event if deltaMode is not checked by authors

[Emilio Cobos Álvarez]

On 3/9/21 17:10, Anne van Kesteren wrote:


On Tue, Mar 9, 2021 at 4:45 PM Emilio Cobos Álvarez  wrote:

Let me know if you have any concerns with this or what not.


So if I understand it correctly we'll have a getter with side effects.
Is the expectation that we can eventually remove this? Are other
browsers on board with this model?


Well, the side effect is not _quite_ that bad IMO, in the sense that the 
page can't really tell whether the event is returning pixels because the 
scroll was actually pixel-based (e.g., trackpads do this IIRC) or 
because they didn't check deltaMode.


The only alternative to this that I can think of is basically never 
return DOM_DELTA_LINE (which is what other browsers do in practice), but 
that seemed both more risky for us, and also a potential regression 
(knowing lines can be useful).


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

Re: Intent to ship: Return pixel deltas in wheel event if deltaMode is not checked by authors

[James Graham]

On 09/03/2021 18:21, Emilio Cobos Álvarez wrote:

On 3/9/21 17:10, Anne van Kesteren wrote:


On Tue, Mar 9, 2021 at 4:45 PM Emilio Cobos Álvarez 
 wrote:

Let me know if you have any concerns with this or what not.


So if I understand it correctly we'll have a getter with side effects.
Is the expectation that we can eventually remove this? Are other
browsers on board with this model?


Well, the side effect is not _quite_ that bad IMO, in the sense that the 
page can't really tell whether the event is returning pixels because the 
scroll was actually pixel-based (e.g., trackpads do this IIRC) or 
because they didn't check deltaMode.


The only alternative to this that I can think of is basically never 
return DOM_DELTA_LINE (which is what other browsers do in practice), but 
that seemed both more risky for us, and also a potential regression 
(knowing lines can be useful).


It seems like having all browsers have the same behaviour is going to be 
better in the long run than having some weird heuristic in gecko that 
acts as a footgun for authors going forward.


Do we have any way to assess the compat impact of switching to match 
Blink and WebKit always?

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

[OUTAGE] Phabricator (phabricator.services.mozilla.com) to be down for maintenance on Sat Mar 13th at 12:00 PM EST (17:00 UTC)

[David Lawrence]

On Saturday, March 13th, at 12:00PM EST (17:00 UTC), Phabricator will be 
taken down for a period

of two hours for database maintenance.

A recent upstream migration requires a change to one of the larger 
tables that could cause Phabricator
to be unresponsive. So we decided best to do the changes during off 
hours. Also, taking the system
down will allow us to roll back to a database backup if  any issues 
occur.


Systems affected:
* https://phabricator.services.mozilla.com - Phabricator will be 
unavailable during the database upgrade.
* https://lando.services.mozilla.com - Lando requires access to 
Phabricator for various tasks so it

  should not be used during the outage.
* https://bugzilla.mozilla.org - Bugzilla displays current revision data 
in some bug reports so that

  functionality could be affected.

For any comments or questions, you can find us in #phabricator on Slack.

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

Re: Intent to ship: Return pixel deltas in wheel event if deltaMode is not checked by authors

[Emilio Cobos Álvarez]

On 3/9/21 20:36, James Graham wrote:

It seems like having all browsers have the same behaviour is going to be
better in the long run than having some weird heuristic in gecko that
acts as a footgun for authors going forward.

Do we have any way to assess the compat impact of switching to match
Blink and WebKit always?


Not an easy one that I can think at least. We can measure how often 
pages access the deltas without the deltaMode or vice versa, but it's 
not clear to me how to correlate that to broken or good behavior easily.


I guess we could enable the always-disabled pref on Nighly and watch for 
a few releases to see if there's reports of broken sites. Would that 
seem reasonable to you?


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

Re: Intent to ship: Return pixel deltas in wheel event if deltaMode is not checked by authors

[Karl Dubost]

Hello,

So about experimenting with wheelEvent…
Cool to see the work of Emilio in that space. 

Le 2021/03/10 à 07:13, Emilio Cobos Álvarez  a écrit :
> I guess we could enable the always-disabled pref on Nighly and watch for a 
> few releases to see if there's reports of broken sites. Would that seem 
> reasonable to you?

Yes we could do that. Webcompat will probably surface weird cases. 

There is a lot of user agent sniffing and weird heuristics going on on Websites 
to fix this kind of scrolling issues. 

Either people are afraid to switch to wheel, because they support 
mousewheel/DOMMouseScroll (ex: CodeMirror) or they try to fix the scrolling ( 
ex: svg.panzoom for a recent case)

Everything which goes into direction of simplifying the space will be great and 
webcompat will likely catch the outcome if it really breaks big sites or some 
libraries. 



https://github.com/svgdotjs/svg.panzoom.js/issues/67
https://github.com/svgdotjs/svg.panzoom.js/pull/68
https://github.com/svgdotjs/svg.panzoom.js/pull/68/files


-- 
Karl Dubost, mozilla 💡 Webcompat
http://www.la-grange.net/karl/moz





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

Intent to ship: aspect-ratio property

[Boris Chiou]

I intend to turn the preferred aspect ratio, `aspect-ratio`
 property, on by
default on all platforms after the last bug got landed (i.e. bug 1646098
), so the most
possible version should be Firefox 88. It has been developed behind the
layout.css.aspect-ratio.enabled preference. The spec should be stable
enough and CSSWG agrees to ship this feature (csswg-drafts#5598
).

Status in other browsers:
Google Chrome: Ship already last Oct. (Chromium intent to ship mail
)
Safari: Implementing this feature, and has supported this in Safari
Technology Preview.

*Bug to turn on by default*:
https://bugzilla.mozilla.org/show_bug.cgi?id=1672073

There are bunch of wpts already in
https://github.com/web-platform-tests/wpt/tree/master/css/css-sizing/aspect-ratio

This feature was previously discussed in this "Intent to prototype"
thread:
https://groups.google.com/g/mozilla.dev.platform/c/mWViuwFw8b8/m/HVHJ8yAnAAAJ

Please let me know if you have any concerns.

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

Intent to Ship: AV1 Still Image File Format (AVIF)

[Jon Bauman]

As of March 18, 2021, I intend to turn AVIF on by default all platforms in
Firefox 88. It has been developed behind the image.avif.enabled preference.
Though there's a good chance it'll be delayed until Firefox 89, depending
on some external factors.

AVIF is an image format based on the AV1 video codec
 from the Alliance for Open Media
. AV1 support shipped in release 55
 and is currently
supported in Chrome, but not Safari. The Chromium issue for AVIF support is
960620 .
Chrome shipped AVIF support in version 85 in August 2020. Among other
chromium-based browsers, Opera shipped in version 71 in September, 2020 and
Egde has yet to ship AVIF support. Safari has not shipped AVIF support yet
and has released no plans, but Apple is an active member of AOM and
initial AVIF
support recently landed in Webkit
. However, Safari is
unlikely to ship AVIF support until it appears in macOS. More details on
support in other browsers are available at https://caniuse.com/avif.

Bug to turn on by default:
https://bugzilla.mozilla.org/show_bug.cgi?id=1682995.

We are choosing to ship AVIF as an MVP with some features not yet
implemented, notably animations/image-sequences, grid-based image support,
image transforms (e.g., rotation, mirroring, etc.) and 10- and 12-bit image
support. Full details of what we intend to complete and leave incomplete
before shipping with AVIF enabled by default can be seen in the dependency
tree

for the AVIF meta bug 
.

This feature was previously discussed in this "Intent to implement" thread

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

New JavaScript engine module owner

[Jason Orendorff]

Hi, everyone.

I'm pleased to announce that Jan De Mooij has agreed to take ownership of
the JavaScript engine module.

Following a Mozilla tradition that was venerable when I got here, Jan has
been doing the job already for quite some time. Please join me in
congratulating Jan and thanking him for his ongoing leadership.

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

Re: New JavaScript engine module owner

[Giorgio Maone]

Congratulations, keep up the good work!
-- G

On 10/03/21 02:12, Jason Orendorff wrote:
> Hi, everyone.
>
> I'm pleased to announce that Jan De Mooij has agreed to take ownership of
> the JavaScript engine module.
>
> Following a Mozilla tradition that was venerable when I got here, Jan has
> been doing the job already for quite some time. Please join me in
> congratulating Jan and thanking him for his ongoing leadership.
>
> Sincerely,
> Jason
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform


-- 
Giorgio Maone
https://maone.net

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

Re: New JavaScript engine module owner

[Andy Wingo]

On Wed 10 Mar 2021 02:12, Jason Orendorff  writes:

> I'm pleased to announce that Jan De Mooij has agreed to take ownership of
> the JavaScript engine module.

Congratulations rather to you & commiserations to Jan ;)

What am I saying, congrats all around! :)

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