This was done by way of hacking our vendored version of org.simple.json.
MozReview-Commit-ID: GpTFpmeevVN
--HG--
extra : rebase_source : 2a29b53919a617e2ea89d776a53a43257959bc22
Add a test case to testInputConnection that makes sure GeckoEditable's
Editable interface still behaves correctly even after disconnecting from
Gecko due to a blur.
MozReview-Commit-ID: 7Z6Kpv2tpRy
--HG--
extra : rebase_source : 9ec338c77d362a86fb0097b51bd4d55a15654f43
Extend timeout for testEventDispatcher to 40 seconds and fix a bug where
the wrong mode is used for event callback tests. r=me for trivial
test-only fix.
MozReview-Commit-ID: JiyW8lFW8kg
The main goal of these changes is to ensure we're not doing any unnecessary work
in the unahppy cases of BatchingUploader. We might fail in three general ways:
- encounter a 412 error
- encounter another type of HTTP error
- encounter a GUID in the "failed" array
Currently, in all of these cases, we de-facto abort the session, without performing
an actual abort. E.g. we won't commit a batch, we'll refuse to upload any still-flowing
records. This patch simplifies our unhappy-case behaviour: if something failed, actually
abort the session (triggering a shutdownNow of the work queues), declare store as failed, etc.
It's important to note that our "did the synchronization fail?" login in the SynchronizerSession
depends on the store failure counts, and so this patch maintains the "record failed to store"
delegate chain. However, these counts are largely meaningless. What does it mean to fail to store
50 records, if we abort on the 51st, and prevent the other 100 from flowing (and from being counted
as failed?).
This patch also fixes an omission in the verstion tracking logic:
- prior, if we encountered a record in the "failed" array, we'd continue on with the flow, won't upload
anything, mark the synchronization as failed, but we'd also call into 'onStoreCompleted' which will
trigger an update of syncVersion for outflowing records
- with this patch, we won't call into onStoreCompleted in the case above, and so won't update syncVersion
in case of such failures
- this is the correct behaviour for batching uploads (now enabled on all but one server), but possibly
non-optimal behaviour if batching isn't enabled. However, this behaviour should be safe from a data consistency
point of view regardless of the batching mode.
MozReview-Commit-ID: LIYCPaRX8JA
--HG--
extra : rebase_source : 110224b2db85a383635db933ec6c19b21af886e7
Find the Fennec LayerView through `Solo.getView()` and the View id
instead of going through `GeckoAppShell.getLayerView()`.
MozReview-Commit-ID: FVcPM0fYorf
--HG--
extra : rebase_source : 1787cfde739eac742d28244ab29579a789997b81
Find the Fennec LayerView through `Solo.getView()` and the View id
instead of going through `GeckoAppShell.getLayerView()`.
MozReview-Commit-ID: FVcPM0fYorf
--HG--
extra : rebase_source : c446302e957c5c1136a6a670735ce9df2dc3f41a
Before we'd recurse instead while fetching multiple batches, overflowing the stack on older devices.
MozReview-Commit-ID: 37BG6zGBdn0
--HG--
extra : rebase_source : 2e9d2eeeba247454051e9fe4ab875d9f9ca5e2d4
Change the subscripts (e.g. FormAssistant.js) that we load in BrowserCLH
into proper .jsm modules. This avoids the `defineLazyScriptGetter`
incompatibility mentioned in the bug, and when we turn on shared JSM
global, any memory advantage we get from using subscripts should not
matter anymore.
MozReview-Commit-ID: krSwANdtb5
--HG--
rename : mobile/android/chrome/content/ActionBarHandler.js => mobile/android/modules/ActionBarHandler.jsm
rename : mobile/android/chrome/content/FormAssistant.js => mobile/android/modules/FormAssistant.jsm
rename : mobile/android/chrome/content/InputWidgetHelper.js => mobile/android/modules/InputWidgetHelper.jsm
rename : mobile/android/chrome/content/SelectHelper.js => mobile/android/modules/SelectHelper.jsm
rename : mobile/android/chrome/content/WebrtcUI.js => mobile/android/modules/WebrtcUI.jsm
extra : rebase_source : fa361c9eeea38485ba6a8f6c49321c32304d4006
Sometimes Robocop is confused when are multiple `R.id.menu` UI components shown on screen,
one is the menu button on toolbar and otehrs are context menus on Activity Stream.
To access the menu on toolbar, a simple fix is access toolbar first and use it to find its child.
MozReview-Commit-ID: Jw4sTLeR3li
--HG--
extra : rebase_source : 337c3df3ffd36a4d26547b994aba3ce7647bafc8
Use the BrowserCLH for PromptService startup, to consolidate startup
handling code and also to delay loading PromptService.
MozReview-Commit-ID: 25UgVH7wrrs
I tested this through the unit tests I added.
In theory, we could also validate URLs to make sure they're valid but users
should see 404s if they're not valid so this seems like unnecessary code.
MozReview-Commit-ID: 3XqsMawLabj
--HG--
extra : rebase_source : 7e395dfdb6016f3cb9973e5642c8377928c8fa64
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
We found sometimes Robocop operates wrong UI components when it deals with a complex layout.
Since default panel shows Activity Stream which contains complex UI components, we configure
bookmarks panel as default panel to keep the layout as simple as possible.
MozReview-Commit-ID: 12xhVOdlIRK
--HG--
extra : rebase_source : fcb1a42e8e0ccdb06fd17bcb14880ed4a650efc7
The permissions check itself is synchronous, but if we then decide to prompt the user to acquire the permission, we have to do so asynchronously and eventually continue execution on the UI thread as a result. Therefore we need to provide a counterpart of onUIThread() for operations that want their callback to stay off the UI thread in all situations.
MozReview-Commit-ID: AOCX1v69R1J
--HG--
extra : rebase_source : ed0bab9f3ae3198bf2af90eabc86fd5ddd95b3a0
