Our user-facing builds crash if we manage to slip in some main thread network access by mistake (which is the default Android StrictMode policy since Honeycomb), so our developer builds shouldn't be more forgiving here.
MozReview-Commit-ID: 6bZwwwrSb3q
--HG--
extra : rebase_source : 8f4258de89f141ce6d3b2b141b1e4daa1dc6f6aa
This patch is necessary for the previous changesets to take effect.
MozReview-Commit-ID: 98IemAEgbmi
--HG--
extra : rebase_source : 31b39d30c9b682a9f998add9b47d6743375d0c99
This is part 1 of the good-enough approach: see the MAX_SCALE_FACTOR comment
as to what we're aiming for. The next changeset will discard any icons that
do not look good being scaled so much.
The MAX_SCALE_FACTOR field is non-private because it's used in the next
changeset.
MozReview-Commit-ID: HGzdQBEuMAy
--HG--
extra : rebase_source : 995262e4975a4ebd713cc81f29bc9e84ee2b8d9f
Move the form fill event listeners out of browser.js and into
BrowserCLH.js, and update them to support chrome windows, so we can
handle form fill events for Fennec, custom tabs, and PWAs.
MozReview-Commit-ID: Fb5gWmGvxfE
--HG--
extra : rebase_source : 1ecb7f83bc8022cb3fef1a5ffa9d9d084b837bf4
Use the BrowserCLH for PromptService startup, to consolidate startup
handling code and also to delay loading PromptService.
MozReview-Commit-ID: 25UgVH7wrrs
--HG--
extra : rebase_source : 162ee97db80608caf3c5cd93734764bc87b99c6f
Move `addLazyGetter` and `addLazyEventListener` utility functions from
GeckoViewStartup.js into GeckoViewUtils.jsm, so they can be used for
both Fennec and standalone GeckoView.
Also switch to "chrome-document-loaded" for loading
DownloadNotifications because that's later in the startup sequence.
MozReview-Commit-ID: 1caMtufkHGR
--HG--
extra : rebase_source : eea04495bd96e98a83d4874709f2a88d989ee466
Call `onBackPressed()` when `android.R.id.home` is selected to make sure the same click behavior between
HomeAsUpIndicator and back button.
MozReview-Commit-ID: 3tTKtbDTugg
--HG--
extra : rebase_source : 5b59a4c23efb30bade427a28242885480cbedf77
Due to how we access our prefs files (read: all over the place), the idea here is to perform the migration whenever
some component actually attempts to get the prefs. This guarantees that every consumer of prefs will receive the
correct version, and we won't accidentally duplicate our shared prefs either.
I would have preferred to just perform this migration at a set point.
We have a "services upgrade point" - FxAccountUpgradeReceiver - which receives a "package upgraded" intent and kicks
off some async work. Unfortunately, we can't guarantee that its tasks won't overlap with our uses of prefs
(either in the background or foreground code).
MozReview-Commit-ID: AWQ4IY7i32F
--HG--
extra : rebase_source : 7f585e8a71291fb812937b4846ce790a9b332fac
This patch is necessary for the previous changesets to take effect.
MozReview-Commit-ID: 98IemAEgbmi
--HG--
extra : rebase_source : 2609d0168b525b96a4392c15430a7dc85323da59
This is part 1 of the good-enough approach: see the MAX_SCALE_FACTOR comment
as to what we're aiming for. The next changeset will discard any icons that
do not look good being scaled so much.
The MAX_SCALE_FACTOR field is non-private because it's used in the next
changeset.
MozReview-Commit-ID: HGzdQBEuMAy
--HG--
extra : rebase_source : 9ac7ad89e0866a3af89c4086ae59255ebedeb31c
suneet
Andrew Swan
Sebastian Hengst
Grigory Kruglov
Eugen Sawin
sajattack
Francois Marier
Chenxia Liu
Michael Comella
Jan Henning
Sebastian Kaspari
Jim Chen
Jing-wei Wu
Wes Kocher