Bug 1544105 added a default implementation of `GfxInfoBase::FindMonitors` so
`gfxInfo.getMonitors()` no longer throws on Linux, but it only ever returns the
primary monitor there.
Differential Revision: https://phabricator.services.mozilla.com/D30096
--HG--
extra : moz-landing-system : lando
When I implemented the no preview for span I did originally try using text in
the canvas, but discarded it when I realised trying to format it to display
nicely (across different languages and text lengths) was a losing proposition.
However just the prohibition symbol without context is confusing to users, and
on reflection the text can easily be included as an element stacked on top of
the canvas.
Also lighten the background of the no preview message, since the pure black was
indistinguishable from the frame sides on Windows and Linux.
Differential Revision: https://phabricator.services.mozilla.com/D29750
--HG--
extra : moz-landing-system : lando
Removed all occurences of ondialogaccept.
Removed all occurences of ondialogcancel.
Replaced all removed attributes with event handlers.
Differential Revision: https://phabricator.services.mozilla.com/D21227
--HG--
extra : moz-landing-system : lando
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
--HG--
rename : browser/themes/linux/setDesktopBackground.css => browser/themes/shared/setDesktopBackground.css
extra : moz-landing-system : lando
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
--HG--
rename : browser/themes/linux/setDesktopBackground.css => browser/themes/shared/setDesktopBackground.css
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
***
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
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
These are two other cases where grouping is not really necessary. For accessibility, the checkbox at the end of the download interstitial dialog does not need to be in the same group as the radio button, and the question text can more simply just label the radiogroup. The vbox is still necessary to hide the section, but is not related to accessibility or dialog structure.
Differential Revision: https://phabricator.services.mozilla.com/D8421
--HG--
extra : source : b11d646505c15a1b9ecdcf4dc21199c13ed432c2
Automatic changes by ESLint, except for manual corrections for .xml files.
Differential Revision: https://phabricator.services.mozilla.com/D4439
--HG--
extra : moz-landing-system : lando
Move all of the overlay pieces into an include file except for the
DTD's that could not be put there. Inline the DTD's into the files
where they were used. Update comments in macWindow.inc.xul and browser.xul
to more accurately reflect the current state.
MozReview-Commit-ID: HZIeSf29Yl
--HG--
rename : browser/base/content/macBrowserOverlay.xul => browser/base/content/macWindow.inc.xul
extra : rebase_source : 5772943e01b4c6de7526ab829c6ea5b6960016e5
The overlay defined two elements (helpMenu, menu_ToolsPopup) for all
platforms and three others (windowMenu, baseMenuCommandSet, baseMenuKeyset)
that were MacOS only. The two all platform elements and windowMenu were only
used once and inlined into browser-menubar.inc. The rest of the MacOS only
elements were conditionally inlined into browser-sets.inc.
MozReview-Commit-ID: D2uyCrnepuH
--HG--
extra : rebase_source : a3f7ecaf70c55574ee87091027a651ce429c6876
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 {, <