Add some tests for the Oreo auto-fill frontend, similar to the tests for
the a11y auto-fill frontend. However, because these tests depend on the
ViewStructure class, they require SDK 23+ to run.
Differential Revision: https://phabricator.services.mozilla.com/D3810
Another reason to backout is that there may be other subtle breakage
like bug 1478623 and bug 1478269 and we don't have a lot of test
coverage on Android.
This also removes the trivial tests for geckoview_example that were
causing problems.
Differential Revision: https://phabricator.services.mozilla.com/D3991
--HG--
extra : moz-landing-system : lando
The fragment is also used to handle intents launched through GeckoAppShell.
openUriExternal(), such as e.g. when launching downloaded files from
about:downloads.
The synchronous code path when not in private browsing is already covered by the
code added in bug 1450449, but the async path through the fragment when in
private browsing needs to be handled separately.
Differential Revision: https://phabricator.services.mozilla.com/D3916
--HG--
extra : moz-landing-system : lando
Fix running robocop tests on debug builds.
This patch fixes multidex issues when running robocop on debug builds.
Differential Revision: https://phabricator.services.mozilla.com/D3422
--HG--
extra : moz-landing-system : lando
Add a frontend for the Oreo auto-fill API in SessionTextInput, which
processes events from Gecko and provides consumer APIs that match the
Oreo auto-fill APIs. GeckoView then forwards the necessary calls to
SessionTextInput.
Differential Revision: https://phabricator.services.mozilla.com/D3538
Add an auto-fill frontend that listens to events from Gecko. It
populates accessibility nodes for input fields and sends accessibility
events, in order to support auto-fill clients that use accessibility
services to perform auto-fill.
Differential Revision: https://phabricator.services.mozilla.com/D3254
Add an auto-fill backend in GeckoViewContent.js that detects fields on
the page and sends information about the fields to Java through events.
Differential Revision: https://phabricator.services.mozilla.com/D3253
Make the session store event listeners inline, because it makes the code
more readable, and also because auto-fill requires a pageshow listener
that is always registered, so the existing pageshow listener needs to be
moved elsewhere.
Differential Revision: https://phabricator.services.mozilla.com/D3252
Make a distinction between a session being active (i.e. being visible)
and it being focused. More than one session may be active at a time, but
only one session is focused at a time. This means the focused session is
always active, but an active session may not be focused.
Also, manage setting of active/focused states in GeckoView itself, so
consumers don't generally have to worry about these states.
Differential Revision: https://phabricator.services.mozilla.com/D3251
Move the AccessibilityNodeProvider implementation under
SessionAccessibility, to reduce the indent of the code.
Also make all methods in SessionAccessibility.Settings static to make
the code easier to follow.
Differential Revision: https://phabricator.services.mozilla.com/D3250
Add a frontend for the Oreo auto-fill API in SessionTextInput, which
processes events from Gecko and provides consumer APIs that match the
Oreo auto-fill APIs. GeckoView then forwards the necessary calls to
SessionTextInput.
Differential Revision: https://phabricator.services.mozilla.com/D3538
Add an auto-fill frontend that listens to events from Gecko. It
populates accessibility nodes for input fields and sends accessibility
events, in order to support auto-fill clients that use accessibility
services to perform auto-fill.
Differential Revision: https://phabricator.services.mozilla.com/D3254
Add an auto-fill backend in GeckoViewContent.js that detects fields on
the page and sends information about the fields to Java through events.
Differential Revision: https://phabricator.services.mozilla.com/D3253
Make the session store event listeners inline, because it makes the code
more readable, and also because auto-fill requires a pageshow listener
that is always registered, so the existing pageshow listener needs to be
moved elsewhere.
Differential Revision: https://phabricator.services.mozilla.com/D3252
Make a distinction between a session being active (i.e. being visible)
and it being focused. More than one session may be active at a time, but
only one session is focused at a time. This means the focused session is
always active, but an active session may not be focused.
Also, manage setting of active/focused states in GeckoView itself, so
consumers don't generally have to worry about these states.
Differential Revision: https://phabricator.services.mozilla.com/D3251
Move the AccessibilityNodeProvider implementation under
SessionAccessibility, to reduce the indent of the code.
Also make all methods in SessionAccessibility.Settings static to make
the code easier to follow.
Differential Revision: https://phabricator.services.mozilla.com/D3250
Bug 1481139 - p1: handle invalid file descriptors.
Bug 1481139 - p2: add dummy fds for GMP process.
Two file descriptors were added in bug 1438678 and 1471025 for content/child
process but not GMP process, and it breaks the IPC channel on Android.
Add dummy values to make it work for now before bug 1440207 clean up the mess.
Differential Revision: https://phabricator.services.mozilla.com/D3541
--HG--
extra : moz-landing-system : lando
The previous implementation attempted to delete files from /res/fonts (i.e.
root). I don't believe this was intended either:
https://bugzilla.mozilla.org/show_bug.cgi?id=878674#c0 indicates the fonts
directory should be inside the data dir of the application. The crash occurs
when the /res/fonts directory exists (only some devices) but the user doesn't
have read access. If the user has write access, our code may actually delete
these system files: uh oh!
My fix is to change the deletion from /res/fonts to <dir>/res/fonts. I verified
this fix worked by creating a clean profile, adding dummy files to the
res/fonts dir, and making sure only the correct ones were deleted (in zsh):
export DIR=/data/data/org.mozilla.fennec_mcomella; \
adb shell pm clear org.mozilla.fennec_mcomella && \
adb shell mkdir -p $DIR/res/fonts && \
for i in touch.ttf lol.rdf; do adb shell touch $DIR/res/fonts/$i; done && \
adb shell ls $DIR/res/fonts
MozReview-Commit-ID: 8atpcjYjGu0
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
This makes things saner for all consumers, which makes it worth doing on its
own. But it also gives me an easy nsTArray to work with, which I can use to
dispatch DOM events with array properties.
Differential Revision: https://phabricator.services.mozilla.com/D3466
--HG--
extra : rebase_source : e8bcc75e84845e42c932886502f99ca3154df48d
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.
Created specific notification channel dedicated to download progress notifications.
MozReview-Commit-ID: 88vsQiI2L2
***
--HG--
extra : rebase_source : 146563fd14a59299bc9bbba79fc9bdfd9e7ed37f
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant C++ functions are updated to take a typed enum. JavaScript
calls are unaffected but they will throw if the string argument does not
correspond to one of the known entries in the C++ enum. The existing whitelists
and blacklists of annotations are also generated from the YAML file and all
duplicate code related to them has been consolidated. Once written out to the
.extra file the annotations are converted in string form and are no different
than the existing ones.
All existing annotations have been included in the list (and some obsolete ones
have been removed) and all call sites have been updated including tests where
appropriate.
--HG--
extra : source : 4f6c43f2830701ec5552e08e3f1b06fe6d045860
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 : 72164b6e6b9c8e1a2f31a33db9b8da7d457739a9
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 : a99e4688d6724e5b73b748078f51cf6a6268733d
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.
MozReview-Commit-ID: 5s5NEJcuS0p
--HG--
extra : rebase_source : 2b61942672d27453a936174c16f843109c9e36ba
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 : e9b5a7478cfb8a9ad44c149e3ba1532f22ab4086
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 : 345c838325264399cc7f7829cc587faf7e9cc756
This permission is needed on API26+ to be able to install app updates but also
other downloaded APKs.
MozReview-Commit-ID: Lk0uqBAJ5BH
--HG--
extra : rebase_source : 5f31cfd06c2205cd2a96ac68ba19b697d49ae75c
This alters nsILoadURIDelegate.loadURI() to return a Promise rather than spinning the event loop to synchronously return a boolean, and alters nsDocShell::InternalLoad to allow for those changes by re-calling itself if necessary based on the resolution of the promise.
Multidex will now be enabled for all builds, not just for the _local_ ones.
Also added the 'ads-identifier' library needed for the builds with the
MOZ_INSTALL_TRACKING flag case in which the dex limit would be reached.
MozReview-Commit-ID: FRTXBD9Kc6T
--HG--
extra : rebase_source : c73a0a48d355edbe2080b14ceeb2f99609a45d7c
This happened whenever starting to cast a video and loading the media failed.
MediaStatus in this case would be null and querying it would throw a
NullPointerException.
Avoiding this query when the MediaStatus is null lets the normal execution flow
continue and if loading media failed casting will fail gracefully.
MozReview-Commit-ID: 8ZOqr1FO1Dt
--HG--
extra : rebase_source : 905b7e83bc7265fe8312509dfc5aa6274dd89c5c
In order to use DOMLocalization from C++ we need an XPIDL interface.
mozIDOMLocalization exposes the class and functionality allowing DocumentL10n to hook into it.
MozReview-Commit-ID: GPMhw61LPEg
--HG--
extra : rebase_source : 65d6e2b84379e78201f0c8b674630d1f485aaf8c
The 'dataType' parameter to nsISearchEngine.addEngine is now obsolete.
MozReview-Commit-ID: CTe26M0j4xa
Differential Revision: https://phabricator.services.mozilla.com/D2778
--HG--
extra : moz-landing-system : lando
Fixed the issue where we it was trying to parse a drawable instead of an id from parcelable.
MozReview-Commit-ID: IEgmAT39JiQ
Differential Revision: https://phabricator.services.mozilla.com/D2924
--HG--
extra : moz-landing-system : lando
Previously, this wasn't noticeable since adding/removing a PageAction would call
refreshPageActionIcons(), which would do the correct thing, but now a newly
created PageActionLayout can start with an already pre-populated mPageAction-
List, which means that the subsequently arriving call to setPrivateMode() will
erroneously activate the private mode tinting for all PageActions that support
it.
MozReview-Commit-ID: EvNx1Q9vwZ5
--HG--
extra : rebase_source : 17781b64e77c52affcb76e2e9debc925a7c32f8e
When a PageActions:Remove message arrives and we cannot simply forward it, we
need to remove not just pending PageActions:Add messages, but also any already
present PageActions objects that a former PageActionLayout had handed to us.
MozReview-Commit-ID: 3jnGsmMuVfa
--HG--
extra : rebase_source : 7ca27912f06dfcc82a73faa644bc4583c381bec6
Despite its name and the original purpose for which it was added, that function
generically checks for duplicates among all PageActions, not just the PWA badge.
MozReview-Commit-ID: Ae6FsLb9F3S
--HG--
extra : rebase_source : 0ea24add9f941b21b66b4fd216833a46bfa2a5ed
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 patch adds JaCoCo as a dependency for the geckoview androidTest configurations, as well as
the `mach android archive-geckoview-coverage-artifacts` command, and the `--enable-java-coverage`
mozconfig flag.
MozReview-Commit-ID: 36jNAzK44g3
--HG--
extra : rebase_source : 9edc37913a3929ad045270c601c77791d122e363
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant functions are updated to take a typed enum (in C++) and an
integer constant (in JavaScript). A JavaScript wrapper around the crash
reporter service is provided to hold the constants. The existing whitelists
and blacklists of annotations are also generated from the YAML file and the
existing duplicate code has been consolidated. Once written out to the .extra
file the annotations are converted in string form and are no different than
the existing ones.
All existing annotations have been included (and some obsolete ones removed)
and all call sites have been updated including tests.
--HG--
extra : rebase_source : b4f0d4bf83c64851028c271d3fab3ebcb6fbcd3e
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant functions are updated to take a typed enum (in C++) and an
integer constant (in JavaScript). A JavaScript wrapper around the crash
reporter service is provided to hold the constants. The existing whitelists
and blacklists of annotations are also generated from the YAML file and the
existing duplicate code has been consolidated. Once written out to the .extra
file the annotations are converted in string form and are no different than
the existing ones.
All existing annotations have been included (and some obsolete ones removed)
and all call sites have been updated including tests.
--HG--
extra : rebase_source : f0e8d229581ac5c0daa0e0454cb258746108e28d
I generally tried to preserve the behavior of consumers where they treated an
exception from getInterface(Ci.nsIContentFrameMessageManager) as a signal to use
some sort of fallback.
I did change the behavior of consumers that walked up to the root same-type
docshell before getting the message manager to just get it directly from the
docshell they have. Please review those parts carefully, and let me know if you
want me to ask some subject area experts to review those.
Used the provided foreground layers and background color for the icons of
Release and Nightly.
Used the old icon and the provided background color for the icons of Beta and
Dev builds. Proper icons for them will be added in bug 1479724.
Added support for round icons which as per
https://developer.android.com/about/versions/nougat/android-7.1#circular-icons
can be required by certain launchers.
The old icons - /drawable/icon.png are still kept because they are used as
logos and also by SiteIdentityPopup.java.
MozReview-Commit-ID: EA9pojukhmw
--HG--
extra : rebase_source : d960bb0785b329a91493d9fe2c126549a5641189
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
Fix the clear() call to clear highlights in addition to the selection.
MozReview-Commit-ID: 1DNXa8fIGTP
--HG--
extra : rebase_source : c84033c644becf2c9b0e7df8d2580523e75de97d
Android-specific WebExtension modules (e.g. ext-android.js) are
currently packaged inside chrome.jar. However, GeckoView only includes
geckoview.jar and not chrome.jar. So to make GeckoView be able to load
WebExtensions at all, we need to move these modules to geckoview.jar.
MozReview-Commit-ID: CVpIAZxgkwy
--HG--
extra : rebase_source : 73e5df7dc32faf326787293f9938319fffa55fad
