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
Part 1 - Add methods for each setting in `GeckoSessionSettings`.
Migrate existing code to use these new methods instead of the exisiting get/set<DataType>(Key, Value) methods.
Part 2 - Make old methods and fields for get/set<DataType> in `GeckoSessionSettings` private.
Part 3 - Migrate existing code to use these new methods instead of the exisiting get/set<DataType>(Key, Value) methods.
Part 4 - Add Builder to `GeckoSessionSettings` to handle setting of init only fields.
* Make setters for init only fields protected.
* Remove tests that ensure that init only fields throw an error when set on the fly as this is no longer possible.
* Update tests to use builder when init-ing settings.
* Update API doc to reflect new public API.
Part 5 - Update `CHANGELOG.md`.
Part 6 - Update `geckoview_example` to use new methods.
Part 7 - Fetch `CHROME_URI` key when calling `getChromeUri` rather than incorrect `USER_AGENT_OVERRIDE`
Differential Revision: https://phabricator.services.mozilla.com/D15651
--HG--
extra : moz-landing-system : lando
Refreshing account (triggered by signing in) can cause a NullPointerException after quickly signing out.
This defect consists in bad sync between the signing in state and signing out state.
Differential Revision: https://phabricator.services.mozilla.com/D14269
--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
We want to remove recently closed tabs from the session store when they get re-
stored again, and for that we need something to uniquely identify them.
As tab IDs are unique per session only, this means that the tab IDs of recently
closed tabs resurrected from the previous session could conflict with tabs that
have been freshly opened in the current session.
E.g. tab 2 has been closed in a previous session and is now part of the session
store's closed tab list. In the current session, a number of tabs are opened
again and then what is now the *current* tab 2 is closed as well. The result
would be that the session store now has two closed tabs with a tab ID of 2.
To avoid that scenario, all recently closed tabs are renumbered with an ID in
the negative range at the start of the session. Therefore all tabs originally
opened in the current session will have a tab ID >= 0, while all recently closed
tabs coming directly from a previous session will have a negative tab ID, < -1.
(-1 itself remains the sentinel value for an invalid tab ID).
Differential Revision: https://phabricator.services.mozilla.com/D15331
--HG--
extra : source : 971ebdae024e188a913d2eda452a7761b4b38d1b
extra : histedit_source : b04ac438d2d7325d35e300946fcdb2a385b1598c
We want to remove recently closed tabs from the list that have been restored
again. At the moment this only works if the tab data never leaves Gecko, because
in undoCloseTab(), the session store determines the tab data to be removed from
its closed tab collection by checking for equality with the tab data that was
passed as an argument to undoCloseTab().
So a tab restored through the "Undo" snackbar will be removed from the "Recently
closed" list, but a tab restored from the History home panel won't, because in
the latter case the tab data will have been serialised and deserialised while
travelling back and forth between Gecko and the Android UI.
Hence we're going to switch the system to identify tabs through their tab ID
instead.
If automatic session restoring is turned off, the "Recently closed" home panel
also displays all tabs that were open in the previous session. Those tabs aren't
coming directly from the session store; instead the Android UI reads them
directly from the corresponding file on disk. Therefore, when restoring such a
tab we need to make sure that the session store won't attempt to find and remove
that tab from its own list of recently closed tabs.
To that effect, we therefore simply drop the "tabId" when parsing the "last
session" file from disk.
Differential Revision: https://phabricator.services.mozilla.com/D15330
--HG--
extra : source : cedb3b5d62a6019a1176f2196848d7bb43c74e9d
extra : histedit_source : 88e2c1f549c98d0cf9adeaf91891f3de61fca499
Nobody within mobile or toolkit is currently using it.
Differential Revision: https://phabricator.services.mozilla.com/D15328
--HG--
extra : source : 531c402060ecc2bc3d1119ecaf3b49b29e03e3cc
extra : histedit_source : 0e86b12909c5f76605304a0a0ff4088031a7b8b9
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
On versions prior to Android N (24), initializing the WifiManager via Context#getSystemService can cause a memory leak if the context is not the application context.
Differential Revision: https://phabricator.services.mozilla.com/D14721
--HG--
extra : moz-landing-system : lando
This is because these persmissions are the responsibility of the embedding app to request,not GeckoView's.
Differential Revision: https://phabricator.services.mozilla.com/D14722
--HG--
extra : moz-landing-system : lando
The AOSP ExternalStorageProvider always creates document IDs of the form
"storage device ID" + ':' + "document path", where the storage device ID will
be "primary" for the primary emulated storage and the file system UUID for
everything else.
Assuming that OEMs won't customise this behaviour, the main problem that needs
to be handled is how to turn the file system UUID back into a file system path.
Differential Revision: https://phabricator.services.mozilla.com/D15259
--HG--
extra : moz-landing-system : lando
Because getOriginalFilePathFromUri() doesn't use framework methods newer than
Kitkat, instead of a generic @SuppressLint("NewAPI") it would be better to use
@TargetApi(19), so you still get warned if you start using framework methods
more recent than API19.
However because the isKitkat helper variable is only used in one place, in the
end we simply replace it with a direct Build.VERSION.SDK_INT check, so that we
don't have to use any special handling for the linter.
Differential Revision: https://phabricator.services.mozilla.com/D15258
--HG--
extra : moz-landing-system : lando
Instead, getOriginalFilePathFromUri() will simply *always* return null if it
cannot divine the original file path, and consequently resolveContentUri() will
then always fall back to the temp file method if getOriginalFilePathFromUri()
returns null.
Differential Revision: https://phabricator.services.mozilla.com/D15257
--HG--
extra : moz-landing-system : lando
Brian Grinstead
John Lin
Brindusan Cristian
Tim Nguyen
Axel Hecht
Emily Toop
Andrei Lazar
Oana Pop Rus
Randall Barker
alwu
Bogdan Tara
Csoregi Natalia
Cameron McCormack
Razvan Maries
Cosmin Sabou
Alphan Chen
Vlad Baicu
Mark Banner
Jan Henning
Emilio Cobos Álvarez
Gijs Kruitbosch
Agi Sferro
James Willcox
Hiroyuki Ikezoe
Michael Kaply
Ciure Andrei