Modifying the manual font size settings while the GeckoFontScaleListener is
active is theoretically possible, but probably not the most sensible way of
using that API. Therefore, we prohibit it and throw an exception in that case.
There is one complication, though: The very same API is used by the font scale
listener itself in order to modify the font size settings according to the
system font scale. Therefore, we have to move the GeckoFontScaleListener into
the GeckoView package itself, so that we can provide a package-private internal
API that bypasses the above usage checks.
This means that going forward, Fennec needs to use the official GeckoView API
to communicate with the font scale listener, too. As we've moved out the Shared-
Preferences watching in part 5, this doesn't pose any insurmountable
difficulties.
Because for a short while I encountered some strange crashes where getRuntime()
in GeckoApplication apparently returned null while trying to initialise the
listener, I'm tying its initialisation to creation of the runtime, just to be on
the safe side.
Differential Revision: https://phabricator.services.mozilla.com/D18507
--HG--
rename : mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoFontScaleListener.java => mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoFontScaleListener.java
extra : moz-landing-system : lando
Some callers might prefer to manually set the font size in analogy to WebView's
WebSettings.setTextZoom(), respectively allow their users to do so.
Subsequently, we're also going to switch the GeckoFontScaleListener to operate
on those settings.
Because the effects of font inflation are more difficult to quantify than a
plain text zoom, we just check that operating the runtime setting sets the
corresponding Gecko pref. Besides, there already are further platform (ref)tests
checking the actual operation of font inflation itself.
Differential Revision: https://phabricator.services.mozilla.com/D17749
--HG--
extra : moz-landing-system : lando
With the dependencies on Fennec's GeckoPreferences and GeckoSharedPrefs gone, we
can now move the class into GeckoView in preparation for hooking it up to the
GeckoViewRuntimeSettings.
Differential Revision: https://phabricator.services.mozilla.com/D18506
--HG--
rename : mobile/android/base/java/org/mozilla/gecko/GeckoFontScaleListener.java => mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoFontScaleListener.java
extra : moz-landing-system : lando
For easier testing in Fennec, we want to continue watching the respective
SharedPreferences key and toggle the listener in response to *that* instead of
directly wiring it into our Settings menu (GeckoPreferences), however because
that functionality is Fennec-specific, we move that logic out of the font scale
listener itself.
In conjunction with this, we also decouple the enabled state of the listener
from its attached state.
The enabled state can now be toggled at all times, but unless the listener is
also attached to a context, it simply won't have any practical effect.
Differential Revision: https://phabricator.services.mozilla.com/D17746
--HG--
extra : moz-landing-system : lando
In practice, everything in the GeckoFontScaleListener will run on the UI thread,
so get rid of the `synchronized` methods and just enforce the threading
assumptions in the public API.
Differential Revision: https://phabricator.services.mozilla.com/D18505
--HG--
extra : moz-landing-system : lando
Going forward, we want to be able to toggle the enabled state at all times, and
being able to do this before calling initialize() seems a bit inconsistent.
Hence, we rename it to the more neutral-sounding attachToContext().
Differential Revision: https://phabricator.services.mozilla.com/D17745
--HG--
extra : moz-landing-system : lando
The GeckoFontScaleListener is intended to live as long as the app (and there-
fore Gecko) remains alive and consequently keeps a reference to the
*application* context, so the linter warning can be safely suppressed.
Also reorder imports to match coding style.
Differential Revision: https://phabricator.services.mozilla.com/D17743
--HG--
extra : moz-landing-system : lando
The scrollTo() and scrollBy() functions in the PanZoomController may be
used to scroll the root document in GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D18898
--HG--
extra : moz-landing-system : lando
Modifying the manual font size settings while the GeckoFontScaleListener is
active is theoretically possible, but probably not the most sensible way of
using that API. Therefore, we prohibit it and throw an exception in that case.
There is one complication, though: The very same API is used by the font scale
listener itself in order to modify the font size settings according to the
system font scale. Therefore, we have to move the GeckoFontScaleListener into
the GeckoView package itself, so that we can provide a package-private internal
API that bypasses the above usage checks.
This means that going forward, Fennec needs to use the official GeckoView API
to communicate with the font scale listener, too. As we've moved out the Shared-
Preferences watching in part 5, this doesn't pose any insurmountable
difficulties.
Because for a short while I encountered some strange crashes where getRuntime()
in GeckoApplication apparently returned null while trying to initialise the
listener, I'm tying its initialisation to creation of the runtime, just to be on
the safe side.
Differential Revision: https://phabricator.services.mozilla.com/D18507
--HG--
rename : mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoFontScaleListener.java => mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoFontScaleListener.java
extra : moz-landing-system : lando
Some callers might prefer to manually set the font size in analogy to WebView's
WebSettings.setTextZoom(), respectively allow their users to do so.
Subsequently, we're also going to switch the GeckoFontScaleListener to operate
on those settings.
Because the effects of font inflation are more difficult to quantify than a
plain text zoom, we just check that operating the runtime setting sets the
corresponding Gecko pref. Besides, there already are further platform (ref)tests
checking the actual operation of font inflation itself.
Differential Revision: https://phabricator.services.mozilla.com/D17749
--HG--
extra : moz-landing-system : lando
With the dependencies on Fennec's GeckoPreferences and GeckoSharedPrefs gone, we
can now move the class into GeckoView in preparation for hooking it up to the
GeckoViewRuntimeSettings.
Differential Revision: https://phabricator.services.mozilla.com/D18506
--HG--
rename : mobile/android/base/java/org/mozilla/gecko/GeckoFontScaleListener.java => mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoFontScaleListener.java
extra : moz-landing-system : lando
For easier testing in Fennec, we want to continue watching the respective
SharedPreferences key and toggle the listener in response to *that* instead of
directly wiring it into our Settings menu (GeckoPreferences), however because
that functionality is Fennec-specific, we move that logic out of the font scale
listener itself.
In conjunction with this, we also decouple the enabled state of the listener
from its attached state.
The enabled state can now be toggled at all times, but unless the listener is
also attached to a context, it simply won't have any practical effect.
Differential Revision: https://phabricator.services.mozilla.com/D17746
--HG--
extra : moz-landing-system : lando
In practice, everything in the GeckoFontScaleListener will run on the UI thread,
so get rid of the `synchronized` methods and just enforce the threading
assumptions in the public API.
Differential Revision: https://phabricator.services.mozilla.com/D18505
--HG--
extra : moz-landing-system : lando
Going forward, we want to be able to toggle the enabled state at all times, and
being able to do this before calling initialize() seems a bit inconsistent.
Hence, we rename it to the more neutral-sounding attachToContext().
Differential Revision: https://phabricator.services.mozilla.com/D17745
--HG--
extra : moz-landing-system : lando
The GeckoFontScaleListener is intended to live as long as the app (and there-
fore Gecko) remains alive and consequently keeps a reference to the
*application* context, so the linter warning can be safely suppressed.
Also reorder imports to match coding style.
Differential Revision: https://phabricator.services.mozilla.com/D17743
--HG--
extra : moz-landing-system : lando
It's only being referenced in these two lines in mobile.js, but nowhere else
anymore.
Differential Revision: https://phabricator.services.mozilla.com/D19309
--HG--
extra : moz-landing-system : lando
Replacing js and text occurences of asyncOpen2
Replacing open2 with open
Differential Revision: https://phabricator.services.mozilla.com/D16885
--HG--
rename : layout/style/test/test_asyncopen2.html => layout/style/test/test_asyncopen.html
extra : moz-landing-system : lando
This manifests as silent child process crashes; let's try to avoid
that when we can.
Differential Revision: https://phabricator.services.mozilla.com/D19089
--HG--
extra : moz-landing-system : lando
Functionally, we want Marionette to be enabled whenever remote
debugging enabled and disabled whenever remote debugging is enabled.
That's not particularly well supported by Gecko prefs, so we don't try
to handle all situations. We force the Marionette pref whenever the
remote debugging pref changes; if consumers get themselves into a bad
state by fiddling the Marionette pref independently, that's fine:
GeckoView will take back control eventually.
There are a couple of wrinkles here. The first is that GeckoView and
Marionette race to set themselves up in "profile-after-change". We
ensure that both are configured before GeckoView notifies
"marionette-startup-requested". The second is that the initial value
of the Marionette pref is taken from the environment variable
MOZ_MARIONETTE; therefore, we set that variable when starting the
Gecko thread.
Differential Revision: https://phabricator.services.mozilla.com/D17580
--HG--
extra : moz-landing-system : lando
This is just a testing convenience. Remote debugging is engine-wide,
not session-wide, so it doesn't fit the other actions _exactly_; but
the "multiprocess" option is also somewhat engine-wide, so it doesn't
seem wildly out of place.
Differential Revision: https://phabricator.services.mozilla.com/D18616
--HG--
extra : moz-landing-system : lando
Once a webextension using a blocking WebRequest listener has started loading,
all network connections covered by the extension's manifest are held until the
extension is ready the process them.
One condition for the extension being ready apparently includes browser startup
having progressed far enough, as signified by "browser-delayed-startup-finished"
having been dispatched.
Therefore, we have to start sending that notification when opening a new Gecko-
View window, too, and copy Fennec's InitLater() system for that.
Unlike Fennec, we cannot tie registration of those InitLater() runnables to the
initial content load having progressed far enough because of
a) e10s, which makes that approach neither easily possible nor really sensible,
as content will load in a different process in that case, and
b) because we're racing with extension startup here - if extensions are loaded
quick enough to block even the initial page load, we'd be deadlocked: We
cannot send the notification until the page finishes loading, but the page
cannot load until we send the notification. Fennec isn't affected by the
latter problem because "sessionstore-windows-restored", which Fennec will
send in any case, serves as an alternative pathway for completing extension
startup.
And unlike Desktop, we don't really have any chrome content to paint, so we
cannot tie delayed initialisation to a paint listener for that, either.
Therefore, we simply fire off a runnable at the *end* of geckoview.js's
startup() method, which should give more pressing initialisation tasks enough of
a headstart.
For completeness, we're also adding the "browser-idle-startup-tasks-finished"
notification and thereby solve bug 1465832 as well, allowing the ScriptPreloader
to detect which scripts are commonly loaded during GeckoView startup and to
start caching and pre-parsing them.
Differential Revision: https://phabricator.services.mozilla.com/D18865
--HG--
rename : mobile/android/modules/DelayedInit.jsm => mobile/android/modules/geckoview/DelayedInit.jsm
extra : moz-landing-system : lando
That way, domain highlighting (and therefore the URL justification code that
right-justifies the TLD within the URL bar) can run even on error pages.
This also means that the workaround from bug 1479311 for blocking javascript:
URIs from being highlighted in ToolbarDisplayLayout is no longer required -
the base domain for domain highlighting is now being generated from the same
URI that actually ends up being displayed in the URL bar, and as such the
existing checks in browser.js for only generating a base domain for HTTP(S)/
FTP-URIs, but not any other schemes, finally work the way they are intended.
Differential Revision: https://phabricator.services.mozilla.com/D18587
--HG--
extra : moz-landing-system : lando
Currently, the Android front-end uses a tab's base domain both for permission
prompt doorhangers, as well as for doing domain highlighting in the URL bar. The
base domain in turn is based on the document's nodePrincipal's URI.
As per bug 1325955, the nodePrincipal is the right choice for permission
prompts, but it causes some problems for domain highlighting instead: For error
pages for example, the nodePrincipal's URI will be some variety of
about:neterror, which means that the front-end won't be able to do any domain
highlighting based on that, since
a) we don't generate any baseDomain anyway because the URI's scheme isn't
HTTP(S)/FTP, and
b) even if we did, the nodePrincipal's baseDomain won't match the contents of
the URI displayed in the URL bar.
Therefore, we want to separate these two concerns, and generate two baseDomains:
One based on the nodePrincipal for use in permission prompts, and one based on
the display URI, which going forward will power our domain highlighting.
Differential Revision: https://phabricator.services.mozilla.com/D18586
--HG--
extra : moz-landing-system : lando
Jan Henning
Randall Barker
James Willcox
Brindusan Cristian
Andreea Pavel
Eitan Isaacson
Jonathan Kingston
Nick Alexander
Andrew Erickson
Gijs Kruitbosch
shindli
Yuan Cheng
Oana Pop Rus
Delphine Lebédel
Zibi Braniecki