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
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
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
Kartikaya Gupta
Wes Kocher
James Willcox
Daniel Stenberg
Phil Ringnalda
Michael Comella
Martyn Haigh
Carsten "Tomcat" Book
Bob Clary
Mark Finkle
Christian Schmitz
Prateek Arora
Allison Naaktgeboren
Gian-Carlo Pascutto
Mark Goodwin
Ms2ger
Ehsan Akhgari
Fabrice Desré
Florian Quèze
dominique vincent
Sebastian Kaspari