The test failing intermittently on test-verify jobs seems to be only the one that covers the newly added
Glean timespan metric named "extensions.startupCacheLoadTime".
Given that it seems to be only failing in test-verify jobs, and with the Glean metric set to a numeric value as expected
just not always a non-zero value as the test expectes, I suspect it may be because the startupCache is technically
empty or only including a pretty small amount data and so it may be able to be loaded so fast that the resulting
value is 0 milliseconds.
I'm unable to reproduce the same locally even when running the test locally using --verify, and so this patch
is actually relaxing the failing assertion to only check that the Glean metric value is numeric and the
mirror scalar is set to the exact same value, and in addition to that the test is not reseting the FOG data
and assert that the Glean metric is initially undefined until we expect it to be collected and set to a numeric value.
Differential Revision: https://phabricator.services.mozilla.com/D145904
Switch back to SW decode when frame decode time and averange decode time is bigger
than frame interval for defined number of frames.
Differential Revision: https://phabricator.services.mozilla.com/D145871
The scroll snap spec defines the concepts [1]. There are three type of scroll
operations. 1) intended end position, 2) intended direction and end position
and 3) intended direction.
Basically our existing ScrollUnits types correspond;
1) DEVICE_PIXELS, WHOLE => intended end position
2) PAGES => intended direction and end position
3) LINES => intended direction
There are two exceptions in the `intended direction and end position` case,
scrollBy() and fling gestures (on Linux). They were defined as scroll operations
with DEVICE_PIXELS unit, but the spec cleary says they are `intended direction
and end position` operations.
Note that we will also use this information for scroll-snap-stop property since
the properly will only have effects on both 2) and 3) cases.
[1] https://drafts.csswg.org/css-scroll-snap/#scroll-types
Depends on D145190
Differential Revision: https://phabricator.services.mozilla.com/D145191
We might want to look into this further and see if it can be supported, but for now at least
the safest option is to disable any attempt by Gecko to render such glyphs.
(Actually, in some cases they may work anyhow, if they're natively supported by the system font
rasterizer we're using; I'm seeing this on current macOS thanks to Core Text. Maybe at some point
we can switch off our SVG-glyph code altogether and just rely on the platform.)
Differential Revision: https://phabricator.services.mozilla.com/D146052
Persist dictionary preference in document content language field for mail editors so multiple dictionary selection can persist.
Differential Revision: https://phabricator.services.mozilla.com/D144935
The scroll snap spec defines the concepts [1]. There are three type of scroll
operations. 1) intended end position, 2) intended direction and end position
and 3) intended direction.
Basically our existing ScrollUnits types correspond;
1) DEVICE_PIXELS, WHOLE => intended end position
2) PAGES => intended direction and end position
3) LINES => intended direction
There are two exceptions in the `intended direction and end position` case,
scrollBy() and fling gestures (on Linux). They were defined as scroll operations
with DEVICE_PIXELS unit, but the spec cleary says they are `intended direction
and end position` operations.
Note that we will also use this information for scroll-snap-stop property since
the properly will only have effects on both 2) and 3) cases.
[1] https://drafts.csswg.org/css-scroll-snap/#scroll-types
Depends on D145190
Differential Revision: https://phabricator.services.mozilla.com/D145191
This will still prevent them from accessing stuff (.length will be
undefined, etc), but seems better than unexpectedly throwing. This fixes
the issue at hand at least.
With this patch, we reject length accesses here:
https://searchfox.org/mozilla-central/rev/86c98c486f03b598d0f80356b69163fd400ec8aa/js/xpconnect/wrappers/XrayWrapper.cpp#229-233
Your call on whether this patch is enough as-is, or more work is needed.
Also your call on whether if more work is needed that needs to happen on
this bug or somewhere else.
I'm not sure what we'd need to do to support this more "properly",
presumably we'd need to add special XRay support to
ObservableArrayProxyHandler or so? Pointers (or patches of course ;))
welcome.
Also unsure about the setter situation, I _think_ it's fine not to throw
given the code I read, but please sanity-check.
Differential Revision: https://phabricator.services.mozilla.com/D145045
Since Bug 1732739, "session change handling of window occlusion on Windows" is enabled until early beta. And no regression was reported. Then it seems OK to enable it until release.
Differential Revision: https://phabricator.services.mozilla.com/D145193
Matthew Gaudet
Jens Stutte
Luca Greco
Henrik Skupin
Nika Layzell
Nicolas B. Pierron
Mike Kaply
R. Martinho Fernandes
Narcis Beleuzu
Norisz Fay
Sergey Galich
Andrew Osmond
Bogdan Szekely
lyavor
Emilio Cobos Álvarez
Meg Viar
stransky
Hiroyuki Ikezoe
Andrew McCreight
Jonathan Watt
Jonathan Kew
Joel Maher
Nicolas Silva
Dão Gottwald
ui.sayuree
Martin Giger
Jan de Mooij
Alex Finder
Mozilla Releng Treescript
sotaro
Kelsey Gilbert
criss
Alexandre Lissy
Eitan Isaacson