SessionStore factors both prefs into the decision about if a tab is restored
lazily, but this helper only uses the `restore_tabs_lazily` pref.
Depends on D114001
Differential Revision: https://phabricator.services.mozilla.com/D114002
Modify related test files to test documents with COOP headers enabled.
There are some tests that fail when run with new COOP configurations without
Fission enabled, prior to fixes that come in part 2. This means that some of
the COOP behaviour was already broken. Since fixing non-Fission COOP
behaviour prior to this patch is out of scope, I skipped calling `addCoopTask`
to test COOP documents in non Fission cases for such tests.
Even with COOP headers disabled, some tests fail when the document they load
is served over httpS and not http. For a single test where this behaviour was
occuring prior to fixes in part 2, I skipped testing an HTTPS non-COOP
document and filed 1703351 to fix such behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D110993
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
Before this change, we accessed the browser URL in the following ways:
- "chrome://browser/content/browser.xul"
- "chrome://browser/content/" (which redirects to chrome://browser/content/browser.xul)
- Services.prefs.getCharPref("browser.chromeURL") which returns "chrome://browser/content/"
- getBrowserURL() from utilityOverlay.js
MozReview-Commit-ID: I5vtRke1x9t
NOTE: The '__SSi' and '__SS_lastSessionWindowID' properties on windows are kept,
because they are expected to stick around longer during application shutdown.
The benefits is are:
1. Cleaner code - Sessionstore implementation details are not leaked outside its
module.
2. Observing the lifetime of objects becomes unnecessary, because the WeakMaps are
cleaned up when objects are GC'd, making leakage of their references impossible
and Sessionstore can't hold objects hostage anymore.
3. Simplification - all state is now maintained in SessionStore.jsm, which allows
for additional refactoring later on to simplify the implementation further.
MozReview-Commit-ID: C1II8qHkQ6F
