This method turned out to only be used for tracing wrapper cached things. The wrapper cache has its own way of implementing barriers and contains a raw JSObject pointer. Changing this trace method to take an nsWrapperCache pointer (effectively a JSObjct**) enforces correct use of Heap<T> for other TraceCallbacks callers.
Differential Revision: https://phabricator.services.mozilla.com/D48693
--HG--
extra : moz-landing-system : lando
This was disabled in Bug 1441558 because it broke the mingw-gcc build.
But it doesn't break the mingw-clang build, and we don't support mingw-gcc
anymore, so we can re-enable it.
Differential Revision: https://phabricator.services.mozilla.com/D48645
--HG--
extra : moz-landing-system : lando
This replaces the old DOMWindowCreated event, and allows SpecialPowers to still
be instantiated for each new chrome document.
Differential Revision: https://phabricator.services.mozilla.com/D47337
--HG--
extra : moz-landing-system : lando
The duration file downloader uses the cache directory created by taskgraph generation.
Differential Revision: https://phabricator.services.mozilla.com/D48705
--HG--
extra : moz-landing-system : lando
`preEvent` isn't used anymore, but was somehow
replaced by `before`. This patch remove all the
mentions of `preEvent`, and tries to document
what can be done with `before`.
Differential Revision: https://phabricator.services.mozilla.com/D48068
--HG--
extra : moz-landing-system : lando
Finally, `Document.execCommand()` still does not work fine if selection
starts from very start of block and/or end at very end of block because
`PromoteInlineRange()` extends selection range to contain the
containers, then, `SubtreeContentIterator` won't list up text nodes.
In this case, `RemoveInlinePropertyInternal()` expects that
`RemoveStyleInside()` removes text node style with creating
`<span>` elements. However, `RemoveStyleInsilde()` only handles
`Element`s and it handles elements from most-descendants.
Therefore, it cannot distinguish whether text node style comes
from removing inline elements or parent block.
This patch makes `RemoveInlinePropertyInternal()` collect
descendant text nodes in the range after handling all nodes in
the range except descendant text nodes, then, check the
final style of descendant text nodes, finally, remove the style
if coming from parent block.
Differential Revision: https://phabricator.services.mozilla.com/D47865
--HG--
extra : moz-landing-system : lando
The root marking functions have assertions that will catch this being used outside of heap marking.
Differential Revision: https://phabricator.services.mozilla.com/D48534
--HG--
extra : moz-landing-system : lando
GCPolicy<T> calls the instance method for these types so these static methods aren't required.
Differential Revision: https://phabricator.services.mozilla.com/D48533
--HG--
extra : moz-landing-system : lando
The warm-up count is stored in ScriptWarmUpData until the script is warm
enough for the Baseline Interpreter and the JitScript is created. At that point
we use the warm-up count stored in JitScript.
ScriptWarmUpData uses pointer tagging. This should make it easy to add new
types for LazyScript data in the future.
Differential Revision: https://phabricator.services.mozilla.com/D42319
--HG--
extra : moz-landing-system : lando
Protocol.js's Front and Pool's destroy are not expected to be async.
But TargetMixin.destroy is. It makes DebuggerClient.close do not wait
for all Target fronts destroys correctly. The client close method calls
the cleanup method of all the pools. Top level fronts are pools.
Target fronts are still self managed and so are pools.
And so, when we close the toolbox, the target destroy is still pending
after toolbox.destroy is resolved.
Differential Revision: https://phabricator.services.mozilla.com/D46221
--HG--
extra : moz-landing-system : lando
This will later allow dynamically change this value for local tabs,
during Fission processes switches.
Differential Revision: https://phabricator.services.mozilla.com/D48070
--HG--
extra : moz-landing-system : lando
The changes are just cleanup for member variables/methods that should
be private to ServiceWorkerManager.
Differential Revision: https://phabricator.services.mozilla.com/D48181
--HG--
extra : moz-landing-system : lando
Also replace ServiceWorkerManager shutdown logic's normal for-loops with
range-based for-loops.
Differential Revision: https://phabricator.services.mozilla.com/D48179
--HG--
extra : moz-landing-system : lando
Due to limitations in the test harness, the "serviceworker_e10s" (for mochitest
and xpcshell) and "sw-e10s" (for WPT) values will match mozinfo's "nightly_build"
value, unless overridden by "--setpref dom.serviceWorkers.parent_intercept=..."
provided at the CLI.
Differential Revision: https://phabricator.services.mozilla.com/D43170
--HG--
extra : moz-landing-system : lando
- Listen for observer topics in the parent-process when in parent intercept mode
- Remove an extra postMessage call (and the corresponding message handler)
Differential Revision: https://phabricator.services.mozilla.com/D44513
--HG--
extra : moz-landing-system : lando
Adds a way for mochitest, reftest, and crashtests to skip XBL related
tests when XBL is disabled. Also, add an app constant so JS can
check whether XBL is enabled.
Depends on D45614
Differential Revision: https://phabricator.services.mozilla.com/D45615
--HG--
extra : moz-landing-system : lando
Adds a feature "moz_xbl" that when disabled causes the XBL code in servo to
be stubbed out.
Depends on D45613
Differential Revision: https://phabricator.services.mozilla.com/D45614
--HG--
extra : moz-landing-system : lando
When XBL is disabled, no code in dom/xbl will be built. Also, adds ifdefs
to remove any of the XBL related code elsewhere. There's definitely more
that can be done here, but I think it's better to wait to do the rest of
the cleanup when we actually remove the code.
Depends on D45612
Differential Revision: https://phabricator.services.mozilla.com/D45613
--HG--
extra : moz-landing-system : lando
Previously, Service Workers could spawn in a process that isn't subscribed
to permission updates, which could happen if that process hadn't loaded any
same-origin documents. To address this, parent-process logic for spawning
Service Workers would snapshot the permissions state to be sent to a content
process.
Unfortunately, this approach could lead to outdated, unsynchronized permissions.
Note that nsIPermissionManager::SetPermissionsWithKey is only used to initialize
permissions for a given key and is a no-op if already called with the same key
in a given process. As a result, the following sequence of events could happen:
Assume a content process CP that isn't subscribed to permission changes for an
origin A:
1) Parent process decides to spawn an origin A Service Worker in CP,
snapshotting a value V for permission P.
2) The Service Worker is spawned in CP, setting CP's permission manager's
permission P to value V (for origin A).
3) Parent process updates its permission P to a value A', which is not
broadcasted to CP (because it's not subscribed).
4) By now, the initial Service Worker has been terminated, and the parent
process decides once again to spawn an origin A Service Worker in CP.
5) The Service Worker is spawned in CP, but the call to SetPermissionsWithKey
is a no-op, leaving CP1 with a mismatched value for permission P.
An additional scenario is if the parent process updates a permission during a
remote Service Worker's lifetime.
This patch, which would subscribe CP1 to permission updates when the parent
process knows a Service Worker would be spawned in CP1, prevents these problems.
Differential Revision: https://phabricator.services.mozilla.com/D48620
--HG--
extra : moz-landing-system : lando
