When compiling without ENABLE_TESTS, the following error occurs:
/toolkit/xre/ModuleEvaluator_windows.cpp(221,20): error: redefinition of
'scoreThreshold' with a different type: 'const int' vs 'int'
This removes the 2 lines of code that caused the error.
Differential Revision: https://phabricator.services.mozilla.com/D15372
--HG--
extra : moz-landing-system : lando
According to the log of bug 1498823, ibus won't set IBUS_IGNORED_MASK to
modifier flags when it synthesizes the event for asynchronous handling in
some environments.
Currently, we assume that iBus and Fcitx set IBUS_IGNORED_MASK or
FcitxKeyState_IgnoredMask. So, we put both real key events and synthesized
key events into the posting event queue and that causes using a lot of
memory until the editor is blurred. Fortunately, timestamp of synthesized
key events are always same as their original events. Therefore, we can look
for original event from the positing event queue.
Although we have gotten no bug reports about this issue of Fcitx, but this
patch adds same hack for Fcitx too because the runtime cost is not
expensive but the symptom is really serious.
Differential Revision: https://phabricator.services.mozilla.com/D15321
--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
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
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
This helper code is currently unused, and presents a pretty significant
footgun for any JS object which implements nsIPropertyBag itself.
When those objects are first queried to nsIWritablePropertyBag, they behave as
expected, returning the JS-implemented nsIPropertyBag methods. But when
they're first queried to nsIPropertyBag, they use the XPCWrappedNative stubs,
which don't behave as expected.
Differential Revision: https://phabricator.services.mozilla.com/D15235
--HG--
extra : rebase_source : 02942592dc8c4efcc1190610448a46593faa5703
Instead of opening the pop-up permissions dialog with the origin already populated, this command now highlights the pop-up permission row in the preferences. This doesn't remove any functionality because the only action that would be available for the origin in the permissions dialog is "Allow", which is equivalent to the "Allow pop-ups for" command in the notification bar menu.
Differential Revision: https://phabricator.services.mozilla.com/D15066
--HG--
extra : rebase_source : 064b3d39dc2a8c4d6a3c0949a51ab361ed6e71dd
Luca Greco
Dão Gottwald
Edwin Gao
Carl Corcoran
Masayuki Nakano
Cameron McCormack
Ciure Andrei
sharath
Jared Wein
Jeff Muizelaar
Raul Gurzau
Bogdan Tara
Ehsan Akhgari
WR Updater Bot
longsonr
arthur.iakab
Jan de Mooij
Cosmin Sabou
Andreea Pavel
Tom Prince
inspiro
Daniel Holbert
Kris Maglione
Paolo Amadini