Since the storage inspector is the last consumer of the VariablesView,
it makes sense to move the component directly in the storage inspector
folder.
Since it can't have a controller, the bits where we were checking this
are removed.
Differential Revision: https://phabricator.services.mozilla.com/D54734
--HG--
extra : moz-landing-system : lando
The holdings objects can be foreground or background finalized, but HeapPtr's destructor depends on the referent's arena to have not been released. Making FinalizationGroups foreground finalized achieves this.
Differential Revision: https://phabricator.services.mozilla.com/D55302
--HG--
extra : moz-landing-system : lando
Where a FinalizationGroup and its target are in different compartments they are linked by a CCW from a map in the target's zone to the FinalizationGroup. This deals with what happens if we nuke the CCWs between these two compartments. I think the sensible thing to do in this case is to not call the FinalizationGroup's callback and effectively forget about the registrations. Nuking CCWs happens when compartments are known to be dead and therefore this is similar to the way don't call callbacks on shutdown.
Depends on D55114
Differential Revision: https://phabricator.services.mozilla.com/D55115
--HG--
extra : moz-landing-system : lando
We perform this check in the first OnDataAvailable, instead of doing it in
OnStopRequest in case a network down event occurs after the data has arrived
but before we fire OnStopRequest. That would cause us to report a missing
networkID, even though it was not empty while receiving data.
Differential Revision: https://phabricator.services.mozilla.com/D55574
--HG--
extra : moz-landing-system : lando
The origin switch causes a process switch that makes us load about:blank first.
For the scope of the test we can just check we don't revert to the original url
and we finally set the expected one.
Differential Revision: https://phabricator.services.mozilla.com/D55524
--HG--
extra : moz-landing-system : lando
Rename acceptableSources to just sources, merge it with the existing sources property.
Differential Revision: https://phabricator.services.mozilla.com/D55082
--HG--
extra : moz-landing-system : lando
Summary of changes:
* Copy aboutDialog-appUpdater.js to a new aboutDialog-appUpdater-legacy.js file
* Update aboutDialog-appUpdater.js: Rewrite it to use the new AppUpdater.jsm when the `browser.aboutDialogNewAppUpdater` pref is true, and load aboutDialog-appUpdater-legacy.js otherwise
* In toolkit/mozapps/update/tests/browser, add new browser.legacy.ini and browser.legacy.bits.ini files that do not set `browser.aboutDialogNewAppUpdater` to true, so that the old implementation is still tested
* Update browser.ini and browser.bits.ini files to set `browser.aboutDialogNewAppUpdater` to true so that the new implementation is tested
If all this is OK, I'll file another bug for removing the legacy stuff once we merge.
Differential Revision: https://phabricator.services.mozilla.com/D54837
--HG--
rename : browser/base/content/aboutDialog-appUpdater.js => browser/base/content/aboutDialog-appUpdater-legacy.js
rename : toolkit/mozapps/update/tests/browser/browser.bits.ini => toolkit/mozapps/update/tests/browser/browser.legacy.bits.ini
rename : toolkit/mozapps/update/tests/browser/browser.ini => toolkit/mozapps/update/tests/browser/browser.legacy.ini
extra : moz-landing-system : lando
Move the relazification decisions to JSScript since the check is made after
delazification happens. The JSScript::isRelazifiable check inspects
characteristics of the script itself, while JSScript::canRelazify includes
additional checks for runtime conditions outside the script.
Depends on D55362
Differential Revision: https://phabricator.services.mozilla.com/D55390
--HG--
extra : source : 14f33b78f0eb5e32fd3e9c116f21a23ab7221f26
extra : amend_source : b589a2468c961591d1ada333857118e9e3a26e64
Now that both LazyScript and JSScript have the same pointer field, we can
move to the BaseScript class. The inner-function pointers in the gcthings
array will have the same meaning for both LazyScript and JSScript, but the
other members of gcthings may have different interpretations.
This adds poisoning of the PrivateScriptData in the LazyScript case for
consistency.
Depends on D55361
Differential Revision: https://phabricator.services.mozilla.com/D55362
--HG--
extra : source : 617ce539db705444da7589ecba02e4060d825a2e
Reorder the classes in JSScript.h so that we can use PrivateScriptData from
within BaseScript.
Depends on D55360
Differential Revision: https://phabricator.services.mozilla.com/D55361
--HG--
extra : source : 47f84263339e71dcca4b8cf03179f5722b7503fd
It it straight-foward for users of LazyScriptData to support a single array
for closedOverBindings and innerFunctions. As a result, we can use
PrivateScriptData as the implementation and eliminate the LazyScriptData type
altogether.
Depends on D55035
Differential Revision: https://phabricator.services.mozilla.com/D55360
--HG--
extra : source : 07471e96b2d8fdec534ee3c03432d1fe21095599
Unify the JSScript::warmUpData_ and LazyScript::enclosingLazyScriptOrScope_
fields into BaseScript. As a script progresses from lazy up to being JIT-ed
it the type stored in this field will change. If a script is in a compiled
state, the enclosingLazyScriptOrScope_ value can always be reconstructed
during relazification.
Depends on D55034
Differential Revision: https://phabricator.services.mozilla.com/D55035
--HG--
extra : source : 5163670bfede45831e1d2eb246eceeaa774d2631
Allow storing manually-barriered GC pointers in ScriptWarmUpData. This
updates the 'trace' method as needed. When switching types, the user must
first 'clear' the old type and then 'init' the new type. We continue to use
WarmUpCount(0) as the default safe state.
Depends on D55033
Differential Revision: https://phabricator.services.mozilla.com/D55034
--HG--
extra : source : 5ea098cc9ef02f4391d2ed8c8f0a64625a9042fa
Prepare to move the warmUpData field to BaseScript by first moving the type
definition earlier in the file.
Differential Revision: https://phabricator.services.mozilla.com/D55033
--HG--
extra : source : 42ca239ee6a65d3f28f1990da62db7efe2c19bd8
This adds the shell option for all the FinalizationGroup tests and updates the test262 update script. We still need to run the update script so that the tests do feature detection.
Differential Revision: https://phabricator.services.mozilla.com/D55121
--HG--
extra : moz-landing-system : lando
The patch adds a new option that can be used from jstests.list to pass additional shell command line options. With feature detection (skip-if) this allows us to have tests running on infra for experimental features that are not yet supported in the browser.
Differential Revision: https://phabricator.services.mozilla.com/D54316
--HG--
extra : moz-landing-system : lando
There are two places using DBService during a page load at startup:
1. nsChannelClassifier::Start, used by Phishing Protection
2. AsyncChannelClassifier::CheckChannel, used by Tracking Protection
Tracking protection checks happen before establishing a network connection, so it happens
prior to phishing protection checkes. When we load a page at
startup, ::CheckChannel API is called, but DBService is not yet created.
This patch fixes this issue by creating a DBService instance when
::GetWorker API is called without a DBService instance.
Differential Revision: https://phabricator.services.mozilla.com/D55248
--HG--
extra : moz-landing-system : lando
`StoreBuffer::putSlot` when called with a nursery object as its `obj` parameter
is a no-op, because `StoreBuffer::put` is a no-op when `Edge::maybeInRememberedSet`
return false, which, in the case of `SlotsEdge`, happens when `SlotsEdge::object()`
is in the nursery. This enables us to skip the linear traversal of the elements
array in `elementsRangeWriteBarrierPost` when the current object is in the nursery.
Differential Revision: https://phabricator.services.mozilla.com/D55420
--HG--
extra : moz-landing-system : lando
Move the relazification decisions to JSScript since the check is made after
delazification happens. The JSScript::isRelazifiable check inspects
characteristics of the script itself, while JSScript::canRelazify includes
additional checks for runtime conditions outside the script.
Depends on D55362
Differential Revision: https://phabricator.services.mozilla.com/D55390
--HG--
extra : moz-landing-system : lando
Now that both LazyScript and JSScript have the same pointer field, we can
move to the BaseScript class. The inner-function pointers in the gcthings
array will have the same meaning for both LazyScript and JSScript, but the
other members of gcthings may have different interpretations.
This adds poisoning of the PrivateScriptData in the LazyScript case for
consistency.
Depends on D55361
Differential Revision: https://phabricator.services.mozilla.com/D55362
--HG--
extra : moz-landing-system : lando
Reorder the classes in JSScript.h so that we can use PrivateScriptData from
within BaseScript.
Depends on D55360
Differential Revision: https://phabricator.services.mozilla.com/D55361
--HG--
extra : moz-landing-system : lando
It it straight-foward for users of LazyScriptData to support a single array
for closedOverBindings and innerFunctions. As a result, we can use
PrivateScriptData as the implementation and eliminate the LazyScriptData type
altogether.
Depends on D55035
Differential Revision: https://phabricator.services.mozilla.com/D55360
--HG--
extra : moz-landing-system : lando
Unify the JSScript::warmUpData_ and LazyScript::enclosingLazyScriptOrScope_
fields into BaseScript. As a script progresses from lazy up to being JIT-ed
it the type stored in this field will change. If a script is in a compiled
state, the enclosingLazyScriptOrScope_ value can always be reconstructed
during relazification.
Depends on D55034
Differential Revision: https://phabricator.services.mozilla.com/D55035
--HG--
extra : moz-landing-system : lando
Allow storing manually-barriered GC pointers in ScriptWarmUpData. This
updates the 'trace' method as needed. When switching types, the user must
first 'clear' the old type and then 'init' the new type. We continue to use
WarmUpCount(0) as the default safe state.
Depends on D55033
Differential Revision: https://phabricator.services.mozilla.com/D55034
--HG--
extra : moz-landing-system : lando
Prepare to move the warmUpData field to BaseScript by first moving the type
definition earlier in the file.
Differential Revision: https://phabricator.services.mozilla.com/D55033
--HG--
extra : moz-landing-system : lando
Nicolas Chevobbe
Marco Vega
Jon Coppeard
shindli
Kershaw Chang
Valentin Gosu
Marco Bonardo
Julian Descottes
Simon Giesecke
Henri Sivonen
Thomas Nguyen
Edgar Chen
Drew Willcoxon
Ted Campbell
Coroiu Cristina
Noemi Erli
Mihai Alexandru Michis
ffxbld
Jonathan Watt
Dimi Lee
André Bargull
longsonr