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
We temporarily hide `home_add_to_launcher` in API 26, which means directly accesses it without checking
if it exists or not would cause NullPointerException.
MozReview-Commit-ID: KXnP81ZZa6u
--HG--
extra : rebase_source : 9189f3ab940d50702f82365824feff441faeef5a
Remove `GeckoAppShell.setLayerView()/getLayerView()` now that it's no
longer used anywhere.
MozReview-Commit-ID: 6URNFhSs01P
--HG--
extra : rebase_source : bd76d75fe26f9c3d8782475767e5a48fcd2cb9eb
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
Pass in a `GeckoView` instance when sending a11y events so we're not
dependent on `GeckoAppShell.getLayerView()`. However, there's likely
more work to be done to make a11y work for any GeckoView.
MozReview-Commit-ID: DBeDOX5c3qY
--HG--
extra : rebase_source : 49d9a06ec90543c49d03f298a7d78ea54bbe0a58
Let `GeckoLayerClient` directly deal with scroll-to-input on resize,
instead of going through `GeckoAppShell` and relying on
`getLayerView()`. This is a necessary fix to let us remove
`getLayerView()`, and in a follow-up bug we should actually fix
scroll-to-input to work on any GeckoView.
MozReview-Commit-ID: 1xsHh2vg08M
--HG--
extra : rebase_source : 3061623d3ed0309fff42c6dc66d0246e1d3000a3
In GeckoInputConnection, use the current view available through
`getView()`, instead of using `GeckoAppShell.getLayerView()`.
MozReview-Commit-ID: Hc9AUz5SNEs
--HG--
extra : rebase_source : c42a81bb9b46f79e0a1b827d16ac7494579017e6
Instead of using `getLayerView()` to perform haptic feedback, this patch
adds a `HapticFeedbackDelegate`, which `GeckoApplication` implements to
call `performHapticFeedback()` on the active view. Also, use
HapticFeedbackDelegate elsewhere in the Fennec codebase where we want to
perform haptic feedback.
MozReview-Commit-ID: GAArA6yJFNF
--HG--
extra : rebase_source : 683520b1b314ff0376a6fc843415a8485650e80b
Add a diagnostic crash for the unexpected case where
GeckoService.register() is called a second time. We know the stack for
the second call, but we want to know the stack for the first call, so we
introduce this intentional crash. r=me for trivial diagnostic patch
which will be backed out ASAP.
MozReview-Commit-ID: HobtPiVSSTR
To be honest, I'm not sure why this works. onSizeChanged seems to be a callback
to notify the user that your layout has completed and not a place to update
layout params. However, it makes *slightly* more sense that you could update
your children's layout from this view, which is what this patch changes the
code to do.
I think I could figure out why this works if I dug further into [1] but I have
other things to focus on.
I don't think this is the most correct solution, but it is likely the smallest
and least risky change we can make to fix this issue, which is ideal because
we'd like to uplift this to the 57 Beta.
A more correct solution would override the Activity Stream RecyclerView and
provide different desired measurements to its parent so that the new size is
set *during* layout rather than after it, which would make the layout process
more efficient. However, this type of code is less commonly written day-to-day
by developers so it's harder to write, harder to maintain, and I'd have to read
a lot of [1] in order to write it. :)
[1]: https://developer.android.com/guide/topics/ui/how-android-draws.html
MozReview-Commit-ID: AceUvDYGWCR
--HG--
extra : rebase_source : 5fe014388db8e4186c2cda54a453930bf8eed211
gcc 4.9 is the last version in Android NDK and our minimum requirement of gcc is 4.9+. --with-android-gnu-compiler-version is unnecessary option because gcc version of Android is always 4.9.
MozReview-Commit-ID: 1sutqlvbQU5
--HG--
extra : rebase_source : 77e42aba81da5276bcddd945ea41895ce2461afa
The proper solution here is to put MORE and the arrow in a single focusable
container but this needs to get uplifted so I went with the simpler change.
For non-visual users, there is no difference. For visual users, the only "more"
is focused, rather than "more" and the arrow in one container. The code as it
is slightly more complex because we have to hide and add click listeners to
multiple objects.
MozReview-Commit-ID: JZFLc8jvXII
--HG--
extra : rebase_source : e31aa207b204ace35871acbded1e753fdb636874
Remove `GeckoAppShell.setLayerView()/getLayerView()` now that it's no
longer used anywhere.
MozReview-Commit-ID: 6URNFhSs01P
--HG--
extra : rebase_source : 202177e049d969efba04290b228dd67a15ebe3f4
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
Pass in a `GeckoView` instance when sending a11y events so we're not
dependent on `GeckoAppShell.getLayerView()`. However, there's likely
more work to be done to make a11y work for any GeckoView.
MozReview-Commit-ID: DBeDOX5c3qY
--HG--
extra : rebase_source : 0c6c76d326b755671d2d29109823ceaf1aa627ba
Let `GeckoLayerClient` directly deal with scroll-to-input on resize,
instead of going through `GeckoAppShell` and relying on
`getLayerView()`. This is a necessary fix to let us remove
`getLayerView()`, and in a follow-up bug we should actually fix
scroll-to-input to work on any GeckoView.
MozReview-Commit-ID: 1xsHh2vg08M
--HG--
extra : rebase_source : c09c906cbdaf2b3bea96ecfcec1f25bdef4fa31d
In GeckoInputConnection, use the current view available through
`getView()`, instead of using `GeckoAppShell.getLayerView()`.
MozReview-Commit-ID: Hc9AUz5SNEs
--HG--
extra : rebase_source : 3e55c4ac8749b75e6f5bc50a2b706f7f4ad264e8
Instead of using `getLayerView()` to perform haptic feedback, this patch
adds a `HapticFeedbackDelegate`, which `GeckoApplication` implements to
call `performHapticFeedback()` on the active view. Also, use
HapticFeedbackDelegate elsewhere in the Fennec codebase where we want to
perform haptic feedback.
MozReview-Commit-ID: GAArA6yJFNF
--HG--
extra : rebase_source : c9ac6e28584ca2b6c6fb707444cca8dc08abe649
Before we'd recurse instead while fetching multiple batches, overflowing the stack on older devices.
MozReview-Commit-ID: 37BG6zGBdn0
--HG--
extra : rebase_source : 2e9d2eeeba247454051e9fe4ab875d9f9ca5e2d4
When I implemented this, I forgot to add it to non-phone configurations.
MozReview-Commit-ID: 4zTrYZm5tXR
--HG--
extra : rebase_source : ea0a8606d8bd9cc82c020102a25f2f59724be1f6
Small fixes to ride-along in this bug:
* Use localized ellipsis in ActionBarHandler if available.
* Fix one situation where the FormAssistPopup fails to hide.
* Handle an error case in FormAssistant.
MozReview-Commit-ID: 9EZhPnS5h3E
--HG--
extra : rebase_source : a05c13c242158cc1396912378b6f529eea38b0de
Use the universal DoorHanger API from Prompt.jsm to show the login
doorhanger from any window. Also, refactor parts of LoginManagerPrompter
to use Services.jsm if possible.
MozReview-Commit-ID: 3cnzeT0RNgR
--HG--
extra : rebase_source : 70a926fec8d15c70a75f6afe771e973fd62fe9c9
Now that we have a Docker image with newer library versions on it, we
can move our builds over. The new images differ from the old
CentOS-based images in two important ways, though:
1) The system compilers in the new image are new enough to be used as
host compilers; additionally, our CentOS-built GCC compilers will not
work. We need to change the Android mozconfigs to reflect that. We
also need to change the Android tasks to not depend on the GCC
toolchain builds.
2) In a similar fashion, we can use the system JDK; we no longer need to
use the JDK from the Android NDK, which we had packaged up via the
Android dependencies task.
Both of these changes come with caveats: our l10n repack jobs continue
to run on the CentOS-based images; l10n repacks have not been completely
converted to Taskcluster. So we need to:
1) Retain the use of our custom GCC toolchain for HOST_CC/HOST_CXX on
the CentOS-based images.
2) Retain the JDK packages in the tooltool manifests, and referencing
them when we build on the CentOS-based images.
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
(by nalexander, from Bug 1375571)
This is follow-up to Bug 1220892, which just forgot to remove these strings.
MozReview-Commit-ID: 2WLa0AC8BZp
--HG--
extra : rebase_source : cc0d4711a0f4d38980a67ed64054cf96b5683a1b
CLOSED TREE
--HG--
extra : amend_source : 84120d6bacb5d72a9fbe41e4c3b405d63825da7c
extra : histedit_source : 8320c2193761b745f10850055ee74a3c9ac73615%2Cfbc2a28d8c5004a53305ef858ca5aea4245691e0
Add a `window` parameter to all Prompt.jsm usages, so the prompt will
appear in the correct window. This includes HelperAppDialog.js, which
was preventing the download chooser dialog from appearing in a custom
tab window.
The patch also moves `getActiveDispatcher` from GeckoViewPermission to
GeckoViewUtils, and makes several improvements to `getChromeWindow` and
`getDispatcherForWindow`. Prompt.jsm now uses the active
WindowDispatcher in the fallback scenario where we don't have a window.
MozReview-Commit-ID: KpAFMCZzQZp
Icons apparently doesn't fade images, however, so it looks bad. Also, we try to
request the image each time we bind, so scrolling up and down will create
additional pop-in, which also sucks.
MozReview-Commit-ID: 246pokTMFl7
--HG--
extra : rebase_source : 8cb2750225d2e0331b1cfe25e02c766dd631e565
Now that we have a Docker image with newer library versions on it, we
can move our builds over. The new images differ from the old
CentOS-based images in two important ways, though:
1) The system compilers in the new image are new enough to be used as
host compilers; additionally, our CentOS-built GCC compilers will not
work. We need to change the Android mozconfigs to reflect that. We
also need to change the Android tasks to not depend on the GCC
toolchain builds.
2) In a similar fashion, we can use the system JDK; we no longer need to
use the JDK from the Android NDK, which we had packaged up via the
Android dependencies task.
Both of these changes come with caveats: our l10n repack jobs continue
to run on the CentOS-based images; l10n repacks have not been completely
converted to Taskcluster. So we need to:
1) Retain the use of our custom GCC toolchain for HOST_CC/HOST_CXX on
the CentOS-based images.
2) Retain the JDK packages in the tooltool manifests, and referencing
them when we build on the CentOS-based images.
Update the host jsshell, which is used for minifying Fennec JS code, to
the one from the 56 release, so minification works again.
MozReview-Commit-ID: K87XQrAbC9p
--HG--
extra : rebase_source : 9ae4aad02ca11bdde0d2da9f0bb98fb5e83769d1
I believe this doesn't affect this bug because I think the ViewHolders are
recreated on rotation but for any other type of change, only bind will be
called so for correctness, we should update the size in bind.
MozReview-Commit-ID: 3ojO4TF89i4
--HG--
extra : rebase_source : 6376aca2f6858261ca913fa0f613cbdb9be2b4bf
