Loading SpecialPowers into frame scripts has side-effects, detailed in part 1,
which are undesirable. The main side-effect that I'm trying to get rid of here
is the force-enabling of permissive COWs in frame script scopes, which is
blocking changes that I need to make elsewhere. But both that and the scope
pollution it causes are likely to allow code to work when running in
automation which fails in real world usage.
This patch changes our special powers frame scripts to load specialpowers.js
and specialpowersAPI.js as JSMs, which run in their own global, but define
most of the same properties on our frame script globals.
Most other callers still load those scripts via <script> tags or the subscript
loader, and should ideally migrated in a follow-up. But even so, this patch
still gives us a cleaner separation of the frame script and non-frame-script
loading code.
MozReview-Commit-ID: CR226gCDaGY
--HG--
extra : rebase_source : 251574d238ded31b9df32dc89852251831d55757
extra : source : c53c7b0249ad3359fbc9f144f2cf9ca3b6386c59
Summary:
Implemented by nsDocShell and nsWebBrowser (which just wraps the
docshell functions), but not actually used anywhere.
MozReview-Commit-ID: 2YzfsrvOolX
Test Plan: Try run
Reviewers: nika
Tags: #secure-revision
Bug #: 1480641
Differential Revision: https://phabricator.services.mozilla.com/D2695
Summary:
Unused interface that can be removed.
MozReview-Commit-ID: GnHRXdtI4qe
Test Plan: Try run
Reviewers: nika
Tags: #secure-revision
Bug #: 1480637
Differential Revision: https://phabricator.services.mozilla.com/D2694
Summary:
nsIWebShellServices is only implemented by nsDocShell, and only used
in one place in C++. Move definitions to nsIDocShell, and rename
functions to show they are only used as part of Charset changes.
MozReview-Commit-ID: DOSeE3Doc51
Test Plan: Try run
Reviewers: nika
Tags: #secure-revision
Bug #: 1480628
Differential Revision: https://phabricator.services.mozilla.com/D2692
Loading SpecialPowers into frame scripts has side-effects, detailed in part 1,
which are undesirable. The main side-effect that I'm trying to get rid of here
is the force-enabling of permissive COWs in frame script scopes, which is
blocking changes that I need to make elsewhere. But both that and the scope
pollution it causes are likely to allow code to work when running in
automation which fails in real world usage.
This patch changes our special powers frame scripts to load specialpowers.js
and specialpowersAPI.js as JSMs, which run in their own global, but define
most of the same properties on our frame script globals.
Most other callers still load those scripts via <script> tags or the subscript
loader, and should ideally migrated in a follow-up. But even so, this patch
still gives us a cleaner separation of the frame script and non-frame-script
loading code.
MozReview-Commit-ID: CR226gCDaGY
--HG--
extra : rebase_source : fa253abde2029ec09c724404106d83623f064875
This alters nsILoadURIDelegate.loadURI() to return a Promise rather than spinning the event loop to synchronously return a boolean, and alters nsDocShell::InternalLoad to allow for those changes by re-calling itself if necessary based on the resolution of the promise.
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant functions are updated to take a typed enum (in C++) and an
integer constant (in JavaScript). A JavaScript wrapper around the crash
reporter service is provided to hold the constants. The existing whitelists
and blacklists of annotations are also generated from the YAML file and the
existing duplicate code has been consolidated. Once written out to the .extra
file the annotations are converted in string form and are no different than
the existing ones.
All existing annotations have been included (and some obsolete ones removed)
and all call sites have been updated including tests.
--HG--
extra : rebase_source : b4f0d4bf83c64851028c271d3fab3ebcb6fbcd3e
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant functions are updated to take a typed enum (in C++) and an
integer constant (in JavaScript). A JavaScript wrapper around the crash
reporter service is provided to hold the constants. The existing whitelists
and blacklists of annotations are also generated from the YAML file and the
existing duplicate code has been consolidated. Once written out to the .extra
file the annotations are converted in string form and are no different than
the existing ones.
All existing annotations have been included (and some obsolete ones removed)
and all call sites have been updated including tests.
--HG--
extra : rebase_source : f0e8d229581ac5c0daa0e0454cb258746108e28d
All the C++ consumers already call the getter, so we can remove
nsIEditingSession from the docshell GetInterface method completely.
Differential Revision: https://phabricator.services.mozilla.com/D2668
--HG--
extra : moz-landing-system : lando
If we add to history on a docshell that is being shut down, add
history entry but skip trying to load the new URI.
MozReview-Commit-ID: JCF9muhxbFd
Differential Revision: https://phabricator.services.mozilla.com/D2311
--HG--
extra : moz-landing-system : lando
This change also renames several related functions, as well as fields,
and the header is moved into EXPORTS.mozilla given it is defined under
mozilla namespace.
MozReview-Commit-ID: LqCdcW8fmUN
--HG--
rename : layout/base/ScrollbarStyles.cpp => layout/base/ScrollStyles.cpp
rename : layout/base/ScrollbarStyles.h => layout/base/ScrollStyles.h
extra : rebase_source : 8933f3bca88d5db4b9508e3947f695ecf7511b3e
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : source : fcfb99baa0f0fb60a7c420a712c6ae7c72576871
extra : histedit_source : 5be9b7b29a52a4b8376ee0bdfc5c08b12e3c775a
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : rebase_source : a13c59d1a5ed000187c7fd8e7339408ad6e2dee6
To not leave dangling BrowsingContexts due to crashing child processes
we need to detach all BrowsingContexts owned by a specific process
when that process goes away.
--HG--
extra : histedit_source : a737dd272224ae2595e8851813f3f9a66a2e01f2
Have BrowsingContext keep its own cache to enable caching of
BrowsingContexts, especially in the parent process.
This isn't really optimal, since it effectively duplicates the
cache in the child process. BFcache keeps a list of strong pointers to
the list of cached nsDocShells, where each nsDocShell in turn keeps a
reciprocated strong pointer to its BrowsingContext, which in turn is
held in the BrowsingContexts list of cached contexts. Ideally these
caches should be merged.
--HG--
extra : histedit_source : 094370f6d54d83728e8433ec5c47003086146476
Add BrowsingContext to allow the tree structure of docshells to exist
in several processes simultaneously. This is a first step towards
allowing a tree structure preserving separation of docshells across
processes.
--HG--
extra : histedit_source : d3c7f6ab4b9ae76f170c126d669ebd570e52f348
We have 2 different LoadType enums with two different values, which
have to be converted between depending on whether we're going to/from
LoadInfo/nsISHEntry/etc. We should be able to just use the same enum
everywhere and not have to deal with conversion, especially since we
don't have any type safety around the enum.
MozReview-Commit-ID: 2t9vVGLpOte
While nsDocShellLoadInfo isn't represented by WebIDL (because we don't
need it in JS currently), make the getter/setter interface look
similar, just to keep consistent code style.
MozReview-Commit-ID: 3UfLR6jWVGK
nsIGlobalHistory2 is not implemented by any mozilla-central nor comm-central applications, and hence can be removed. As a result, nsDownloadHistory's implementation can also be removed.
MozReview-Commit-ID: 5bQ2OHsV1Ky
Differential Revision: https://phabricator.services.mozilla.com/D1929
--HG--
extra : moz-landing-system : lando
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Before this change, the trusted URI schemes, based on a string whitelist, were:
https, file, resource, app, moz-extension and wss.
This change removes "app" from the list (since we don't implement it),
and adds "about" to the list (because we control the delivery of that).
The current limit of at most one bfcache entry on Android dates back to when
Fennec was built for the Nokia N810, which had a whopping 128 MB of memory.
Since a few years have passed since then and mobile device technology has
evolved considerably, it should be safe now to allow a little more than that.
Since web sites sizes might have grown somewhat as well compared to the figure
of 4MB mentioned in CalcMaxTotalViweres(), though and to be absolutely on the
safe side, we still tweak the formula when building for Android, though.
If in the worst case even those assumptions turn out too generous, we will still
be protected by the fact that
- we temporarily disable the bfcache when the OS signals memory pressure, and
- our contentViewerTimeout is set to a lower value than on Desktop, so bfcache
entries will expire sooner
MozReview-Commit-ID: 1A6d0Q6Mdx0
--HG--
extra : rebase_source : 9cc1f7abb1aef82ffc4d7987773ae7cf35440884