- Various element IDs and strings were renamed in the preceeding patches before this. This fixes
the strings and element ID reference in the RDM unit tests.
- Fixed RDM unit tests to work with new native context menu which used to be <select> elements.
- Removes the duplicate dropdown arrow icon that is used in both RDM and Network monitor
- Converts the network throttling menu in the network monitor to be a shared component that
can be used in both RDM and network monitor
- Move the common styles for the dropdown menu button into toolbars.css
--HG--
rename : devtools/client/shared/components/throttling/NetworkThrottlingSelector.js => devtools/client/shared/components/throttling/NetworkThrottlingMenu.js
- Converts the reload condition <select> to use native context menu
- Converts the showMenu util to be reusable by both RDM and the Network Monitor
- Renames getToplevelWindow to getTopLevelWindow
- Renames the reload condition menu to be a setting menu in RDM according to the designs
- Uses the new photon setting icon in RDM
--HG--
rename : devtools/client/responsive.html/components/ReloadConditions.js => devtools/client/responsive.html/components/SettingsMenu.js
rename : devtools/client/netmonitor/src/utils/menu.js => devtools/client/shared/components/menu/utils.js
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
