I tried to use the `?android:attr/...` method listed in the nearby comments but
kept receiving a "ResourceNotFound" exception. I wonder if this is related to
the way we inherit and then override the themes.
--HG--
extra : commitid : 6G6nTr4Sfrv
extra : rebase_source : 1ba4aab60e3a9cf3423b0297bd643055f9f1b28d
This patch reintroduced changes behind a nightly flag removed by:
1161638: Remove the chrome at the bottom of the screen in the Tabs Tray
1164723: Inherit from Tablet UI on Mobile UI (aka compact tabs)
1193745: Implement the tablet tabs tray grid view on mobile
I've also done a bit of work to allow the chrome to sit at the correct Y location in landscape on mobile devices when the tabs panel is shown to account for bug 1193374 which adjusts the aspect ratio of the tabs panel thumnbnails and didn't need to be hidden behind a nightly flag. Tablets remain unaffected by this change.
--HG--
extra : commitid : F4ZrEWNLzUw
extra : rebase_source : ec45dc9d919ac84a29487116582f35669fdf99af
extra : amend_source : 4afe062c66d7e9ca55419d328532060e9cb04184
This commit does a few things. First, it fixes a typo
(s/ForResponse/ForResult/). It's not clear how this /ever/ worked,
but it did.
Second, it adds an UpdateAccountFromJSON sibling to
CreateAccountFromJSON. It would have been reasonable to have the
create message do double-duty and update an existing account (we have
the latitude to change the meaning since this API is not yet public)
but I generally prefer each consumer to perform the conditional state
check and to act appropriately.
Third, it generalizes the existing Accounts:Exist message to provide
some details (including email and UID) of any existing Firefox
Account. The Accounts.exist() API /is/ public, so I introduce a new
(not yet public) API for this richer information.
--HG--
extra : commitid : 5OcLn2ejQzZ
extra : rebase_source : dca7f1ab0cb101948e9d67db4595b91127f0bfd6
There are enough Accounts: messages to separate them from BrowserApp,
and the list is only growing.
This has also the small advantage of removing some non-native event
listeners.
--HG--
extra : commitid : EdVdLpnxju7
extra : rebase_source : 574212eb4b74336ef3322297ed71eeb401b03f84
This patch stops referring to package/class objects to identify
Android components directly and instead launches through action intent
filters. The intent filters are scoped to the package, but not marked
as private or as requiring a permission. A malicious package could
inject itself into an account flow, but I don't think there's much
advantage: the only time a secret is passed between activities is when
the native sign up (CreateAccount) and sign in (SignIn) activities
link between themselves, and in this instance I didn't route through
the action intent filters. (This is entirely native -- there's no web
analog -- so I didn't use the indirection.)
--HG--
extra : commitid : 5kItROluc9m
extra : rebase_source : e02f324ab9a5cc4d807d37fa575e649631dee5d6
When used to do our own animation when opening the browser from the
share overlay. That caused this bug: we didn't call `finish` until
`onAnimationEnd` but since `startActivity` was called, the application
was switched before `onAnimationEnd`, and thus `finish`, could be
called. When we returned to the share overlay, it was in an unexpected
state (`isAnimating` was true) and the user could no longer interact
with it, blocking access to the app the ShareOverlay was opened from.
We fix this by not doing our custom animations and just calling `finish`.
Note: in any case, overriding the animation when opening the browser
could be unintuitive to users because they might expect a consistent
app-switch animation throughout the system.
--HG--
extra : commitid : LAPOPiQePMN
extra : rebase_source : 79a7dd1c9acd2dc04d68f5ce890e4ea94cee348d
The call to setResolution has (I believe) not been needed since bug 732971. Prior
to that resolutions used to be applied on the root document in Fennec, and so
browser.js would have to reapply the desired resolution on every tabswitch.
After that bug, the resolution was saved on the content documents for each tab
and so browser.js no longer needed to reapply the resolution. Until recently
doing this was redundant but harmless.
With bug 1180267 though the browser.js code that tracks the resolution may have
the wrong resolution initially, because that is determined in C++ code. Only
after the Java-side code process the setFirstPaintViewport message and sends
that information to browser.js does everything have the correct resolution. In
the case where a tab loaded in the background is brought into the foreground, the
tab-selected code runs before the setFirstPaintViewport code, and therefore uses
an incorrect resolution. This then screws up the viewport clamping code and causes
the page to get scrolled.
--HG--
extra : commitid : 3Ic2BinhkXO
The intent of this check is to avoid setting the same margins more than once.
However this is redundant because the code in nsLayoutUtils::SetDisplayPortMargins
already has an equivalent check. Further, this code is wrong because it stores
the old margins per-tab, and so once a new document is loaded the margins may be
the same as "before" but they apply to a different element. In order to be correct
the check would have to track the target element as well as the margin values,
but it's easier to just get rid of this and let nsLayoutUtils handle it.
--HG--
extra : commitid : 3OpAxOyiOkS
1) Added some comments to firefox.js to explain the relationship between
extensions.blocklist.interval and security.onecrl.maximum_staleness_in_seconds
2) Modified default values in firefox.js and mobile.js to set maximum staleness
to 1.25x blocklist interval
3) modified the tests_ev_certs.js xpcshell test to cope with larger maximum
staleness values to address test failures
This is a Fennec version of about:accounts, cribbed largely from
Desktop's implementation. This implementation serves two purposes:
One, it allows all fxa-content-server pref handling to remain in
Gecko. Java-side consumers redirect to about:accounts?action=... and
have pref munging and parameter addition (like context=fx_fennec_v1,
etc) handled by about:accounts itself.
Two, it handles network connectivity display and error handling. When
a request is started, we display an animated spinner. We transition
smoothly from the spinner to the iframe display if we can, and if not
we hide any network error and offer to retry. This is more important
in Fennec than it is on Desktop. This approach agrees with Firefox
for iOS.
Some additional notes:
The spinner to iframe transition uses the WebChannel listener to send
LOADED messages to the appropriate XUL <browser> element. It's worth
remembering that Fennec's Gecko is single process, so the <browser> in
question is in the same process. None-the-less, we are close to e10s
safe.
There are four actions: signup/signin/force_reauth, and manage. The
first three try to produce a LOGIN message. The last uses the
fxa-content-server to manage the Account settings. *This is not how
this is arranged on Desktop: Desktop redirects to a new tab, not
wrapped in about:accounts.*
--HG--
extra : commitid : F2waTwe355B
extra : rebase_source : f63c96f676d1300c774d091968ec8d88bb7a86dc
This list is not meant to be exhaustive. There are many ways to get
to the Get Started activity; not all of them are interesting. We're
just trying to capture the significant entrypoints, like firstrun and
preferences.
--HG--
extra : commitid : 6NI5PTknABt
extra : rebase_source : bb376e316cf3c68388506e1805ce33b749db324f
Pretty straight-forward. It's possible that getStringExtra is not
safe in the face of malicious data; the worst we might expect is a
crash on the Java side; a large memory allocation on the JS side; or
significant URL data transfer. The first is valuable because we'd see
abusers in crash-stats; and the second two are already possible when
opening any URL.
--HG--
extra : commitid : GZNHCgMWFt5
extra : rebase_source : dfb88da52ef0449246ba54d460a4653170542b69
This also skips the tab queue when opening other links internally,
like the FxA Terms of Service and Privacy Policy.
--HG--
extra : commitid : H9f8Gur7qMg
extra : rebase_source : 21cda6d413871e20b22eca4dd4bc95127250bec6
The spinner itself is 60px square, colored like fennec_ui_orange.
The HTML and CSS was hacked out of
https://github.com/lightningtgc/material-refresh, tree
6b1be0046d.
The original code is licensed MIT. I pruned things we don't use,
adjusted the box model for our use, changed the spinner color, and
simplified the CSS.
--HG--
extra : commitid : yncLSrgF9z
extra : rebase_source : 02dc83cbb189fb8fa7ff5b1f75d6407a4601d1d5
Now Fennec can use the message from Gecko with the zoom constraints and we can
delete a bunch of code that did the equivalent job in browser.js
--HG--
extra : commitid : 20xL8HASMlt
The default zoom value is only used on the Java side to clamp the min/max zoom
values in the case where zooming is disabled. We can do this much earlier in
the flow, when we are computing the metadata, and reduce the amount of
redundant information being passed around.
--HG--
extra : commitid : AdyBXqXiIaW
From browser.js's point of view there's no difference between restricted and guest profiles. Both use the
parental controls API. So there are only two "simple" solutions here:
* 1) Add a method to nsIParentalControlsService to determine whether the current profiles is a restricted or
a guest profile (Something like isGuest()). But then every platform using this interface would require
to at least implement a stub for this method.
* 2) Add a new restriction that controls installing the theme.
This patch implements option 2. While this restriction is not of much use besides deciding whether we need
to install a specialized theme (DISALLOW_DEFAULT_THEME), it still offers the most flexibility. In a
follow-up bug we could decide to make the restriction configurable by the device admin (requires localized
strings).
--HG--
extra : commitid : 1HcJmNLuz7b
extra : rebase_source : d43407713b7d41a546213e75b7d5e4f03a8b3d78
This patch creates a copy of the GeckoAppBase style in v21/themes.xml and removes
the custom icons for copy, cut and paste we use on v11+. Instead the system icons,
that match the look&feel of the ActionBar, will be used.
--HG--
extra : commitid : bb07iANzjF
extra : rebase_source : 3b057830c78f5cac1361474d3c60eeaf86eda1d6
extra : amend_source : 86e0168b47967e3e66cd36b151b33ccefd2e2af7
To do this, I ran:
convert <image> -alpha extract -alpha on <image>
The resultant images were slightly larger than their previous
counterparts so I then compressed them with ImageOptim.
--HG--
extra : commitid : KJ2wVCoGpWp
extra : rebase_source : c53cf14e32c8904e2ed2403f32bc8cb87245c465
DONTBUILD NPOTB
This adds a pass-thru |mach android| command. It's just here to make
it easier to add and remove Android SDK packages: since most folks
don't have the Android tools on their PATH, this saves them having to
root through the object directory to find the path to the tool.
--HG--
extra : commitid : HgCtltLK3V4
extra : rebase_source : 6c7db25c10b643c8fe655976e613c29db7cd0bc4
extra : histedit_source : fd95eb809a901fd3873968117c60966f3f82790c
DONTBUILD NPOTB
Straight from http://stackoverflow.com/a/24751182 and the linked
IntelliJ tickets.
--HG--
extra : commitid : AcbSF0042KW
extra : rebase_source : f67e9eecfdf3f452e4fd55901f8eb42b0f3ed22c
Other 3-dot menu button locations to follow.
I tested that the colors are correct in the various states (e.g. private
browsing).
This patch additionally:
* Restructured the menu button (which allowed the removal of a setVisibility
call
* Removed the now unused tablet assets.
--HG--
extra : commitid : 5AzCA3B3KHo
extra : rebase_source : b2ba9b4052cf94f8af4c4cb39b3f5f1f250d3b17
And replace the older assets.
These are the 36dp icons from Google's material design page:
https://www.google.com/design/icons/#ic_more_vert
Then we trim off the whitespace with image magick:
convert icon.png -trim out.png
And compress with ImageOptim.
--HG--
extra : commitid : 2KxoyvO50be
extra : rebase_source : 23535bb72fa7cc99f9e6a9b1efbf9e4c3f3a84f0
This also involved moving a redundant background declaration to only the
containing style.
--HG--
rename : mobile/android/base/resources/drawable/action_bar_button.xml => mobile/android/base/resources/drawable/menu_item_action_bar_bg.xml
extra : commitid : GFUgNsiZgGb
extra : rebase_source : 4a3c03b50f923e50bf99effea9b9d34813adb40b
These appear to have been added in the initial implementation of this feature.
--HG--
extra : commitid : KIlolzsFEyi
extra : rebase_source : 0351ba974ed6624c6f767146a39443f5704a57ab
On Gingerbread devices (Android API 9 or 10) the ViewHelper.setTranslationY code
doesn't work to move the SurfaceView. In order to acheive that effect I turned
LayerView into a ScrollView with a dummy element at the top, and allow it to
scroll. This allows the SurfaceView to move as desired. A few places in the code
were assuming that the LayerView and SurfaceView were always at the same screen
location (which was true before but not any more) and so those sites needed
some updating as well.
--HG--
extra : commitid : Jpr1k74MOAD
vivek
Martyn Haigh
Justin Dolske
Allison Naaktgeboren
Phil Ringnalda
Mark Finkle
Richard Barnes
Kartikaya Gupta
Wes Kocher
Carsten "Tomcat" Book
Liang-Heng Chen
Daniel Stenberg
Justin Inouye
Sebastian Kaspari
Robert O'Callahan
Kan-Ru Chen
Dylan Roeh
Michael Comella
Christoph Kerschbaumer
Nick Alexander
Eitan Isaacson
Bob Clary
Christian Schmitz
Prateek Arora
Gian-Carlo Pascutto
Mark Goodwin
Ms2ger
Ehsan Akhgari
Shu-yu Guo
Chenxia Liu
Fabrice Desré
James Willcox
Florian Quèze
dominique vincent
Margaret Leibovic
Ryan VanderMeulen
Garvan Keeley
Mantaroh Yoshinaga