Now that GeckoScreenOrientation generally offers notifications of screen
orientation changes, the PromptService no longer needs to do its own orientation
tracking and require to be fed orientation changes from each activity using it.
MozReview-Commit-ID: K7KbDsQip7b
--HG--
extra : rebase_source : 8b447d9db079794c9ad231a31a52f2787ab742ce
As of bug 1475875, cached screen data is now held by Gecko, so
- we no longer need to cache the screen size (retrieval of which can be
expensive when called en masse, as required e.g. by font inflation) within
GeckoAppShell, and
- we need to trigger a refresh of that data instead when the activity
orientation changes.
MozReview-Commit-ID: JsY6sBCcOih
--HG--
extra : rebase_source : f286f3b01732bd724da3988c4713adb7329a5fae
By moving the calls to GeckoScreenOrientation.update() into GeckoView, any app
using a GeckoView will automatically update the screen orientation in Gecko,
too, without any further action being required by the embedding app.
The synchronisation around GeckoScreenOrientation.update()/(un)lock() is
required for the following scenario:
If (un)locking of the screen orientation as requested by Gecko caused the
actual screen orientation of the app to change, there are two ways in which this
will cause our internal screen orientation to be updated:
1. Either the call to delegate.setRequestedOrientationForCurrentActivity
(happening on the Gecko thread if the original request to (un)lock came from
Gecko) returns first and update() is subsequently first called from the Gecko
thread, too, meaning the onOrientationChange notification to Gecko can occur
synchronously as well. In that case, as soon as (un)lock returns to Gecko,
querying our internal screen orientation will return the correct value.
2. Or else the GeckoView.onConfigurationChanged() call resulting from the screen
rotation manages to call GeckoScreenOrientation.update() first and does so
from the Android UI thread. This means that the onOrientationChange
notification will be redispatched asynchronously to the Gecko thread, while
the Gecko thread's call to GeckoScreenOrientation.update() will return early
without doing any work, as the screen orientation had already been previously
updated by the UI thread.
As a result,there will be a period of time between the Gecko thread returning
from GeckoScreenOrientation.(un)lock() and the onOrientationChange
notification finally executing where querying the internal screen
orientation will not yet return the new orientation. This can cause problems
for Gecko (test) code that expects to (un)lock the orientation and then be
able to immediately query the new, changed orientation after the call to
(un)lock returns.
Without additional measures in place, there are no guarantees at what point
the GeckoView will receive the onConfigurationChanged() call in relation to the
request to change the activity's orientation making its way back to (un)lock().
Therefore, we add synchronisation such that no other thread will be able to up-
date the screen orientation in GeckoScreenOrientation while another thread is
still busy (un)locking the screen orientation.
MozReview-Commit-ID: 5s5NEJcuS0p
--HG--
extra : rebase_source : cbfbc6da99aa23af4eee8c4bf6018359f9e71304
The call to mSession.transferFrom(ss.session) in the line above also transfers
the window from ss.session into mSession, which means we subsequently won't be
able to retrieve a runtime from ss.session any more, thereby defeating the goal
of calling mRuntime = ss.session.getRuntime().
This case is encountered e.g. when the containing activity is destroyed and sub-
sequently recreated after a configuration change that isn't handled by the app,
e.g. screen rotation in the GeckoView example app.
MozReview-Commit-ID: 5YGskdLZWqw
--HG--
extra : rebase_source : 3293fcaaf645706133531cb0180b6514a289b612
Once responsibility for notifying GeckoScreenOrientation of potentially changed
screen orientations moves from GeckoApp into GeckoView, the former will no
longer be able to benefit from the return value of calling GeckoScreen-
Orientation.update(), indicating whether the orientation actually changed or in
fact remained the same.
GeckoApp however requires that information in order to reset/refresh parts of
the UI when the orientation changes, and since GeckoScreenOrientation is already
doing all the work of tracking screen orientation changes, we don't want to have
to partially duplicate those efforts again in GeckoApp.
Instead, we introduce a mechanism for GeckoScreenOrientation to notify
interested parties on the Android app side as well.
The GeckoScreenOrientation.update() call in GeckoApp.onResume() is removed
completely (as opposed to merely removing the refreshChrome() bit) at this stage
already because it is unnecessary. If any screen rotation happened while the
activity was in background, it will receive an onConfigurationChanged() call
anyway before being resumed again.
MozReview-Commit-ID: Ila1evcj8Ud
--HG--
extra : rebase_source : f342800628f930d717fe346779894793a1bac0e9
The enable/disable logic of the list manager was wrong. If multiple features
shared a given table (e.g. tracking protection and tracking annotations)
and only one of them was enabled, then updates could either be disabled
or enabled depending on which feature was checked first.
By disabling everything at the beginning and selectively re-enabling tables,
we can ensure that no table gets both enabled and disabled by different
feature toggles.
Differential Revision: https://phabricator.services.mozilla.com/D3259
--HG--
extra : moz-landing-system : lando
For each file touched in this patch, the file had an #include for nsContentUtils.h, but no other mentions of the string "nsContentUtils", nor any mention of its "ScriptBlocker"-related types. So these files likely don't need their nsContentUtils.h include anymore, and we can remove it to get a marginal win on build time/complexity.
Differential Revision: https://phabricator.services.mozilla.com/D3370
--HG--
extra : moz-landing-system : lando
Tests for this are in the next commit (e.g. test_address_form.html) because this can't be tested properly due to existing tests not filling fields in ways that fire input/change events.
MozReview-Commit-ID: 62CckFP6Ou3
--HG--
extra : rebase_source : 02a73ae78f6102e139cdca31e64d6248dc8d5281
Sometimes .errorMessage exists without .message
MozReview-Commit-ID: D4zBJKxfJba
--HG--
extra : rebase_source : b665ab4c79a894462064662bbf8bcc49e320d7ce
These testcases now have virtually-identical copies called...
flexbox-justify-content-horiz-006.xhtml
flexbox-justify-content-vert-006.xhtml
...in our w3c-css/submitted/flexbox reftest directory. So these ones don't need
to exist anymore.
--HG--
extra : rebase_source : 4cc4601987d6678efd87966f94322446c7d00e98
extra : amend_source : 55186587084d49fdf786cd47bb01e2ff4ec0fb6f
External systems such as the generic ingestion service will want to work with
the more standard json-schema format. This commit adds a script to convert the
voluptuous schema to json-schema format using the `luscious` Python module.
Since that module has not been updated recently, we install and use a fork with
some changes.
Since this is a single-purpose command that's unlikely to be used by many
people it's not implemented as a mach command, but simply a standalone script
that can be invoked via `mach python`.
Differential Revision: https://phabricator.services.mozilla.com/D2841
--HG--
extra : rebase_source : d35ed221d05d1d56b96604b931c22b700c10e476
This change adds a voluptuous schema for build system telemetry, replacing
the existing json schema file. Using voluptuous will make it easier to work
with the schema from Python code in the build system. A future commit will
use a Python module to provide a mach command to convert the voluptuous
schema to json schema format for consumption by other systems.
Differential Revision: https://phabricator.services.mozilla.com/D2840
--HG--
extra : rebase_source : 067995385334d1dbc123f2db4245ef4e69d076c3
voluptuous 0.11.1 added support for a `description` argument for Required and
Optional objects, which is useful for adding descriptions in the schema that
we can persist when converting it to json-schema format. This patch vendors
the current version of voluptuous, which is 0.11.5.
MozReview-Commit-ID: 2qt1KE8MPYR
Differential Revision: https://phabricator.services.mozilla.com/D2839
--HG--
extra : rebase_source : f784a529a45fd5467de4dc39ab5db1624004bf2f
Verify mode runs tests multiple times. In the case of browser_startup_content.js,
this gives extra modules a chance to load before subsequent runs, which leads
to failures.
Since there's no particular reason to run this test in verify mode, the
obvious solution is to just disable it.
Differential Revision: https://phabricator.services.mozilla.com/D3430
--HG--
extra : rebase_source : 034fc518bc3e4346cc99404def659b7cf3233308
extra : amend_source : d80dfffefbc674a24c118800af03a12f638fb3a6
