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
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
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
Summary:
The about:crashes page is being updated (bug 1463515). To facilitate these changes,
this patch changes the about:crashes page to use Fluent for localization instead of the old systems.
This also includes a script to migrate strings from the old .DTD and .properties files
to the new .ftl one.
Test Plan:
1. build Firefox with the changes
2. run Firefox
3. go to the about:crashes page
4. expect nothing to be different
This extension: https://github.com/rhelmer/webext-experiment-crashme can be used to
add local crash reports for verifying the different states of the about:crashes page.
Reviewers: flod, Pike, jchen, snorp
Reviewed By: flod, Pike, jchen, snorp
Subscribers: nalexander, reviewbot
Bug #: 1476034
Differential Revision: https://phabricator.services.mozilla.com/D2225
--HG--
extra : rebase_source : 0ca9516b4df78e735fd03907f2ea324bc72ca893
- Access nsISSLStatus directly as a member of nsITransportSecurityInfo
and nsISecureBrowserUI. This is part of a larger effort to consolidate
nsISSLStatus and nsITransportSecurityInfo.
- The TabParent implementation of GetSecInfo will always return null.
- Removed unnecessary QueryInterface calls
- Style adherence updates
MozReview-Commit-ID: Dzy6t2zYljL
--HG--
extra : rebase_source : 9c400bed3c9d29a186fc987c9bd0ffceb37bfd94
- Access nsISSLStatus directly as a member of nsITransportSecurityInfo
and nsISecureBrowserUI. This is part of a larger effort to consolidate
nsISSLStatus and nsITransportSecurityInfo.
- The TabParent implementation of GetSecInfo will always return null.
- Removed unnecessary QueryInterface calls
- Style adherence updates
MozReview-Commit-ID: Dzy6t2zYljL
--HG--
extra : rebase_source : fbfbcf7608efbfb35c9be4018ff0f4e70b2768d2
In Bug 1188240 we disabled autoplay on Android < API version 16 because of a
vulnerability in old libstagefright, but as of Firefox 55 our minimum supported
Android version is 4.1, or API verion 16.
We've renamed the media.autoplay.enabled pref, so we can just remove the
check on media.autoplay.enabled added in bug 1188240 as it's testing for a
version of Android we no longer support anyway..
MozReview-Commit-ID: Gc8ZnlOiiMn
--HG--
extra : rebase_source : 12817b6e782331f3e4f26be0b97181418ec3287f
Added reading permission as a safety measure for any future android updates.
MozReview-Commit-ID: Be6V8hn9KF8
***
--HG--
extra : amend_source : 501deb367f68b0592a1d91015c640782700c62f3
Based on Sebastian's addon - https://github.com/pocmo/Addon-Switchboard-Experiments,
this will allow to easily enable / disable Switchboard experiments, process
that after Firefox 57 and the obsolescence of the addon was too cumbersome.
MozReview-Commit-ID: 2EkYQ42Bd8B
--HG--
extra : rebase_source : 7024c1d68897bea9d80f3fc857c5b204f77c8725
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
Currently Fennec remote debugging has a bug where custom tabs / PWA can
permanently override debugging of Fennec tabs. Fix that bug by switching
between the browser/geckoview window types depending on if the Fennec
window is gaining or losing focus.
MozReview-Commit-ID: 2BhAOPFz3c0
--HG--
extra : rebase_source : b9b6059241549bdb6badcc5702c9e47e7228edb3
Currently Fennec remote debugging has a bug where custom tabs / PWA can
permanently override debugging of Fennec tabs. Fix that bug by switching
between the browser/geckoview window types depending on if the Fennec
window is gaining or losing focus.
MozReview-Commit-ID: 2BhAOPFz3c0
--HG--
extra : rebase_source : b9b6059241549bdb6badcc5702c9e47e7228edb3
Currently Fennec remote debugging has a bug where custom tabs / PWA can
permanently override debugging of Fennec tabs. Fix that bug by switching
between the browser/geckoview window types depending on if the Fennec
window is gaining or losing focus.
MozReview-Commit-ID: KEXPwAfl32X
--HG--
extra : rebase_source : c9dd78aa426f2fe27e58ca0fe329e970c1485c35
Our current way is somewhat convoluted - we manually create an about:neterror
URL in the Android UI and then load it from the ContentDispatchChooser by simply
setting window.location.href, which means that the page URL won't reflect the
actual URL we were trying to load and the rest of Gecko will think that the page
load succeeded (unless they're explicitly checking the URL for the presence of
about:neterror).
MozReview-Commit-ID: Z0LSSE6AGU
--HG--
extra : rebase_source : 95b390ca30e08222f140f5d6d790ca93a49363ba