The next easy step is to move the getters below the static methods.
Differential Revision: https://phabricator.services.mozilla.com/D30156
--HG--
extra : rebase_source : a609823f9f19a51f73fe61fa910bc513c614378e
extra : source : 2e91e4b9d847b74f1514a14720c618bf1634d91e
extra : histedit_source : bd641bf544aa378544fb401b0b0a6768d63b48f3
The methods in BrowserParent are a bit disorganized. There's a lot to
do to fix that, but an easy first step is to move static methods to
the top of the class.
Differential Revision: https://phabricator.services.mozilla.com/D30155
--HG--
extra : rebase_source : 2fb0b7ad48030ba4682e6d0ded06b67494a0c330
extra : source : 05002949953c3df7a647e78a8a65975a19e23631
extra : histedit_source : a6b997485d7576962ce23dcfe86b419686c19b78
This is the followup to the previous patch, and attempts to organize
state to be a bit more logical.
Differential Revision: https://phabricator.services.mozilla.com/D30154
--HG--
extra : rebase_source : e85426e0c03857ceb4b89fab3fdb557e66ab9f2f
extra : source : c0221209ace4c85d66cd9b667e0699f50b923f1a
extra : histedit_source : 16d5f4a458dab48ab96741e449d50b8e8b48c5eb
Somehow all of the member variables of BrowserParent have been
spread around the class. This makes it really hard to understand
what state there is. This commit moves all member variables
(preserving order) to the bottom of the class.
Differential Revision: https://phabricator.services.mozilla.com/D30153
--HG--
extra : rebase_source : 377f5b55e5393a9ac6f88389f0589eb6fd66848c
extra : source : 033e99403d147fd11eaf7b2037f36e156d2598ff
extra : histedit_source : c20e5d02ca67c3f3eff3c1d77abb0f871a9025d2
This isn't needed now that BrowserParent has the same name
as the protocol.
Differential Revision: https://phabricator.services.mozilla.com/D30151
--HG--
extra : rebase_source : dbfc1722a43e1f8fbbe01f1766a397b570fa7d6a
extra : source : 792b49f269bb6308e152290ed0dfa03efbffa536
extra : histedit_source : e001669549af547f5387a3b010ad52ebee6eea3f
In order to show all popups on Wayland we need to set popup parent runtime for popups which don't have
fixed parent. For instance popup menus (fired after right button mouse click) can be issued on top of another popup
and we need to follow that connection on Wayland.
We track all open (active) popups to:
- close all visible tooltip windows when we're going to open another tooltip
- close concurrent popup on the same level when a new one is about to open
- get latest active popup as a parent for a new tooltip windows
- get latest active popup as a parent for a new popup menu without fixed parent
Differential Revision: https://phabricator.services.mozilla.com/D29348
--HG--
extra : moz-landing-system : lando
For guaranteeing the sets of container node, offset in it, and the node
referred by the offset, the method should use `EditorDOMPoint` instead of
managing them separately.
Differential Revision: https://phabricator.services.mozilla.com/D30015
--HG--
extra : moz-landing-system : lando
This is a simple mistake of `MOZ_ASSERTION()` in it. When `mParent` is a node
which can have children, `mChild` should be non-`nullptr` or `mOffset` should
/ be set to the end of `mParent`. But when `mParent` is not a container, any
`mOffset` value should be allowed.
Differential Revision: https://phabricator.services.mozilla.com/D30014
--HG--
extra : moz-landing-system : lando
Test coverage for this is provided in the web platform test
html/browsers/browsing-the-web/history-traversal/persisted-user-state-restoration/scroll-restoration-fragment-scrolling-samedoc.html.
Differential Revision: https://phabricator.services.mozilla.com/D30105
--HG--
extra : moz-landing-system : lando
cargo fix works by building under a specific config, so we can't hit both
sides of a mutually exclusive pair of cfgs, such as cfg(target_os) or
when cfg(feature) and cfg(not(feature)) both exist in the codebase.
Differential Revision: https://phabricator.services.mozilla.com/D29568
--HG--
extra : moz-landing-system : lando
Notably `extern crate foo as bar` is no longer supported
(must do it in Cargo.toml). Also stopped using euclid through webrender_api,
because it produces worse results in 2018.
Differential Revision: https://phabricator.services.mozilla.com/D29566
--HG--
extra : moz-landing-system : lando
0.1.21 mishandles cargo package renames, which are a required
feature for Rust 2018 support. The latest version fixes this.
Differential Revision: https://phabricator.services.mozilla.com/D29946
--HG--
extra : moz-landing-system : lando
The Content Security Policy tests were handling the smaller android preload
values that were #defined on Android by setting media.preload.default=2. Now
that we're detecting whether we're on cellular or not, and the android
emulators that our tests run on emulate a cellular connection, just setting
media.preload.default is no longer enough.
So set media.preload.default.cellular=2 in the CSP mochitests instead of
media.preload.default, to make the CSP mochitests pass in the Android
emulators.
Differential Revision: https://phabricator.services.mozilla.com/D29617
--HG--
extra : moz-landing-system : lando
We're allowed to take some liberties as to what the default value and behaviour
we assume for the 'preload' attribute on HTMLMediaElement by the spec. On
desktop we assumed preload="metadata", while on mobile we assumed the default
of preload="none" to save data. On mobile we also assumed that preload="auto"
meant preload="metadata".
I think it makes sense to instead of always assuming that data on Android is
always expensive, we can instead detect if we're running on a cellular connection,
and preload frugally then, otherwise aggressively.
Differential Revision: https://phabricator.services.mozilla.com/D26235
--HG--
extra : moz-landing-system : lando
Normally when downloading media data we throttle the download only if we're
ahead of the read cursor more than the "readahead limit", and if we estimate
that the connection is fast enough that we'll be able to download at a rate
fast enough to playback in real time if we resume it later.
On mobile we additionally override this so that we always throttle the download
once we're ahead of the read cursor by the readahead limit. This is to save
data. I think we can relax this to only do this override if we're on a
cellular connection; if we're on WiFi we can assume data is cheap.
Differential Revision: https://phabricator.services.mozilla.com/D26234
--HG--
extra : moz-landing-system : lando
In GeckoView the nsINetworkLinkService doesn't work in the content process, as
we don't seem to have an AndroidBridge there, so just maintain the network
connection type on the ContentChild.
(I had considered keeping this on the NeckoChild, but the creation of that is
initiated from the content process side, and there's not an easy and clean way
to have the parent process send us the connection type after construction of
the NeckoParent, other than have the NeckoChild request it either
synchronously, or doing it async and hoping it's not asked for the value before
the response comes in.)
Differential Revision: https://phabricator.services.mozilla.com/D26232
--HG--
extra : moz-landing-system : lando
This allows Gecko to react to network link/status changes events as needed.
Differential Revision: https://phabricator.services.mozilla.com/D28942
--HG--
extra : moz-landing-system : lando
2019-05-06 22:41:10 +00:00
Eugen Sawin ext:(%2C%20Chris%20Pearce%20%3Ccpearce%40mozilla.com%3E)
