Adds overloads to GeckoSession.loadUri() that accept additional HTTP request headers
Differential Revision: https://phabricator.services.mozilla.com/D40951
--HG--
extra : moz-landing-system : lando
Hooks up slow script reporting to the ContentDelegate. Allowing slow script prompts to be implemented.
Differential Revision: https://phabricator.services.mozilla.com/D41970
--HG--
extra : moz-landing-system : lando
This changes provide basic support for webextenion tabs and webNavigation listeners by implementing missing objects on which Fennec implementation was relying.
Differential Revision: https://phabricator.services.mozilla.com/D36575
--HG--
extra : moz-landing-system : lando
This changes provide basic support for webextenion tabs and webNavigation listeners by implementing missing objects on which Fennec implementation was relying.
Differential Revision: https://phabricator.services.mozilla.com/D36575
--HG--
extra : moz-landing-system : lando
This is the first step in making it possible to return remote WindowProxy
objects from window.open() and related APIs.
This patch also incidentally fixes a bug where getContentWindowOrOpenURI
returned the top-level browser window rather than the new content window when
passed OPEN_NEWWINDOW for the `aWhere` parameter. This was not the expected
behavior, and was a potentially major footgun for any new users who expected
to always get the content window for the URL they were loading, rather than
sometimes getting a chrome browser window instead.
For now, that case just returns null, which is only a minor footgun, rather
than the major one we had before.
Differential Revision: https://phabricator.services.mozilla.com/D35688
--HG--
extra : moz-landing-system : lando
Some background information on this change:
DocShell loads about:blank when first starting up. This initial load can be
avoided by setting `nodefaultsrc` on the browser element, but this will still
cause some load events related to `about:blank` to fire anyway, as they are
specified in the DOM spec (see e.g. bz's Comment #2 Bug 1447406). In particular
`onSecurityChange` and `onLocationChange` are still fired, `onPageStart` and
onPageStop` are not.
These messages are unreliable and sometimes do not fire, to unrestand why it's
helpful to look at a timeline of the events when starting up a GeckoSession.
page about:blank ---------------------------------------------------------
nsDocShell --- startup --- onPageStart --- onLocationChange --- onPageStop -----
busyState idle ---------- busy ------------------------------------------ idle-
^ ^ ^ ^ ^
geckoview.js (0) (1) (2) (3) (4)
geckoview.js loads in parallel with nsDocShell startup process (and loading of
about:blank). This means that consumers of GeckoView might start receiving
navigation events at any of the points marked with (0) - (4). E.g. if geckoview
starts up at (4) a consumer waiting for onPageStop for `about:blank` will
actually wait forever (this is what happens before this change for our tests).
As it can be seen there's not really a way to detect in which of the (0) - (4)
state DocShell is when starting up geckoview.js. Checking for the busy state is
not enough as an `idle` busy state might mean that we're in (0) or (4).
Furthermore a consumer of geckoview has no way to know which onPageStop
messages to wait for after an initial loadUri as e.g. the following is what
would happen if geckoview.js happens to startup at (3):
- loadUri(hello.html)
- onPageStop (for about:blank)
- onLoadRequest (for hello.html)
which confuses any code that just waits for onPageStop.
Desktop deals with this in `TabProgressListener.onStateChange` where the
initial `about:blank` navigation is ignored and fake events are triggered at a
convenient time.
To patch implements a very similar behavior for geckoview, we ignore the
initial `about:blank` `onLoadRequest` call, set `nodefaultsrc` so `onPageStart`
and `onPageStop` events don't fire and fire the above calls when the
`GeckoViewProgress` module has finished loading.
This makes `about:blank` events deterministic with the exception of reloading
an empty `GeckoSession`, which will often not fire any extra events. To account
for that we load a dummy html page before the tests that used to rely on this
behavior (which would actually fail occasionally due to the startup race
condition explained above).
This makes the tests pass reliably on x86_64 (20/20 runs passed in try).
Differential Revision: https://phabricator.services.mozilla.com/D32586
--HG--
extra : moz-landing-system : lando
WebExtension pages introduce a case that was previously not possible: a script
with full WebExtension privileges that runs on a page with a GeckoSession
associated to it.
This breaks the assumption that all messages from a privileged context don't
have a GeckoSession associated to it. We fix this by checking if we can find an
eventDispatcher for the given window.
This also fixes the test which had the same wrong assumption.
Differential Revision: https://phabricator.services.mozilla.com/D32512
--HG--
extra : moz-landing-system : lando
Right now there's some duplicated code with the focus manager and the
DOMWindowFocus event.
Android didn't handle the new framefocusrequested event, so the test-cases in
bug 416771 still didn't work there.
I think using the focus manager codepath everywhere is preferable. I confirmed
manually that the stuff that sent DOMWindowFocus events still works as expected
with this patch (i.e., switching to the right tab when you click on a
notification, etc.).
This fixes it so that it works in Fennec, and it sends the focus events right in
GeckoView Example (i.e., we get here[1] properly).
The snippet that Snorp provided on IRC to implement the "bring activity to
front" stuff (`startActivity(getIntent())`) didn't actually work for me, but I
confirmed that the right message is sent when the focus is requested, and that
we get there.
[1]: https://searchfox.org/mozilla-central/rev/952521e6164ddffa3f34bc8cfa5a81afc5b859c4/mobile/android/geckoview_example/src/main/java/org/mozilla/geckoview_example/GeckoViewActivity.java#503
Depends on D32353
Differential Revision: https://phabricator.services.mozilla.com/D32354
--HG--
extra : moz-landing-system : lando
This is because in some circumstances, when navigating away from a page, the dispatcher is no longer present when trying to send the `GeckoView:MediaRecordingStatusChanged` causing the message not to be sent. Fetching the dispatcher earlier ensures that it is present at the point of message sending.
Differential Revision: https://phabricator.services.mozilla.com/D32830
--HG--
extra : moz-landing-system : lando
This is to allow us to detect the enabling and disabling of recording so that we can notify the embedding application of the change in status.
Differential Revision: https://phabricator.services.mozilla.com/D31072
--HG--
extra : moz-landing-system : lando
WebExtension can always open their respective WebExtension pages even when the
WebExtension page is not content accessible.
However, this is not true for `tabs.update`, which couldn't link to
WebExtension pages at all.
Similarly, a user should be able to open a WebExtension page directly by typing
the URL.
To fix the above problems we pass the correct `triggeringPrincipal` when
loading such URIs. This change also makes URI typed by the user not use the
`systemPrincipal` anymore but a more restrictive codebase principal local to
the page that's being typed to avoid unintended side-effects. This also makes
the triggering URI always the page for these privileged pages, so we need to
adjust some tests to account for that by loading unprivileged `http` pages
instead.
Differential Revision: https://phabricator.services.mozilla.com/D32149
--HG--
extra : moz-landing-system : lando
This fixes a crash in `browser.tabs.update` when used with WebExtension pages.
Differential Revision: https://phabricator.services.mozilla.com/D31453
--HG--
extra : moz-landing-system : lando
This fixes a crash in `browser.tabs.update` when used with WebExtension pages.
Differential Revision: https://phabricator.services.mozilla.com/D31453
--HG--
extra : moz-landing-system : lando
Actually, sample url has `<fieldset>` element, so LoginManagerContent cannot detects username field.
`LoginManagerContent.getUserNameAndPasswordFields` detects username field and password field when passing `<input>` element. So we should pass password field if possible.
Differential Revision: https://phabricator.services.mozilla.com/D30179
--HG--
extra : moz-landing-system : lando
Similarly to nsITabParent, TabChild is exposed to frontend code via nsITabChild. It's not clear what the future of this interface will be, but for now we can just rename it to nsIBrowserChild.
Differential Revision: https://phabricator.services.mozilla.com/D28134
--HG--
rename : dom/interfaces/base/nsITabChild.idl => dom/interfaces/base/nsIBrowserChild.idl
extra : rebase_source : a6c42a661e35b19e46c60f6f6a6f3dab64c0a1bc
extra : histedit_source : 1eb475bd840bf37a3f86294685c9b3c250684e79
nsITabParent is exposed to frontend code and is generally used as a representation of a remote tab. We could just rename the interface to nsIBrowserParent and worry about it later, but I think it's better to rename the interface to nsIRemoteTab so that we can later work on splitting the interface away from the PBrowser protocol.
Note: Some frontend code refers to a TabParentId. This commit renames this to RemoteTabId. We need to figure out the purpose of TabId with fission.
Differential Revision: https://phabricator.services.mozilla.com/D28132
--HG--
rename : dom/interfaces/base/nsITabParent.idl => dom/interfaces/base/nsIRemoteTab.idl
extra : rebase_source : 9d8a1790a7bb10195ad063644d1a93d63b2afb72
This change allows GeckoView embedders to respond to
`runtime.sendNativeMessage` and `runtime.connectNative` sent from
WebExtensions.
These APIs are available behind the new privileged-only permission
`geckoViewAddons` and are used by GeckoView apps to communicate between content
and the app.
Depends On D22621
Differential Revision: https://phabricator.services.mozilla.com/D22622
--HG--
extra : moz-landing-system : lando
It's easier this way than fixing who knows how many Webextension APIs that have
learned from Desktop that there is no tab #0 and that therefore refuse to work
in our first tab.
We'll also make a similar change to GeckoView's stub implementation of the tab
API because that affects Custom Tabs and PWAs in Fennec for now.
The tests for tab ID 0 are therefore no longer required - they were added in a
previous attempt to fix the Webextension APIs themselves, which was ultimately
never carried through to completion, though.
Differential Revision: https://phabricator.services.mozilla.com/D26431
--HG--
extra : moz-landing-system : lando
It's easier this way than fixing who knows how many Webextension APIs that have
learned from Desktop that there is no tab #0 and that therefore refuse to work
in our first tab.
We'll also make a similar change to GeckoView's stub implementation of the tab
API because that affects Custom Tabs and PWAs in Fennec for now.
Differential Revision: https://phabricator.services.mozilla.com/D26431
--HG--
extra : moz-landing-system : lando
This autofill popover was being displayed in the incorrect place because the display rect we were providing to the `AutofillManager` was the rect for the `GeckoView` and not the rect for the HTML element that the autofill popover was relating to.
1. Add view dimensions to info passed to autofill in `GeckoViewAutoFill`.
2. Use those view dimensions to calculate the correct location on the screen using `pageToScreenMatrix` in `GeckoSession`.
The resulting locations were incorrect, as the values used by `pageToScreenMatrix` were out of date. The `GeckoSession` was only notified about updated metrics during first composite, which meant that when the metrics changed during zoom and scroll on soft keyboard presentation, `GeckoSession` was unaware of it.
3. Update `GeckoSession` with new screen metrics when they change and not only during first composite.
Despite this change ensuring that `GeckoSession` always had the correct values for the viewport size and location, the request to provide the autofill location was made before the zoom and scroll was complete, meaning that even then out of date values were used during the calculation. The intial solution was to fire an event once zoom was complete, but despite this event being fired after the new screen size had been calculcated in `AsyncCompositionManager`, `GeckoSession` did not receive the values until after the event had been processed (the calls were out by 0.024ms).
5. Call new method `onScreenMetricsUpdated` inside `SessionTextInput` after screen metrics have been updated. Call `AutofillManager#notifyViewEntered` from this function.
This was not my preferred solution to this, but timing issues meant I could not find/think of an alternative way of delaying the calculation of the autofill popover location until after `GeckoSession` had been updated.
This patch currently fixes things on GV apps. Occasionally, on Fennec, the autofill view is out of alignment slightly. This needs further work.
Differential Revision: https://phabricator.services.mozilla.com/D25406
--HG--
extra : moz-landing-system : lando
This autofill popover was being displayed in the incorrect place because the display rect we were providing to the `AutofillManager` was the rect for the `GeckoView` and not the rect for the HTML element that the autofill popover was relating to.
1. Add view dimensions to info passed to autofill in `GeckoViewAutoFill`.
2. Use those view dimensions to calculate the correct location on the screen using `pageToScreenMatrix` in `GeckoSession`.
The resulting locations were incorrect, as the values used by `pageToScreenMatrix` were out of date. The `GeckoSession` was only notified about updated metrics during first composite, which meant that when the metrics changed during zoom and scroll on soft keyboard presentation, `GeckoSession` was unaware of it.
3. Update `GeckoSession` with new screen metrics when they change and not only during first composite.
Despite this change ensuring that `GeckoSession` always had the correct values for the viewport size and location, the request to provide the autofill location was made before the zoom and scroll was complete, meaning that even then out of date values were used during the calculation. The intial solution was to fire an event once zoom was complete, but despite this event being fired after the new screen size had been calculcated in `AsyncCompositionManager`, `GeckoSession` did not receive the values until after the event had been processed (the calls were out by 0.024ms).
5. Call new method `onScreenMetricsUpdated` inside `SessionTextInput` after screen metrics have been updated. Call `AutofillManager#notifyViewEntered` from this function.
This was not my preferred solution to this, but timing issues meant I could not find/think of an alternative way of delaying the calculation of the autofill popover location until after `GeckoSession` had been updated.
This patch currently fixes things on GV apps. Occasionally, on Fennec, the autofill view is out of alignment slightly. This needs further work.
Differential Revision: https://phabricator.services.mozilla.com/D24397
--HG--
extra : moz-landing-system : lando
We really want GeckoView's single remote debugigng setting to
determine whether the engine can be remote controlled, but we're not
quite there yet. The devtools use an abstract UNIX socket for this
purpose, but Marionette uses a TCP socket that defaults to port 2828,
and that means we see cross-App clashes for that port.
Functionally this means that enabling Marionette reverts to the "old
method": either pass the "--marionette" command line argument or set
the `MOZ_MARIONETTE=1` environment variable to enable. Callers remain
responsible for ensuring that the Marionette port is available.
Differential Revision: https://phabricator.services.mozilla.com/D25138
--HG--
extra : moz-landing-system : lando
The scrollTo() and scrollBy() functions in the PanZoomController may be
used to scroll the root document in GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D18898
--HG--
extra : moz-landing-system : lando
Functionally, we want Marionette to be enabled whenever remote
debugging enabled and disabled whenever remote debugging is enabled.
That's not particularly well supported by Gecko prefs, so we don't try
to handle all situations. We force the Marionette pref whenever the
remote debugging pref changes; if consumers get themselves into a bad
state by fiddling the Marionette pref independently, that's fine:
GeckoView will take back control eventually.
There are a couple of wrinkles here. The first is that GeckoView and
Marionette race to set themselves up in "profile-after-change". We
ensure that both are configured before GeckoView notifies
"marionette-startup-requested". The second is that the initial value
of the Marionette pref is taken from the environment variable
MOZ_MARIONETTE; therefore, we set that variable when starting the
Gecko thread.
Differential Revision: https://phabricator.services.mozilla.com/D17580
--HG--
extra : moz-landing-system : lando
Once a webextension using a blocking WebRequest listener has started loading,
all network connections covered by the extension's manifest are held until the
extension is ready the process them.
One condition for the extension being ready apparently includes browser startup
having progressed far enough, as signified by "browser-delayed-startup-finished"
having been dispatched.
Therefore, we have to start sending that notification when opening a new Gecko-
View window, too, and copy Fennec's InitLater() system for that.
Unlike Fennec, we cannot tie registration of those InitLater() runnables to the
initial content load having progressed far enough because of
a) e10s, which makes that approach neither easily possible nor really sensible,
as content will load in a different process in that case, and
b) because we're racing with extension startup here - if extensions are loaded
quick enough to block even the initial page load, we'd be deadlocked: We
cannot send the notification until the page finishes loading, but the page
cannot load until we send the notification. Fennec isn't affected by the
latter problem because "sessionstore-windows-restored", which Fennec will
send in any case, serves as an alternative pathway for completing extension
startup.
And unlike Desktop, we don't really have any chrome content to paint, so we
cannot tie delayed initialisation to a paint listener for that, either.
Therefore, we simply fire off a runnable at the *end* of geckoview.js's
startup() method, which should give more pressing initialisation tasks enough of
a headstart.
For completeness, we're also adding the "browser-idle-startup-tasks-finished"
notification and thereby solve bug 1465832 as well, allowing the ScriptPreloader
to detect which scripts are commonly loaded during GeckoView startup and to
start caching and pre-parsing them.
Differential Revision: https://phabricator.services.mozilla.com/D18865
--HG--
rename : mobile/android/modules/DelayedInit.jsm => mobile/android/modules/geckoview/DelayedInit.jsm
extra : moz-landing-system : lando
***
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
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
Summary:
LastPass will fill password to all input elements which InputType is
TYPE_CALSS_TEXT and TYPE_TEXT_VARIATION_WEB_EDIT_TEXT and has no AutofillHint.
And it will fill username when InputType and AutofillHint is nothing in
<input type="text">.
Actually, current implementation of GeckoView sets InputType only for
<input type="text">, so LastPass fills password to all <input type="text">
So as workaround, we should set InputType and AutofillHint when input element
presumes username fields.
Depends on D12880
Reviewers: droeh
Reviewed By: droeh
Bug #: 1497682
Differential Revision: https://phabricator.services.mozilla.com/D12881
--HG--
extra : rebase_source : b5ab3deadf0dd67bbdb1aa7e7656fe677c6670c4
Currently, when `about:debugging` is displaying, even if move to another URL on
Android, its update does not reflect to `about:debugging` page. Because the `DOMTitleChanged` event on message manager comes from only in case of remote browser. In this patch, get the event on even not remote browser, then notify to clients.
Differential Revision: https://phabricator.services.mozilla.com/D12094
--HG--
extra : moz-landing-system : lando
Currently, some "input" event dispatchers in our script dispatch "input" event
with UIEvent. This is completely wrong. For conforming to HTML spec, Event
is proper event. Additionally, for conforming to Input Events, InputEvent
is proper event only on <textarea> or <input> element which has a single line
editor.
For making us to maintain easier, this patch adds new API, "isInputEventTarget"
to MozEditableElement which returns true when "input" event dispatcher should
use InputEvent for the input element.
Finally, this makes some dispatchers use setUserInput() instead of
setting value and dispatching event by themselves. This also makes
us to maintain them easier.
Note that this does not touch "input" event dispatchers which dispatch events
only for chrome (such as URL bar, some pages in about: scheme) for making
this change safer as far as possible.
Differential Revision: https://phabricator.services.mozilla.com/D12247
--HG--
extra : moz-landing-system : lando
Gecko doesn't support creating a remote browser from a non-remote
browser when there is an opener, so create a non-remote browser when
there is an opener, even in multiprocess mode.
Differential Revision: https://phabricator.services.mozilla.com/D11952
--HG--
extra : moz-landing-system : lando
Some pages can be either remote or non-remote depending on the current
remote type, so we need to take that into account when updating the
remote type.
Differential Revision: https://phabricator.services.mozilla.com/D11951
--HG--
extra : moz-landing-system : lando
Add GeckoView Media API which provides a way to listen to HTMLMediaElement events in a GeckoSession and control the playback externally
Differential Revision: https://phabricator.services.mozilla.com/D9026
--HG--
extra : moz-landing-system : lando
Add GeckoView Media API which provides a way to listen to HTMLMediaElement events in a GeckoSession and control the playback externally
Differential Revision: https://phabricator.services.mozilla.com/D9026
--HG--
extra : moz-landing-system : lando
Add GeckoView Media API which provides a way to listen to HTMLMediaElement events in a GeckoSession and control the playback externally
Differential Revision: https://phabricator.services.mozilla.com/D9026
--HG--
extra : moz-landing-system : lando
For improved security, default to a null triggering principal for
GeckoView.loadUri calls, except when loading certain privileged schemes
such as "resource" and "file".
Differential Revision: https://phabricator.services.mozilla.com/D7785
GeckoViewTab stubs out gBrowser on the root window for WebExtension compatibility.
LoginManagerParent also looks for gBrowser on windows that are handling username
and password form fills, and expects it to implement getBrowserForOuterWindowID.
This patch makes the stub implement getBrowserForOuterWindowID, which just returns
the lone GeckoViewTab browser.
Differential Revision: https://phabricator.services.mozilla.com/D10750
--HG--
extra : moz-landing-system : lando
For improved security, default to a null triggering principal for
GeckoView.loadUri calls, except when loading certain privileged schemes
such as "resource" and "file".
Differential Revision: https://phabricator.services.mozilla.com/D7785
--HG--
extra : moz-landing-system : lando
This patch adds a new API to GeckoSession to get the currently used
UserAgent.
Differential Revision: https://phabricator.services.mozilla.com/D8022
--HG--
extra : moz-landing-system : lando
For improved security, default to a null triggering principal for
GeckoView.loadUri calls, except when loading certain privileged schemes
such as "resource" and "file".
Differential Revision: https://phabricator.services.mozilla.com/D7785
--HG--
extra : moz-landing-system : lando
Auto-fill values can contain personal information and must not appear in
the log.
Differential Revision: https://phabricator.services.mozilla.com/D8051
--HG--
extra : moz-landing-system : lando
The crash is happening because we may not have a full node tree when
looking at a particular node; in that case we may not be able to find
the root node. This patch makes us keep track of the root node from the
beginning, so we always know what the root node is.
Differential Revision: https://phabricator.services.mozilla.com/D6758
--HG--
extra : moz-landing-system : lando
Update auto-fill info when selecting tabs. Also for auto-fill focus and
page events, only handle those events for the foreground tab, so
events from background tabs don't inadvertently affect auto-fill for the
foreground tab.
Differential Revision: https://phabricator.services.mozilla.com/D6757
--HG--
extra : moz-landing-system : lando
Update auto-fill info when selecting tabs. Also for auto-fill focus and
page events, only handle those events for the foreground tab, so
events from background tabs don't inadvertently affect auto-fill for the
foreground tab.
Differential Revision: https://phabricator.services.mozilla.com/D6757
Move all fields of nsISSLStatus to nsITransportSecurityProvider
Remove nsISSLStatus interface and definition
Update all code and test references to nsISSLStatus
Maintain ability to read in older version of serialized nsISSLStatus. This
is verified with psm_DeserializeCert gtest.
Differential Revision: https://phabricator.services.mozilla.com/D3704
--HG--
extra : moz-landing-system : lando
Move all fields of nsISSLStatus to nsITransportSecurityProvider
Remove nsISSLStatus interface and definition
Update all code and test references to nsISSLStatus
Maintain ability to read in older version of serialized nsISSLStatus. This
is verified with psm_DeserializeCert gtest.
Differential Revision: https://phabricator.services.mozilla.com/D3704
--HG--
extra : moz-landing-system : lando
Add a GeckoSession property too specify if media should be suspended when the session is inactive.
Differential Revision: https://phabricator.services.mozilla.com/D4472
--HG--
extra : moz-landing-system : lando
Make a distinction between a session being active (i.e. being visible)
and it being focused. More than one session may be active at a time, but
only one session is focused at a time. This means the focused session is
always active, but an active session may not be focused.
Also, manage setting of active/focused states in GeckoView itself, so
consumers don't generally have to worry about these states.
Differential Revision: https://phabricator.services.mozilla.com/D3251
Make a distinction between a session being active (i.e. being visible)
and it being focused. More than one session may be active at a time, but
only one session is focused at a time. This means the focused session is
always active, but an active session may not be focused.
Also, manage setting of active/focused states in GeckoView itself, so
consumers don't generally have to worry about these states.
Differential Revision: https://phabricator.services.mozilla.com/D3251
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.
Fix the clear() call to clear highlights in addition to the selection.
MozReview-Commit-ID: 1DNXa8fIGTP
--HG--
extra : rebase_source : c84033c644becf2c9b0e7df8d2580523e75de97d
Ehsan Akhgari
Razvan Maries
Elliot Stirling
Dylan Roeh
arthur.iakab
James Willcox
Noemi Erli
Dorel Luca
Thomas Nguyen
chrmod
Cosmin Sabou
Julian Descottes
Randall E. Barker
Kris Maglione
Coroiu Cristina
Bogdan Tara
Eugen Sawin
Eugen Sawin
Alvina Waseem
Gurzau Raul
Brindusan Cristian
Agi Sferro
Jonathan Kingston
Victor Porof
Boris Zbarsky
Emilio Cobos Álvarez
Sean Feng
Emily Toop
Narcis Beleuzu
Makoto Kato
Sebastian Hengst
Ryan Hunt
Christoph Kerschbaumer
Rob Wu
Agi Sferro
Jan Henning
Csoregi Natalia
Oana Pop Rus
Andreea Pavel
Nick Alexander
shindli
Myk Melez
Daisuke Akatsuka
Masayuki Nakano
Jim Chen
Imanol Fernandez
Matt Brubeck
Mike Conley
Daniel Varga
Mark Banner
Eitan Isaacson
Ciure Andrei
Tiberius Oros
Dipen Patel
Imanol Fernandez