In addition to the visual improvement, these icons help the responsive design of the page, because if it becomes too narrow the sidebar labels will disappear and only the icons will be displayed
We're seeing a substantial amount of paint misses caused by
MissedComposite. This splits MissedComposite into subcategories
based on the full paint time.
Differential Revision: https://phabricator.services.mozilla.com/D15241
--HG--
extra : moz-landing-system : lando
As discussed on IRC this is hard to trigger, but this is more consistent with
the cross-compartment code.
Differential Revision: https://phabricator.services.mozilla.com/D15214
--HG--
extra : moz-landing-system : lando
This is consistent with what we do for cross-compartment wrappers and avoids
problems with running jobs against a dying global (Gecko drops such jobs).
I added a globalOfFirstJobInQueue() shell function so I could write a test that
checks both the compartment-per-global and single-compartment cases.
Differential Revision: https://phabricator.services.mozilla.com/D15176
--HG--
extra : moz-landing-system : lando
Now that the upload-* kinds inherit `run-on-projects`, we don't need to special
case handling of them in target-tasks.
Differential Revision: https://phabricator.services.mozilla.com/D15153
--HG--
extra : moz-landing-system : lando
The optimization doesn't actually do what it claims. For the optimization to be
considered, a task needs to be in the target graph, but then all the
dependencies will be too, which inhibits this optimization.
Differential Revision: https://phabricator.services.mozilla.com/D15151
--HG--
extra : moz-landing-system : lando
Nightly is reporting mozglue.dll as being untrusted in the untrusted modules
ping. Until now, xpcshell tests hard-code mozglue to appear as untrusted in
order to cover certain code paths related to startup modules.
This patch:
1. Checks explicitly for the xpcshell environment and only applies this logic
during xpcshell tests.
2. Uses a purpose-build DLL, "untrusted-startup-test-dll.dll", instead of
mozglue. This is more explicit and doesn't interfere with any "true"
processing of mozglue.
Differential Revision: https://phabricator.services.mozilla.com/D14720
--HG--
extra : moz-landing-system : lando
Adds a new flag for evaluating DLL trustworthiness:
ModuleTrustFlags::WinSxSDirectory
This flag indicates that the DLL was loaded from the WinSxS folder. This
grants a trustworthiness equal to that of ModuleTrustFlags::SystemDirectory, in
particular allowing some Microsoft DLLs, like comctl32.dll, to be considered
trusted so they don't appear in the untrusted modules ping.
Differential Revision: https://phabricator.services.mozilla.com/D15106
--HG--
extra : moz-landing-system : lando
This function is invoked elsewhere in this file as "::ParseNumber(...)", which
only works if it's declared outside of any namespace. So, it needs to be moved
outside of the mozilla namespace in order to be referenced that way (and to be
truly a static function that's private to this .cpp file).
I'm not sure why this builds at all in unified mode, but however it works, it's
cheating, apparently.
Also: this patch adds a 'using' statement for the mozilla namespace, for
e.g. the RangedPtr usages in this function definition (since it no longer lives
inside of a namespace mozilla{} block).
Depends on D15232
Differential Revision: https://phabricator.services.mozilla.com/D15233
--HG--
extra : moz-landing-system : lando
And while I'm here, I'm giving SVGDataParser.h a more specific/efficient string
include, to just provide the *forward-decl* of nsAString for this file's
"nsAString&" usage in a function prototype.
Depends on D15231
Differential Revision: https://phabricator.services.mozilla.com/D15232
--HG--
extra : moz-landing-system : lando
These are to support of usages of "SVGElement" in these files, so they
problably only started needing this namespace as of bug 1515187. In any case,
they're currently relying on picking up this "using" statement from other files
in unified builds, so let's just make the usage explicit by giving them their
own "using" statement.
Also, I'm fixing up the #include for SVGElement.h in these files to use the
full mozilla/dom include path (and to make these files include their own .h
file first).
Differential Revision: https://phabricator.services.mozilla.com/D15231
--HG--
extra : moz-landing-system : lando