The code in WebappsUpdateTimer.js tried to detect a webapp process by
using the context class name, which is extremely fragile. This patch
makes it detect the current Gecko profile instead.
This patch makes code use the application context from GeckoAppShell
instead of the activity context. Enough changes are made to let headless
mode work.
This patch adds separate setter and getter for the application context
in GeckoAppShell. The existing getContext method is misused for both
application and activity context, so new methods are added to improve
consistency.
Right now we use the GeckoThread state to detect whether GeckoApp is
first launching or is being restored after being destroyed. However,
because of headless mode, GeckoThread could already be running on
GeckoApp's first launch, so we need a separate way to detect
relaunching.
Due to the import, LayoutParams was RelativeLayout.LayoutParams and
it was referring to the parent container, which is now a FrameLayout.
--HG--
extra : commitid : IUQUTpBRAbe
extra : rebase_source : 8af3206963bb88bb488187a84db4ef06ef68bc6a
It shares an implementation with GeckoApp so it needs to match.
--HG--
extra : commitid : DaYns85thja
extra : rebase_source : 65706273a312a2b4b217f466a81fe7d8e251cce4
MarginLayoutParams is less specific than RelativeLayout.LayoutParams
and is easier to make changes with.
--HG--
extra : commitid : FeMtZlTCy1m
extra : rebase_source : d25f9513ef2f10a001513499c7a5ec052397eaf2
Using systrace, I took 2 traces before and after. Using the slowest
of both traces, the first three measure passes had the following
improvements in CPU time:
1) 20.583ms -> 13.149ms
2) 1.695ms -> 0.827ms (1/2)
3) 22.146ms -> 11.602ms (1/2)
This is to be expected – RelativeLayout requires two measure passes
so it makes sense to approximately half the measure times.
--HG--
extra : commitid : IDQckTgGsge
extra : rebase_source : df061c7645aa6b3a880278f75d3fa637e3160f9c
This code seems to have handled scroll events that started on the toolbar in the past.
But this does not work anymore (for quite some time) and in fact breaks touch event
handling (See bug 1046591 for a side-effect of only partially consuming events here).
--HG--
extra : commitid : 3Lc1nqepusP
extra : rebase_source : 261f59ff61e1246d3d10113041186cedadf4cad2
This is more or less reverting the changes introduced in bug 1216114.
--HG--
extra : commitid : H1PdYtOIFtp
extra : rebase_source : b4b971b02623dfbd53fe9bf75a6cc75903a1ad28
I moved the JAR out of the root directory because I didn't want
multiple copies of things in robocop/ appearing in IntelliJ, although
this turns out to not be strictly necessary. Keeping it as part of a
general push to move things out of the root dumping ground.
--HG--
rename : mobile/android/tests/browser/robocop/robotium-solo-4.3.1.jar => mobile/android/tests/browser/robocop/libs/robotium-solo-4.3.1.jar
extra : commitid : 6NYW1zNU7k8
extra : rebase_source : e152435da39612fdb69749936c713313f2a5b006
extra : histedit_source : aca11a9101156670d49fe89a9237031e4089f2b8
This builds the Robocop tests with |mach build mobile/android|, making
it easier for developers to build Fennec and the tests at the same
time.
--HG--
rename : build/mobile/robocop/AndroidManifest.xml.in => mobile/android/tests/browser/robocop/AndroidManifest.xml.in
rename : build/mobile/robocop/Makefile.in => mobile/android/tests/browser/robocop/Makefile.in
rename : build/mobile/robocop/README => mobile/android/tests/browser/robocop/README
rename : build/mobile/robocop/moz.build => mobile/android/tests/browser/robocop/moz.build
rename : build/mobile/robocop/res/values/strings.xml => mobile/android/tests/browser/robocop/res/values/strings.xml
rename : build/mobile/robocop/robotium-solo-4.3.1.jar => mobile/android/tests/browser/robocop/robotium-solo-4.3.1.jar
extra : commitid : BuNBjgXdm1d
extra : rebase_source : c36b8bf0183d8f5821b7f7839668ca963065d894
extra : histedit_source : a86fef3b834420ea496a9c2644ca72786a2d7da9
- A telemetry probe for when a user clicks to unblock an image.
- A second probe for sending the size of the image being unblocked.
Since we don't have information on the image size the best option
was to make make an XHR HEAD request. We make an approximation
of the image size from the content length which we send in kB.
--HG--
extra : commitid : G0ixOr8xmju
extra : rebase_source : cfb7d0d5777f6d0c657f6aafa18c58ec2b882789
- Replaced bool pref for int list option: Never, Always, or Only over Wi-Fi
- Pref browser.image_blocking.enabled -> browser.image_blocking
- Converted the early return to check for cellular as well.
- Note that in the cellular check, I do not consider LINK_TYPE_USB as "cellular".
- Tested this on a physical device with all combinations
of WiFi ON/OFF (falling back to cellular and each menu state.
- Tested if menu options work as well for each state mentioned above.
--HG--
extra : commitid : 3xKvKEgZv9A
extra : rebase_source : 888cfa9843ca515bef4a3596f6b01bf562065125
It is possible for the display name to contain Unicode characters,
which not all Mozilla service endpoints handle gracefully. This
avoids that issue.
--HG--
extra : commitid : JhI3YFLj4Ho
extra : rebase_source : 7f60fb1dfdb70b3e25aa5220f61d553895294c8c
MarginLayoutParams is less specific than RelativeLayout.LayoutParams
and is easier to make changes with.
--HG--
extra : commitid : GY5tk9gY1Ji
extra : rebase_source : 1cf8940e8d570339fd72f4835033113c48be04d2
Using systrace, I took 2 traces before and after. Using the slowest
of both traces, the first three measure passes had the following
improvements in CPU time:
1) 20.583ms -> 13.149ms
2) 1.695ms -> 0.827ms (1/2)
3) 22.146ms -> 11.602ms (1/2)
This is to be expected – RelativeLayout requires two measure passes
so it makes sense to approximately half the measure times.
--HG--
extra : commitid : BExWbCFEcD3
extra : rebase_source : 64e836f410a53cac7a3c7b245613bd4070fdfda7