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
With same-compartment chrome globals these would end up in the same compartment.
We need to prevent that because the debugger doesn't support it.
Differential Revision: https://phabricator.services.mozilla.com/D15093
--HG--
extra : moz-landing-system : lando
This patch adds a cron task to regularly schedule an update to the custom d8/v8 version in use in jsshell benchmarks.
Differential Revision: https://phabricator.services.mozilla.com/D15256
--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
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
If we QI nsIPropertyBag on an XPCWrappedNative wrapping an XPCWrappedJS, calling
the getProperty method might incorrectly end up calling .getProperty on the
XPCWrappedJS itself, because it also implements nsIPropertyBag.
This became a problem with same-compartment chrome globals because if we no longer
cross a compartment boundary, we don't create a new WrappedNative and can now end up
seeing the nsIPropertyBag if it got queried before nsIWritablePropertyBag.
Depends on D15076
Differential Revision: https://phabricator.services.mozilla.com/D15077
--HG--
extra : moz-landing-system : lando
It was added in case there were CDN issues with downloading unthrottled and
since there haven't been any issues it is no longer needed.
This was suggested by rstrong and simplifies the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D15076
--HG--
extra : moz-landing-system : lando
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
It perhaps makes more sense to use the start of refresh but I'd like to switch
to the start of the paint so that we get more consistent results between the
two probes.
Differential Revision: https://phabricator.services.mozilla.com/D15236
--HG--
extra : moz-landing-system : lando
This hopefully will address the test-verify failures that were reported in bug 1516006.
--HG--
extra : rebase_source : d01139f16469c631eb047d21e998dfaf0d58c3a5
extra : amend_source : 8543fd2e10bf485cabaf45dfac156e6b9094ea41
RectAbsolute contained a MoveBy(Point) function where Point was not a
template parameter but the actual gfx::Point type. This seems to be an
unintentional copy/paste error. This patch fixes it to be properly
templated.
Differential Revision: https://phabricator.services.mozilla.com/D15135
--HG--
extra : moz-landing-system : lando
