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
Replacing js and text occurences of asyncOpen2
Replacing open2 with open
Differential Revision: https://phabricator.services.mozilla.com/D16885
--HG--
rename : layout/style/test/test_asyncopen2.html => layout/style/test/test_asyncopen.html
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
Currently, the Android front-end uses a tab's base domain both for permission
prompt doorhangers, as well as for doing domain highlighting in the URL bar. The
base domain in turn is based on the document's nodePrincipal's URI.
As per bug 1325955, the nodePrincipal is the right choice for permission
prompts, but it causes some problems for domain highlighting instead: For error
pages for example, the nodePrincipal's URI will be some variety of
about:neterror, which means that the front-end won't be able to do any domain
highlighting based on that, since
a) we don't generate any baseDomain anyway because the URI's scheme isn't
HTTP(S)/FTP, and
b) even if we did, the nodePrincipal's baseDomain won't match the contents of
the URI displayed in the URL bar.
Therefore, we want to separate these two concerns, and generate two baseDomains:
One based on the nodePrincipal for use in permission prompts, and one based on
the display URI, which going forward will power our domain highlighting.
Differential Revision: https://phabricator.services.mozilla.com/D18586
--HG--
extra : moz-landing-system : lando
This is a rollup of all the patches that have landed on the cedar project branch:
891252fdd0
Bug 1492475 - Part 1: Migrate most, if not all nsSearchService consumers to use async APIs. r=florian
79b2eb2367
Bug 1492475 - Part 2: Move nsIBrowserSearchService.idl to toolkit/components/search/nsISearchService.idl and update references. r=florian
a947d3cdf0
Bug 1492475 - Part 3: The search service init() method should simply return a Promise. r=florian
c1e172dfac
Bug 1492475 - Part 4: Remove the synchronous initialization flow. r=florian
cd41189eac
Bug 1492475 - Part 5: Since async initialization of the search service now is implicit behavior, remove the distinctive verbiage used internally. r=florian
2ae7189dfa
Bug 1492475 - Part 6: Update the cache build task to work with an actual Promise and re-initialize only once at the same time - all to fix race conditions here. r=florian
c8ee92973f
Bug 1492475 - Part 7: Make the region fetch not block the init flow, to ensure it's as fast as possible. r=florian
c44e674e16
Bug 1492475 - Part 8: Introduce an init flag, which can only be used privately, that allows to explicitly skip waiting for the region check process to complete. r=florian
6c79eaf1d3
Bug 1492475 - Part 9: Update unit tests to stop using 'currentEngine', in favor of 'defaultEngine'. r=Standard8
21b3aa17ee
Bug 1492475 - Part 10: Update unit tests to be fully aware of the new, async signatures of the search service API and remove sync init flow tests. r=mkaply,florian
ce5ba69019
Bug 1492475 - Part 11: Repair incorrect usage of the `identifier` property of nsISearchEngine instances. r=florian
fd177a7994
Bug 1518543 - Fix up the Android (Fennec) nsISearchService shim to work with the new asynchronous API. r=florian
3653d8ee22
Bug 1523708 - Change the search service interaction in the show-heartbeat action to use the new async API. r=florian
Differential Revision: https://phabricator.services.mozilla.com/D18355
--HG--
rename : netwerk/base/nsIBrowserSearchService.idl => toolkit/components/search/nsISearchService.idl
extra : moz-landing-system : lando
The desktopMode property on Fennec's tab object is already being correctly being
preserved when (re)creating a tab [1], but we don't propagate its state to the
content window's desktop viewport mode setting.
[1] When restoring into a fresh tab, the session restore code passes the stored
desktopMode flag to addTab, whereas zombifying an existing tab destroys its
<browser>, but leaves the tab object's properties intact, so we merely need to
re-set the desktop viewport mode on the new <browser>'s content window.
Differential Revision: https://phabricator.services.mozilla.com/D17774
--HG--
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
onSecurityChange from browser.js will not send information about tracking
anymore to Java (because it doesn't know about that anymore).
onContentBlocking from browser.js will be responsible for this from now on.
is called after onSecurityChange which will have created a SiteIdentity()
for that tab in Java
is informed only about tracking status which it caches to only send updates
downstream to Java. Will not propagate identical events one after the other.
will not fire for websites which do not contains any tracking elements
A Content:ContentBlockingEvent received in Java will update the tracking
property of SiteIdentity and finally update the UI with
ToolbarDisplayLayout#updateSiteIdentity().
Differential Revision: https://phabricator.services.mozilla.com/D16822
Let SessionStoreUtils be a WebIDL namespace, rather than a XPCOM service
Differential Revision: https://phabricator.services.mozilla.com/D9776
--HG--
rename : toolkit/components/sessionstore/nsSessionStoreUtils.cpp => toolkit/components/sessionstore/SessionStoreUtils.cpp
extra : moz-landing-system : lando
Summary:
The reason for this ticket was that it was not immediately obvious for
Sync users that deleting logins on this device may affect all logins stored in
user's Sync account. So it was possible that users could unintentionally loose
all their login data.
While we should still offer the option to remove login data, even to Sync users,
we will explicitly inform them that deleting logins can affect all their
synced logins.
Also refactored the code to minimize duplicated code.
Depends on D16026
Reviewers: JanH, #geckoview-reviewers
Reviewed By: JanH
Subscribers: reviewbot, flod
Bug #: 1473470
Differential Revision: https://phabricator.services.mozilla.com/D16027
--HG--
extra : rebase_source : a0e83ce91e7d217c6b46fa81472eb5f54c92420d
extra : histedit_source : b9d9435857c04a73d960275409fd65cf1725edcb
Given the usage example of pull-to-refresh in bug 1371796, downstream consumers
will probably more interested in the true visible scroll position of the user
within the page, i.e. the visual viewport.
Listening for *visual* viewport events will also definitively be required to
get the saveAndRestoreState GeckoView test properly working once we switch
Gecko's session store helper function to use the *visual* viewport scroll
position.
Differential Revision: https://phabricator.services.mozilla.com/D15682
--HG--
extra : moz-landing-system : lando
In order to make the history easier to navigate, this changeset includes the
modifications required to make <xul:browser> actually work as a Custom Element,
and switches the app to use it instead of the XBL browser.
Differential Revision: https://phabricator.services.mozilla.com/D14911
--HG--
extra : moz-landing-system : lando
Let SessionStoreUtils be a WebIDL namespace, rather than a XPCOM service
Differential Revision: https://phabricator.services.mozilla.com/D9776
--HG--
rename : toolkit/components/sessionstore/nsISessionStoreUtils.idl => dom/chrome-webidl/SessionStoreUtils.webidl
rename : toolkit/components/sessionstore/nsSessionStoreUtils.cpp => toolkit/components/sessionstore/SessionStoreUtils.cpp
extra : moz-landing-system : lando
There are multiple fixes contained in this patch:
- fixes for Android/mobile support
- adding extra strings to the ftl file that were never defined before, and previously the ID was just printed to the page
- update test_l10n.py to not rely on about:support anymore
- changing Troubleshoot.jsm to return and ID and args for the strings that should be displayed, so it is compatible with the Fluent API
- misc. fixes so strings that are not localized don't go through the Fluent codepath
Differential Revision: https://phabricator.services.mozilla.com/D15437
--HG--
extra : moz-landing-system : lando
Audio/video related context menu entries are already doing this as far as I can
tell.
Differential Revision: https://phabricator.services.mozilla.com/D15382
--HG--
extra : moz-landing-system : lando
Desktop does this when copying link URLs and sharing is just effectively just
another form of copying.
For completeness, we also apply this when "viewing" the source of images (which
just displays the image itself anyway).
No special handling is required for other media elements (audio/video), because
looking at those in view-source mode does display the raw file contents and
thus none of the media-specific context menu entries will show up.
Differential Revision: https://phabricator.services.mozilla.com/D15381
--HG--
extra : moz-landing-system : lando
Randall Barker
Jonathan Kingston
Gijs Kruitbosch
shindli
Yuan Cheng
Jan Henning
Mike de Boer
Mike Conley
Dylan Roeh
Myk Melez
Eugen Sawin
Cosmin Sabou
Alphan Chen
Nick Alexander
Ciure Andrei
arthur.iakab
Kris Maglione
Petru-Mugurel Lingurar
Ehsan Akhgari
Sebastian Hengst
Christoph Kerschbaumer
Brian Grinstead
Bogdan Tara
Hiroyuki Ikezoe
Mark Banner
Jared Wein
James Willcox