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
