Windows has different driver version semantics than other platforms. We
shouldn't pad the driver versions the same way on Linux/OSX/Android for
our blocklist rules and instead just take the numbers as given. This
really only impacted Linux since it had numerous blocklist rules which
depending on the vendor or Mesa driver versions.
Differential Revision: https://phabricator.services.mozilla.com/D138905
This also disables smooth scrolling in the interaction tests. When smooth scrolling
is enabled a single scroll, say by pressing the down arrow, actually scrolls in
a number of steps starting small, increasing then decreasing. Because we only
wait for a single scroll event to fire before the test switches pages we only
capture the scrolling distance from the very first step which is often small and
sometimes turns out to be 0. Disabling smooth scrolling makes the scroll happen
in one operation so we capture the entire scrolling distance. However we are
then also racing to capture the single scroll event so must add the event
listener before triggering the scroll.
Differential Revision: https://phabricator.services.mozilla.com/D138295
:whimboo found this, apparently if something else holds a reference to
permanentKey we will leak the window. To avoid this happening we use the JSM
global instead.
For more context see Bug 1501789.
Differential Revision: https://phabricator.services.mozilla.com/D138451
When both the current and the earlier props for a given property name are inherited, the current prop should not be marked as overridden if the earlier prop was marked as !important.
!important should only come into play if the property where it was set is not inherited.
Regardless of this, properties are considered in descending order of specificity, so the earlier rule should take precedence.
Differential Revision: https://phabricator.services.mozilla.com/D138895
Note that it's not 100% clear whether this bug is responsible for the
improvement or not, but given it's an improvement...
MANUAL PUSH: Unexpected pass CLOSED TREE
This basically undoes bug 1246346. The current behavior is pretty bizarre,
the screenX origin / position doesn't match the mouse event coordinates,
because on windows we return device pixels rather than CSS pixels for the
window coordinates.
This makes behavior consistent with how other browsers report these coordinates
at least on Windows in non-mixed DPI mode, and I think is fine.
In mixed DPI mode, there might indeed be overlapping coordinates, but again I
think that's fine, because the CSS coordinate space of the different monitors
is different. You need to multiply by the devicePixelRatio if you want
coordinates not to overlap.
Depends on D138039
Differential Revision: https://phabricator.services.mozilla.com/D138130
Device pixels and desktop pixels are not the same on macOS and Win7.
Expose the desktop-to-device scale to JS and use it appropriately.
Depends on D138038
Differential Revision: https://phabricator.services.mozilla.com/D138039
Android has no full-page zoom, so we are not meaningfully changing behavior.
However, these values are exposed to the GeckoView JS api, surprisingly, yet
viewport scaling and so on can change the CSS to device pixel ratio...
Shouldn't we expose device pixels there instead? Or do the api consumers assume
that those CSS pixels are scaled to the device scale factor somehow (and that's
not working)?
Depends on D138037
Differential Revision: https://phabricator.services.mozilla.com/D138038
If the page is zoomed, its devicePixelRatio will differ from the browser
chrome's. Account for this by converting to device pixels before starting to
scroll.
Depends on D138036
Differential Revision: https://phabricator.services.mozilla.com/D138037
If the page is zoomed, its devicePixelRatio will differ from the browser
chrome's. Account for this by converting to device pixels before starting to
scroll.
Depends on D138035
Differential Revision: https://phabricator.services.mozilla.com/D138036
We report window.screen coordinates in CSS space, so it makes sense to do
the same for screen-relative offsets. This requires some front-end fixes
incoming in following patches.
Differential Revision: https://phabricator.services.mozilla.com/D138035
This patch changes the way we parse JavaScript coming from Necko while loading
web pages, by adding an about:config flag named
javascript.options.delazification.strategy which is used to select between:
0 - On Demand
1 - Concurrent Depth First
255 - Parse Everything Eagerly
Previously, we moved from On-demand delazification, to parsing everything
eagerly to improve responsiveness of the browser, but we knew that more room for
optimization exists.
This toogle is meant to explore the space of delazification strategies, such
that we can parse functions of JavaScript files on an helper thread, while the
JavaScript file is being executed on the main thread. The space of
delazification strategies goes from ordering the order in which functions are
processed, as well as filtering functions which are processed. Not all functions
have to be delazified, and if the main thread needs a function which is not
parsed yet, it will fallback to parsing it on-demand.
Differential Revision: https://phabricator.services.mozilla.com/D138034
Also the test skipped checking iframe messages in the Browser Console, but it's
been a while since we fixed the issue mentionned there, so we can safely also
test the Browser Console.
Differential Revision: https://phabricator.services.mozilla.com/D138781
Sean Feng
ahochheiden
Nicholas Rishel
Bob Owen
Emilio Cobos Álvarez
Barret Rennie
Andrew Osmond
Dave Townsend
Butkovits Atila
Marian-Vasile Laza
Agi Sferro
Jeff Muizelaar
asharma
Bryan Thrall
Jens Stutte
Lars T Hansen
Mirko Brodesser
Julian Descottes
Olli Pettay
Sarah Clements
Claudia
Paul Adenot
Jan Varga
Makoto Kato
Nicolas B. Pierron
Henrik Skupin
Itiel
Nicolas Chevobbe