dom_workers.xpt was originally added to Firefox's package-manifest.in
in Bug 757133 (https://hg.mozilla.org/mozilla-central/rev/d5fcb5f05f03).
Adding it to Fennec will allow us to list and debug workers on this platform.
MozReview-Commit-ID: 391mCv4dCid
--HG--
extra : rebase_source : 4598a849cbf84c56e6bdbe6c71cfa20f0467a395
This code was crashing in the framework; removing it should hopefully fix the
crash.
MozReview-Commit-ID: 2G3q4JrJ9tP
--HG--
extra : rebase_source : e9c1379b9dd3ebcb8ec2169165c629727344179d
Also migrates TouchUtils to videoControls in order to keep some interactions.
Removed the casting button from TouchUtils (to be add back to Utils in the next
commit; not removing the SVG images for hg annotation)
MozReview-Commit-ID: DzhmjykCLzu
--HG--
extra : rebase_source : d77dfe3e2d9de2087d21dc2fb9b1773e710177d7
This is a far cry from having good error reporting, but we at least need
to notify the app that the page is no longer loading.
MozReview-Commit-ID: Kbm5MpNbND6
--HG--
extra : rebase_source : 69928ace16dcb87b21b4911af6a86a7f5d8b61b3
This small change is actually very significant. Previously, |mach
package| for mobile/android had two jobs:
1) produce a final APK
2) rebuild parts of the APK that might have been silently modified by
l10n mechanisms, both from multi-locale builds and single-locale
repacks
This second part has never been sensible but has been difficult to
alter until recently, since the l10n mechanisms have been out of
mozilla-central and difficult to modify and test. That's less true
now.
This patch:
a) removes the rebuild parts (the step labeled 2) above (which I
generally refer to as the "nodeps mechanism")
b) uses the APKs produced by Gradle directly, without the copying
indirection from m/a/base/Makefile.in
c) does the rebuild for multi-locale builds as an explicit step in the
appropriate mozharness script
d) does the rebuild for each single-locale repack as another step in
the existing `installers-%` target in m/a/locales/Makefile.in (it's
not easy to remove this from the Makefile, since the repackage is
invoked immediately after (it's the `repackage-zip-$*` target))
The new m/a/gradle.py file will grow additional tasks in tickets to
follow, hence the lock file and pre-factored form.
MozReview-Commit-ID: IKflLdmHR3P
--HG--
extra : rebase_source : fdabe340b6f0896a0ebb9da2951f10753deb5ff5
This should have been a part of Bug 1408710, but alas, here we are.
Patch changes two things:
- serializes process failures in BatchingUploader if record-to-be-uploaded fails sanity checks and server requirements
-- this helps us short-circuit flow in RecordsChannel
- avoids performing any work in ServerSession's storeDone if flow has been aborted
MozReview-Commit-ID: 9qevdzRvHEx
--HG--
extra : rebase_source : 2e30aa7e222916acb791a9803bab0d4d95e5e491
No functional change; added tests to cover the decision tree a bit better, renamed stuff.
MozReview-Commit-ID: LwvyBaAg421
--HG--
extra : rebase_source : 4e46be5f67317f6bd5ea0c4701587908a3628634
On Android, GeckoEditableSupport has already dispatched eKeyDown event and
eKeyUp event even during composition. I.e., the pref which will be enabled
by bug 354358 has already been set to true only on Android.
On the other hand, GeckoEditableSupport does not dispatch them if content
listens to "input", "compositionstart", "compositionupdate" or
"compositionend". So, different from the other platforms, we need additional
pref to make the new behavior behind pref.
Therefore, this patch adds a new pref,
"intl.ime.hack.on_any_apps.fire_key_events_for_composition", to override
existing "intl.ime.hack.on_ime_unaware_apps.fire_key_events_for_composition"
pref. And sets mKeyCode and mKeyNameIndex of the dummy KeyboardEvents to
NS_VK_PROCESSKEY and KEY_NAME_INDEX_Process.
MozReview-Commit-ID: Fuy0Ir2xiO5
--HG--
extra : rebase_source : c76b613ea186458ebdf0d67f4bc984e8ac5f1041
