It seems on OSX the default is somehow not zero. This matches
equivalent code for regular paged reftests in
layout/tools/reftest/reftest-content.js
MANUAL PUSH: Orange fix
CLOSED TREE
Differential Revision: https://phabricator.services.mozilla.com/D90280
In order to fix bug 1657822 we need to run some reftests with the pref ui.useOverlayScrollbars. This preference doesn't have a default value (it is not set by anything on desktop, it appears only in mobile/android/app/mobile.js and when we set the pref for some mochitests, the look and feel code looks at this pref, which is how we almost (?) always query for overlay scrollbars.). The reftest harness doesn't currently handle this because it gets the current value first and doesn't expect the pref to not exist.
Differential Revision: https://phabricator.services.mozilla.com/D89399
Today we don't require that `mach` `CommandProvider`s subclass from any particular parent class and we're very lax about the requirements they must meet. While that's convenient in certain circumstances, it has some unfortunate implications for feature development.
Today the only requirements that we have for `CommandProvider`s are that they have an `__init__()` method that takes either 1 or 2 arguments, the second of which must be called `context` and is populated with the `mach` `CommandContext`. Again, while this flexibility is occasionally convenient, it is limiting. As we add features to `mach`, having a better idea what the shape of our `CommandProvider`s are and how we can instantiate them and use them is increasingly important, and this gives us additional control when having `mach` configure `CommandProvider`s based on data that is only available at the `mach` level. In particular, we plan to leverage this in bugs 985141 and 1654074.
Here we add validation to the `CommandProvider` decorator to ensure all classes inherit from `MachCommandBase`, update all `CommandProvider`s in-tree to inherit from `MachCommandBase`, and update source and test code accordingly.
Follow-up work: we now require (de facto) that the `context` be populated with a `topdir` attribute by the `populate_context_handler` function, since instantiating the `MachCommandBase` requires a `topdir` be provided. This is fine for now in the interest of keeping this patch reasonably sized, but some additional refactoring could make this cleaner.
Differential Revision: https://phabricator.services.mozilla.com/D86255
This hooks the "monochrome" media query and co to the
nsIPrintSettings.printInColor setting.
This print setting we're using is not exposed in the print preview UI,
but you can test it setting the print.print_in_color preference to
"false", and then print preview will correctly show up greyscale'd.
Once this lands, the UI folks just have to use it as they see fit :)
I would've liked to add a proper rendering test, but the print reftests
check only whether the PDF text matches.
I could add a test to printpreview_helper.xhtml, but I'm refactoring
that file in bug 1648064 so I'd rather wait a bit and add it in a
separate bug. The test for the media feature should make sure that we
test that code path at least.
Differential Revision: https://phabricator.services.mozilla.com/D83552
The previous patch stops us from firing the load event if we abort a load. We have a few crashtests that abort loads (either by directly calling stop(), or by starting a new navigation before load completes).
This switches the reftest harness to use web progress to determine when we've finished loading a test.
Differential Revision: https://phabricator.services.mozilla.com/D73995
The previous patch stops us from firing the load event if we abort a load. We have a few crashtests that abort loads (either by directly calling stop(), or by starting a new navigation before load completes).
This switches the reftest harness to use web progress to determine when we've finished loading a test.
Differential Revision: https://phabricator.services.mozilla.com/D73995
The previous patch stops us from firing the load event if we abort a load. We have a few crashtests that abort loads (either by directly calling stop(), or by starting a new navigation before load completes).
This switches the reftest harness to use web progress to determine when we've finished loading a test.
Differential Revision: https://phabricator.services.mozilla.com/D73995
* update paths to test manifest and user.js after Bug 1596567.
* make sure to use root=True when checking for existence of reftest.log.
* work around permissions errors when pushing to /data/local/tests.
* Properly handle symbolic links to the JavaScript tests for desktop
and remote Android tests.
Differential Revision: https://phabricator.services.mozilla.com/D69313
The startup script starts by searching a window by its type; how the window type parameter is only available once the window's document element has been created.
The main window has already been created however and it is in an in-between state which means that you can't find it by its type nor will domwindowcreated be fired.
So we listen to either initial-document-element-inserted which indicates when it's okay to search for the main window by type again and we are ready to start the reftest.
Differential Revision: https://phabricator.services.mozilla.com/D72142
We need it to live in BrowsingContext instead of WindowContext, because
we need to preserve the zoom level across same-origin navigation.
It'd be nice if it only lived in the top BC, but that's not possible at
the moment because a lot of tests rely on zooming only iframes. Some of
them can be adjusted for scaling the top instead, but not sure it's
worth it's worth fixing them and moving the zoom to be top-only, as it'd
be a bunch of effort, and the complexity and overhead of propagating the
zoom is not so big.
The print-preview-specific code in nsContentViewer is from before we did
the document cloning setup, and it seems useless. I've tested print
preview scaling before and after my patch and both behave the same.
The rest is just various test changes to use the SpecialPowers APIs or
BrowsingContext as needed instead of directly poking at the content
viewer.
I named the pres context hook RecomputeBrowsingContextDependentData, as
more stuff should move there like overrideDPPX and other media emulation
shenanigans.
I also have some ideas to simplify or even remove ZoomChild and such,
but that's followup work.
Differential Revision: https://phabricator.services.mozilla.com/D71969