Refactor the test to use a python program to check that the background was successfully changed and re-enable the test on macOS.
For running in automation, this test is dependent on Mac test runner instances being configured to allow users to change the desktop background. A code change to allow this has already been landed. See bug for the additional patches.
Differential Revision: https://phabricator.services.mozilla.com/D72456
The changes in bug 1507352 caused onLocationChange events to be ignored
when there was an http redirect. This caused the screenshot command to hang
since it never attached an event listener on the page it was redirected to.
Differential Revision: https://phabricator.services.mozilla.com/D22220
Currently for any screen with a ratio 1.6 or above, the preview uses a 16:10
image. However, the majority of Fx users have a screen that is 16:9[0], so for
most users the preview shows images distorted (compressed horizontally).
Originally I just added a new 16:9 version of the monitor image, but then I
realised I could save on filesize _and_ make it responsive to whatever the
user's screen actually is, rather than using arbitrary presets, by using
border-image.
The new image files are just sliced up versions of the original monitor.png
files, zopfli compressed to match (though with the power indicator dropped from
the Linux/Windows version to avoid distorting it). The combined filesize
savings seem to be 8.5KiB on macOS and 6.5KiB on Linux/Windows.
With the removal of the use of margins on the canvas we no longer need the
platform-specific setDesktopBackground.css file.
[0] https://data.firefox.com/dashboard/hardware
As of 3rd March 2019 the top three resolutions, 1366x768, 1080p, & 1600x900,
are all 16:9 and make up 67% of the userbase.
Differential Revision: https://phabricator.services.mozilla.com/D23114
Currently for any screen with a ratio 1.6 or above, the preview uses a 16:10
image. However, the majority of Fx users have a screen that is 16:9[0], so for
most users the preview shows images distorted (compressed horizontally).
Originally I just added a new 16:9 version of the monitor image, but then I
realised I could save on filesize _and_ make it responsive to whatever the
user's screen actually is, rather than using arbitrary presets, by using
border-image.
The new image files are just sliced up versions of the original monitor.png
files, zopfli compressed to match (though with the power indicator dropped from
the Linux/Windows version to avoid distorting it). The combined filesize
savings seem to be 8.5KiB on macOS and 6.5KiB on Linux/Windows.
With the removal of the use of margins on the canvas we no longer need the
platform-specific setDesktopBackground.css file.
[0] https://data.firefox.com/dashboard/hardware
As of 3rd March 2019 the top three resolutions, 1366x768, 1080p, & 1600x900,
are all 16:9 and make up 67% of the userbase.
Differential Revision: https://phabricator.services.mozilla.com/D23114
Usually the brandName is a single word like "Firefox" or "Nightly" but
DevEdition's is "Firefox Developer Edition", so on mozilla-beta the filename can
be written with spaces, which GSettings will return percent encoded in a file://
URL so we need to match that.
Differential Revision: https://phabricator.services.mozilla.com/D22746
Bug 1498274 removed the enclosing groupbox, which also removed the XBL box that
bounded the image size. Add a vbox to do so.
Also add a test that checks the image's sizes match its natural sizes.
Differential Revision: https://phabricator.services.mozilla.com/D20547
It seems like none of the Linux test runners lack GSettings, so effectively this
test hasn't actually been testing anything for a while.
Differential Revision: https://phabricator.services.mozilla.com/D20546
Currently the test fails since it throws "TypeError: content is null". This
hasn't been noticed since this test only runs when gsettings is absent and
presumably all the test machines have it.
Differential Revision: https://phabricator.services.mozilla.com/D20545
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
This has no material impact on whether the test fails or passes, but it
is a waste of effort to package headless.html inside chrome.ini and then
fail to link to it properly when running the test.
Depends on D11969
Differential Revision: https://phabricator.services.mozilla.com/D11963
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG