The GMP manager uses a copy of the update service's url formatting code and has
since fallen out of sync. We'll also want to use the same formatting code for
the system add-on update checks so this just exposes it in a shared API.
I've moved the contents of UpdateChannel.jsm to UpdateUtils.jsm and exposed
formatUpdateURL there as well as a few properties that the update service still
needs access to.
UpdateUtils.UpdateChannel is intended to be a lazy getter but isn't for now
since tests expect to be able to change the update channel at runtime.
In a following patch, all DevTools moz.build files will use DevToolsModules to
install JS modules at a path that corresponds directly to their source tree
location. Here we rewrite all require and import calls to match the new
location that these files are installed to.
Currently we "quit" by closing the last window, but this bug makes us
not quit Gecko automatically when the last window closes. Therefore we
should force Gecko to quit. This patch also makes our quit code
consistent with the addon restart code at [1], i.e. using
nsIAppShell::Quit to quit and sending the "quit-application-requested"
notification. The previous notification,
"browser-lastwindow-close-requested", appears to only be used on
desktop.
[1] mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js?rev=f61c3cc0eb8b#6287
This ticket does the following things:
* register early. If the first page that Gecko loads is
about:accounts, the channel needs to be in place. If we delay this,
we can and do miss content server messages.
* listen to the following messages:
CAN_LINK_ACCOUNT: 'fxaccounts:can_link_account'
CHANGE_PASSWORD: 'fxaccounts:change_password'
DELETE_ACCOUNT: 'fxaccounts:delete_account'
LOADED: 'fxaccounts:loaded'
LOGIN: 'fxaccounts:login'
The list of messages is from
2a78a14daf/app/scripts/models/auth_brokers/fx-desktop-v2.js (L24)
via
2a78a14daf/app/scripts/models/auth_brokers/fx-fennec-v1.js
This patch implements only LOADED, LOGIN, and CHANGE_PASSWORD. The
messages have the following behaviour:
A LOADED message is ferried to the individual XUL <browser> element it
originated from. In general, WebChannel is a global listener: it does
not matter where a message originates. We want to have fine-grained
control over when an embedding <iframe> is displayed (as opposed to
loaded, in the Gecko sense of loaded). The fxa-content-server
participates in this exchange via the LOADED message; we complete the
loop by specially handling LOADED.
A LOGIN or CHANGE_PASSWORD message either creates a new Android
Account in the Engaged state, or moves an existing Android Account to
the Engaged state. An Android sync is not yet requested -- we'll
arrange that from the Java side.
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.*
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.
Currently, BrowserCLH opens a single new window on startup. Now that
GeckoView is able to open windows through GeckoView.Window, we should
make GeckoView open its own window, which we can do earlier in startup,
and will make it possible to support multiple GeckoView's down the road.
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.
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.
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.
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).
