This removes the bookmark description UI, but leaves the backend in-place for a release or two, so that users have time to save anything they want (e.g. via backup).
The backend will be removed in bug 1402890.
MozReview-Commit-ID: La4AYFar7eK
--HG--
extra : rebase_source : 02bfe3cacdac331d09d5e62a1a70f48b68741670
In addition to the code going to a .jsm, it became a singleton that implements nsIMessageListener, instead of being one instance per tab (which is usually done to give easier access to the page's content, but it's possible to get to it through each message, as message.target.content
While working to reproduce the stale content bug with tab warming
I realized that my work here had inadvertently clobbered tab
warming by immediately calling the tab unload code. This wasn't
necessary, and I didn't need to put the cached tab deactivation
code in the unload method, it just seemed initially convenient.
This should make more sense overall.
MozReview-Commit-ID: 9v9dYZTa1Dv
--HG--
extra : rebase_source : fe1d6f4f87df11d5ed495e309a4a0f144bfc2143
This is fairly straightforward, other than the fact that the
nomenclature gets a bit awkward with the aForce parameter on
the ForcePaint methods. I'm not sure which direction to go with
this - "aForce" seems a fairly intuitive name for what we want,
and I'm kind of inclined to say the existing ForcePaint mechanic
should be renamed to something like PaintWithInterrupt, or
PaintWithPriority.
MozReview-Commit-ID: Bj9DROug1pC
--HG--
extra : rebase_source : a3d91fec940d83325d36bafb13fe892e9c9530e8
We maintain a simple LRU cache of tab layers by setting their
docShellIsActive = false with preserveLayers(true). Once they
are pushed out of the cache by more recently used tabs, their
layers are discarded.
Luckily most of the complexity of this could be contained in
the AsyncTabSwitcher - the one change that had to sit outside of
that was moving the aTab.closing = true earlier in the removeTab
call, so that we could use that information to eagerly evict tabs
from the cache. This was to address a leak in a few tests on try.
MozReview-Commit-ID: 2E3uU8LEYkD
--HG--
extra : rebase_source : d2865fd1ee10db17d9f41cca059a5cee697f259d
This commit makes the page info window treat cookie permissions a little
differently, to reflect that the "default" value for cookies is a combination
of two prefs that doesn't strictly map onto the ALLOW/SESSION/DENY system of
permissions.
I also added some more general pageinfo permissions tests.
MozReview-Commit-ID: 80vd61Rv867
--HG--
extra : rebase_source : c079e47afb74b2c4b7da271efcaf20dd45d1eb60
While we already do a permission check in native webrtc code, the one
in webrtcUI is needed to provide extra protection against permission spam
by checking if there's a temporarily denied permission on the tab.
Since we introduced custom default permission values it is necessary to
also pass the URI to make sure we catch exceptions added by the user.
MozReview-Commit-ID: C8r6ymbKE3a
--HG--
extra : rebase_source : 8f0b3486f2f33bee75536ae2cf7dd091c5a9c568
We maintain a simple LRU cache of tab layers by setting their
docShellIsActive = false with preserveLayers(true). Once they
are pushed out of the cache by more recently used tabs, their
layers are discarded.
Luckily most of the complexity of this could be contained in
the AsyncTabSwitcher - the one change that had to sit outside of
that was moving the aTab.closing = true earlier in the removeTab
call, so that we could use that information to eagerly evict tabs
from the cache. This was to address a leak in a few tests on try.
MozReview-Commit-ID: 2E3uU8LEYkD
--HG--
extra : rebase_source : b7e7bb3fcf1ed59e79a7c9fb9d3e6ce735ab54e9
We maintain a simple LRU cache of tab layers by setting their
docShellIsActive = false with preserveLayers(true). Once they
are pushed out of the cache by more recently used tabs, their
layers are discarded.
Luckily most of the complexity of this could be contained in
the AsyncTabSwitcher - the one change that had to sit outside of
that was moving the aTab.closing = true earlier in the removeTab
call, so that we could use that information to eagerly evict tabs
from the cache. This was to address a leak in a few tests on try.
MozReview-Commit-ID: 2E3uU8LEYkD
--HG--
extra : rebase_source : b7e7bb3fcf1ed59e79a7c9fb9d3e6ce735ab54e9
Also fixes existing code which fails the rule.
MozReview-Commit-ID: CkLFgsspGMU
--HG--
extra : rebase_source : 86a43837659aa2ad83a87eab53b7aa8d39ccf55b
This makes debugging failures extremely difficult, and tends to confuse
developers who add debugging logs and can't understand why they're not showing
up.
MozReview-Commit-ID: Wajt2JczuY
--HG--
extra : rebase_source : 497d78a915ad92707ba5f7d5b437ec1dfbc5b8f8
Sites which are whitelisted should be allowed to autoplay audible media.
So check whether a HTMLMediaElement's owner doc's principal has an exact
"autoplay-media" permission. This ensures whitelisted origins can autoplay,
but sub-origins of whitelisted origins need their own permission.
MozReview-Commit-ID: 2IO5KIyplEa
--HG--
extra : rebase_source : 4a974aba0533bfbd5e9bb4c4c11d77d17a81db6d
We maintain a simple LRU cache of tab layers by setting their
docShellIsActive = false with preserveLayers(true). Once they
are pushed out of the cache by more recently used tabs, their
layers are discarded.
Luckily most of the complexity of this could be contained in
the AsyncTabSwitcher - the one change that had to sit outside of
that was moving the aTab.closing = true earlier in the removeTab
call, so that we could use that information to eagerly evict tabs
from the cache. This was to address a leak in a few tests on try.
MozReview-Commit-ID: 2E3uU8LEYkD
--HG--
extra : rebase_source : 1de7c196b14b2f3a368bfbae970808cbf49e6e36
Sites which are whitelisted should be allowed to autoplay audible media.
So check whether a HTMLMediaElement's owner doc's principal has an exact
"autoplay-media" permission. This ensures whitelisted origins can autoplay,
but sub-origins of whitelisted origins need their own permission.
MozReview-Commit-ID: 2IO5KIyplEa
--HG--
extra : rebase_source : 4d9afdec0caa4a82b53bedfd645f259a5c760e4d
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
These issues were previously ignored due to the nature of our global import
rules. They need to be fixed before that rule can be updated.
MozReview-Commit-ID: DCChktTc5TW
--HG--
extra : rebase_source : cffb1c9762191c579d1397c8169e6e7635d229da
extra : histedit_source : dea59ddd2daaae52069c5faceae9149a4f08dd73
The OfflineAppCacheHelper was apparently introduced after the Sanitizer had been
forked for Fennec and so far nobody bothered to use it there as well.
MozReview-Commit-ID: 42Uk5hfvf9y
--HG--
rename : browser/modules/offlineAppCache.jsm => toolkit/modules/offlineAppCache.jsm
extra : rebase_source : 77e542dbbdfea62b918b89b4c0799be7e3f89ef9
Tests are also added here for the legacy `getTopWindow` method to guard against
basic regressions.
We now start tracking browser windows right after the DOMContentLoaded event, which
is earlier than before. We now also assume that any newly tracked window has the
focus initially, which is closer to the nsIWindowMediator semantics.
MozReview-Commit-ID: 6QYJqA1tMPC
--HG--
extra : rebase_source : e04e567cf31d1a10e78647d75403b700bc65136b
The OfflineAppCacheHelper was apparently introduced after the Sanitizer had been
forked for Fennec and so far nobody bothered to use it there as well.
MozReview-Commit-ID: 42Uk5hfvf9y
--HG--
rename : browser/modules/offlineAppCache.jsm => toolkit/modules/offlineAppCache.jsm
extra : rebase_source : b7010f732ca13583fd2b2c62102b4ea1c13a4cc6
site.principals is not always guaranteed to contain elements, only if
the site has quota storage or AppCache. This patch simplifies the function
to use hosts instead.
This was done using the script at:
bc5629735d/processors/add-task-async.jsm
MozReview-Commit-ID: KxuS9Cen87
--HG--
extra : rebase_source : c0028e0cd55ba1643610cd30c55c6f4bca7d6e58
extra : histedit_source : ebc84fdec9c2db6176632d62de4e7bdad2a7829d
Reporting was already disabled in Bug 1443605.
This keeps the `enabled` getter as a way to detect if it is enabled, in use in BrowserUITelemetry only.
This keeps `addEvent` and related methods, as they are still in use on Android.
This commit is in preparation of using SiteDataManager in the page info
window to display site data information for a individual hosts.
MozReview-Commit-ID: 3YmUZInvoAT
--HG--
rename : browser/components/preferences/SiteDataManager.jsm => browser/modules/SiteDataManager.jsm
extra : rebase_source : 2d48740a023f63a2ec7af06f4510ab9cbb91fc66
It looks like TabChild::RenderLayers already does the work of suppressing the displayport,
so all of the suppression and bookkeeping that AsyncTabSwitcher is doing is superfluous
and probably opening us up to weird graphical glitches (like the one associated with this
bug).
MozReview-Commit-ID: 5qIVguSMsnr
--HG--
extra : rebase_source : 59e72715791cb8aa25310e48b5a02e1b86762543
Also adds resource://devtools to the whitelist of reported paths for the
scalar.
Differential Revision: https://phabricator.services.mozilla.com/D831
MozReview-Commit-ID: BiAyoTQsWxx
--HG--
extra : rebase_source : ce9e81a153a2c17ebfbb0c894821e7684c547a9a
extra : amend_source : 4ad84421c0b3334d218b2f6928290f95edffa351
The CSS for page action icons doesn't handle fallback when only one variable
is defined, so for widgets that don't define their icons using CSS, we always
need to provide both.
MozReview-Commit-ID: 7UgMSVS3W6K
--HG--
extra : rebase_source : d8e38c256b45efecf04f1e20b5fcc6024e839f25
It looks like TabChild::RenderLayers already does the work of suppressing the displayport,
so all of the suppression and bookkeeping that AsyncTabSwitcher is doing is superfluous
and probably opening us up to weird graphical glitches (like the one associated with this
bug).
MozReview-Commit-ID: 5qIVguSMsnr
--HG--
extra : rebase_source : 35f944a324415401c4a28ed0006baf9361ef73c8
We suppress the displayport when requesting a tab or warming it, in order to reduce
the amount of work that the content process needs to do to paint it (we paint just
the displayport area and nothing around it). Afterwards, we unsuppress the displayport
so that we can paint the surrounding areas when scrolling. We normally do this
unsuppression in destroy(), but with tab warming, that unsuppression can happen
after a few seconds (after the tab warming eviction timeout).
This results in users seeing checkerboarding sometimes, where the tab they're looking
at is still suppressing its displayport and waiting for the timeout to complete.
This patch updates the AsyncTabSwitcher to unsuppress the displayport for a tab as
soon as the tab has been switched to, instead of waiting for the timeout.
Out of an abundance of caution, we still unsuppress displayports for tabs that
never get to enter the STATE_LOADED state, although that really should never
happen.
MozReview-Commit-ID: 5qIVguSMsnr
--HG--
extra : rebase_source : 90c0d617ac3d43a8d4513e864ba2f0a3228a5582
Release is already included in the context as browser info and doesn't need to
be kept as a tag like appBuildId was.
Differential Revision: https://phabricator.services.mozilla.com/D807
MozReview-Commit-ID: IGzT3C3HSG
--HG--
extra : rebase_source : eda48fdf022f19bc681002635f893b2a726836f8
extra : amend_source : 55f7d9fe77af586863576ee9b3ed6bc4fae6d639
This removes some discovery pane tests which are obsolete. The discovery pane
page that it tests uses InstallTrigger, rather than mozAddonManager as we use
in production, and fails when used with WebExtensions.
The other tests have been updated to use WebExtensions, and some relevant
PopupNotifications bugs have been fixed so that they actually pass.
MozReview-Commit-ID: 1g0n73vhncp
--HG--
rename : toolkit/mozapps/extensions/test/browser/addons/browser_dragdrop1/install.rdf => toolkit/mozapps/extensions/test/browser/addons/browser_dragdrop1/manifest.json
rename : toolkit/mozapps/extensions/test/browser/addons/browser_dragdrop2/install.rdf => toolkit/mozapps/extensions/test/browser/addons/browser_dragdrop2/manifest.json
rename : toolkit/mozapps/extensions/test/browser/addons/browser_dragdrop_incompat/install.rdf => toolkit/mozapps/extensions/test/browser/addons/browser_dragdrop_incompat/manifest.json
extra : rebase_source : 0334268d0476227d084fb81bc8455deb186e6bd1
This adds a policy with the capability of adding search engines, choosing the default search engine, and blocking the installation of new search engines.
Additionally, fixes the messages for errors reported by MainProcessSingleton.addSearchEngine so that the offending URL is printed rather than "[xpconnect wrapped nsIURI]".
MozReview-Commit-ID: HuLT15Rnq0r
--HG--
rename : browser/components/search/test/testEngine.xml => browser/components/enterprisepolicies/tests/browser/opensearchEngine.xml
extra : rebase_source : 7815f5d03395decc39ee2657ba05c071dd332abb
nsFrameLoader is on WebIDL bindings, so those QIs are no-ops anyway, unless the given object is no a frameloader to start with.
MozReview-Commit-ID: IPiW70H5NPc