Since converting a PageAction message into an actual PageAction object also en-
tails parsing the image data URL into a drawable, we leave that task to the
PageActionLayout.
This means that the PageAction cache needs to operate slightly differently than
the MenuItem cache. First, we store all PageAction BundleEvent messages that
arrive while no PageActionLayout is ready and then forward them en masse when
one becomes available. Secondly, if the PageActionLayout is going away again,
we then also take a list of already parsed PageAction objects for safekeeping.
MozReview-Commit-ID: AcPPONXqe46
--HG--
extra : rebase_source : 696df760f28f9d126858920b544585e4c86219ff
Since all related EventDispatcher messages use UUIDs, it makes sense to store
our MenuItemInfos in a Map, so we can access them directly by UUID instead of
having to iterate over them until we've found the desired one.
Since we want to preserve the order in which MenuItemInfos were added, we use a
LinkedHashMap.
MozReview-Commit-ID: BEtJ59tX59m
--HG--
extra : rebase_source : 8012b11c1e36b774972a0cc4a6f748ccaace7533
The small savings in initialising this on demand the first time a menu item is
added, are not worth the additional complexity in null checks and the like.
MozReview-Commit-ID: Lcz09Ds8NxJ
--HG--
extra : rebase_source : 379789298e0d60d353426c665a8f89c551ceaa66
Bug 832990 solved the issue of us losing the menu item cache if BrowserApp was
destroyed, however the issue remains that we'll miss any Menu:... messages that
are sent while BrowserApp doesn't exist, e.g. if Gecko is initially loaded
through a GeckoView-based activity.
Therefore we now move the menu item cache and the listener for those messages
into a separate class, whose lifetime better matches that of Gecko.
Apart from any necessary changes, we move the existing code as is. The only
additional change is that we make addAddonMenuItemToMenu() static, because we
can.
MozReview-Commit-ID: BJleonLnjmo
--HG--
extra : rebase_source : e36d954488cc44d250948edcbb8a1964e24ddab7
As a final step, these can be merged as well. The same reasoning as in the
previous patch applies with regards to additional functionality that isn't
(yet) used by webextensions.
MozReview-Commit-ID: Ezx2mQY0s85
--HG--
extra : rebase_source : 955462126312241ca860e8184507bd7ed4955450
The original add-on functions have some additional capabilities regarding e.g.
checkboxes, disabling the menu, etc. that right now aren't required for
Webextensions (yet?), but in that case they will simply not be used - in any
case BrowserActions.jsm controls what functionality is actually exposed to
add-ons.
MozReview-Commit-ID: DPT8gV2gb6q
--HG--
extra : rebase_source : 09a0a52c374c1c423002e9dcb5edc0c7e2730bbd
Now that the UI code for handling both the old NativeWindow API and Web-
extensions is more or less the same and both are using the same MenuItemInfo
class, there's no longer any real need to keep items added through the two APIs
in separate lists - in fact doing so makes it harder to preserve the ordering
of menu items if the activity and its menu are destroyed and need to be re-
created later on from the stored lists of MenuItemInfos.
MozReview-Commit-ID: KlJdvO9WhhY
--HG--
extra : rebase_source : 2d28262f72acaa0e0e6966f8309ef9569d3f6314
Now that both Webextensions and the NativeWindow API manage their onClick call-
back handling by UUID, we can start using the same EventDispatcher message for
both.
MozReview-Commit-ID: J3RRXrwPdTI
--HG--
extra : rebase_source : 7f136d70944641391e57a76efdec6546fe74cfd0
Since the NativeWindow API now only uses UUIDs as well when dealing with its
consumers, we can leave generation of the menu to the Android UI code of
Firefox.
MozReview-Commit-ID: 1qDLDnePfFE
--HG--
extra : rebase_source : d1320f92ebd4be0237d3da554a3f8182a0e72d4e
At the moment, the code for handling of JS-created main menu items is more or
less duplicated between the old NativeWindow API and Webextensions, with the
only real difference being that the former communicates directly via menu item
IDs, while the latter uses UUIDs for messaging between Gecko and the UI.
By switching the NativeWindow API to using UUIDs as well, we will be able to
start unifying this code again.
As for backward compatibility
- the return value of NativeWindow.menu.add is valid for the current session
only, so no migration is necessary
- the return value of NativeWindow.menu add was already effectively only an
opaque value which only had real meaning for subsequent calls to menu.add,
menu.update and menu.remove, so it shouldn't really matter whether we return
a plain numeric ID or an UUID in string form
- old-style add-ons are now unsupported for better or for worse and our one in-
tree caller won't have any problems with this change
MozReview-Commit-ID: HdRNhrx1pu7
--HG--
extra : rebase_source : 33ce855ac2f2f65fe20cb5047de3b8cbbcd094d9
We no longer use that value anywhere, so we can just stop keeping track of it.
MozReview-Commit-ID: D1IgX1t8SKI
--HG--
extra : rebase_source : 51288c866bdd078aed629590ad39b2f8d524d044
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
Creating non-shared scopes for frame scripts is fairly expensive. After these
changes it's even more expensive. However, many frame scripts have no use for
the shared scopes at all. Run-once scripts which execute in closures, for
instance, make no use of them. And after bug 1472491, neither do most of our
default frame scripts.
MozReview-Commit-ID: 9PK7bYdQ0yh
--HG--
extra : rebase_source : db2516d2f00a75e233e1957649f2b62a9299b7cd
This adds the basic framework for defining IPC actors which are lazily
instantiated for the appropriate frame loaders based on DOM events, message
manager messages, and observers. Actual actors are defined in follow-up
commits.
MozReview-Commit-ID: Jb6CWWW7v3v
--HG--
extra : rebase_source : 6c465c492ef423616346d70047c4fd4b074af303
Created a dedicated channel for media notifications.
MozReview-Commit-ID: JKFVPNRu2WO
--HG--
extra : rebase_source : f9df42ecae1467c337c0d4bdbd5c5582e47c582c
Summary:
When running on pre Oreo devices CrashReportingService (a JobIntentService)
is started as a regular Service.
Return super.onStartCommand(..) to make sure onHandleWork() would be caled.
Reviewers: sdaswani, VladBaicu, jchen
Reviewed By: jchen
Bug #: 1480421
Differential Revision: https://phabricator.services.mozilla.com/D3102
--HG--
extra : rebase_source : 78d83fca65b000a10e2f8b522c8ee57cd364a829
extra : histedit_source : 71a48d23421fec60ded4c0c45c8cafb8927196ab
We're currently using NDK r15c, which is rather old, and happens to come
with a buggy gold linker. Let's use a more recent NDK, with a fixed
linker.
Unfortunately, we're currently at NDK API level 9, which the newer NDK
doesn't provide for x86 anymore. But that corresponds to Gingerbread
(2.3), which we've long stopped supporting. On the SDK side, we already
dropped support of versions before Jelly Bean, so we can do the same on
the NDK side. That corresponds to API level 16. So let's just use that
as a baseline.
Another change in the newer NDK is that the target-name changed from
i386-linux-android to i686-linux-android, so adjust for that in the
android x86 mozconfigs.
We're currently using NDK r15c, which is rather old, and happens to come
with a buggy gold linker. Let's use a more recent NDK, with a fixed
linker.
Unfortunately, we're currently at NDK API level 9, which the newer NDK
doesn't provide for x86 anymore. But that corresponds to Gingerbread
(2.3), which we've long stopped supporting. On the SDK side, we already
dropped support of versions before Jelly Bean, so we can do the same on
the NDK side. That corresponds to API level 16. So let's just use that
as a baseline.
Another change in the newer NDK is that the target-name changed from
i386-linux-android to i686-linux-android, so adjust for that in the
android x86 mozconfigs.
