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
This provides support for using XUL elements in chrome XHTML documents,
including the experimental xhtml browser window (browser.xhtml).
Differential Revision: https://phabricator.services.mozilla.com/D3432
--HG--
extra : moz-landing-system : lando
This test runs code in the frame script, which has system privileges. Even
though it trips the security tests as it is, it's not clear whether that
should be the case or not. By running the code in the page itself, the
expected behavior is governed by the service workers spec and is thus well
defined.
Differential Revision: https://phabricator.services.mozilla.com/D3323
--HG--
extra : moz-landing-system : lando
This mirrors the web-platform-tests change at
6058e914c1
According to that commit, WebKit/Chromium/EdgeHTML all have the behavior
that we're switching to here.
Differential Revision: https://phabricator.services.mozilla.com/D3429
--HG--
extra : moz-landing-system : lando
Removed remaining imports of commandline helpers, as they are no longer used anywhere
Differential Revision: https://phabricator.services.mozilla.com/D3412
--HG--
extra : moz-landing-system : lando
remote-control-icon doesn't have an image/width/height when the remotecontrol attribute isn't set on #main-window, so it's invisible (visually).
However, it is still exposed to accessibility, as it is not marked as hidden in any definite way.
This change applies CSS visibility: collapse by default, causing this to be hidden for accessibility too.
That is then overridden by the existing visibility: visible when the remotecontrol attribute is set.
Differential Revision: https://phabricator.services.mozilla.com/D3074
--HG--
extra : moz-landing-system : lando
We were previously considering the grammar for conditionals in wpt
manifests to be something like:
"if " expr ":" string
This excluded the possibilty of complex values on the RHS. Here we
change it to the more obvious (and intended)
"if " expr ":" value
MozReview-Commit-ID: G6YWscW9dJS
Differential Revision: https://phabricator.services.mozilla.com/D3127
--HG--
extra : moz-landing-system : lando
This also returns to using a single convolver for processing of mono input,
which introduces complexity in up-mixing the state of the convolver when a
second channel is added.
MozReview-Commit-ID: KeBrAswQbtF
--HG--
extra : rebase_source : d793bd967e0291069e4e6cc418de53c4b4cf3253
