The window will be supplied in the recording-device-events notification and mediaCaptureWindowState will be called on each window in turn.
Differential Revision: https://phabricator.services.mozilla.com/D56569
--HG--
extra : moz-landing-system : lando
This is useful if you get a certificate-related error and want
to inspect the broken certificate.
Differential Revision: https://phabricator.services.mozilla.com/D58170
--HG--
extra : moz-landing-system : lando
This is the server certificate, if any, as a
java.security.cert.X509Certificate.
Differential Revision: https://phabricator.services.mozilla.com/D58156
--HG--
extra : moz-landing-system : lando
Now that everything in `GeckoProcessManager` runs on the XPCOM launcher thread,
`GeckoThread` should just call `GeckoProcessManager.preload()` directly.
Differential Revision: https://phabricator.services.mozilla.com/D57840
--HG--
extra : moz-landing-system : lando
The primary purpose of this patch is to convert the internal sequence of
service binding and invoking of `start` to asynchronously run on the XPCOM
launcher thread via `GeckoResult`. Because more of the code now runs on the same
thread, many of these methods no longer need to be `synchronized`.
Disconnecting via `unbind` is also modified to use the launcher thread and
`GeckoResult`.
Note that no changes have been made yet to enable multiple processes of the
same type; those changes will be made in bug 1595834.
Differential Revision: https://phabricator.services.mozilla.com/D57839
--HG--
extra : moz-landing-system : lando
This patch adds a `Dispatcher` implementation that allows us to create
`GeckoResult`s that will dispatch to the XPCOM launcher thread.
Differential Revision: https://phabricator.services.mozilla.com/D57838
--HG--
extra : moz-landing-system : lando
Since `XPCOMEventTarget` uses JNI, this patch makes it possible for consumers to
retrieve and invoke methods on one without needing to worry about whether JNI
is actually up yet.
To achieve this, we create the `IXPCOMEventTarget` interface, and observe that
both of its methods can be handled by a proxy if JNI is not ready:
* Calls to `dispatch` may be enqueued until JNI is up;
* Observe that, when JNI is not up yet, the result of `isOnCurrentThread`
can never be `true`.
Once JNI is up and the event targets have been resolved, the proxies are
replaced with the real, concrete `XPCOMEventTarget`s and are no longer used for
the remainder of the Gecko instance's lifetime.
Differential Revision: https://phabricator.services.mozilla.com/D57837
--HG--
extra : moz-landing-system : lando
`TestCrashHandler.Client` expects to run in the UI thread, so we move calls
to its methods into `crashParent` and annotate the test with `@UiThreadTest`.
Differential Revision: https://phabricator.services.mozilla.com/D58577
--HG--
extra : moz-landing-system : lando
This commit does two things:
- It exposes the error that caused the test to fail in our logs, so it would
appear like so:
```
TEST-UNEXPECTED-FAIL | org.mozilla.geckoview.test.ExtensionActionTest.setIconSvg[#pageAction] | java.lang.AssertionError: We shouldn't get here
```
- It catches exceptions that are raised before any test code is run and outputs
a different message (since those failures do not depend on the test at all),
like so:
```
ERROR runjunit.py | The previous test failed because of an error in the test harness | org.mozilla.geckoview.test.rule.TestHarnessException: java.lang.RuntimeException: We shouldn't get here
```
This will hopefully help with spurious intermittents and understand when a
failure changes.
Differential Revision: https://phabricator.services.mozilla.com/D58022
--HG--
extra : moz-landing-system : lando
Autofill service application uses email, username and password hint for login
form. Some sites use email value for autocomplete attribute even if
`<input type="text">`. So we should set autofill hint for this situation.
Differential Revision: https://phabricator.services.mozilla.com/D58215
--HG--
extra : moz-landing-system : lando
It is the right way to do that now. Though again we should probably just link to
the moz-phab docs.
Differential Revision: https://phabricator.services.mozilla.com/D58049
--HG--
extra : moz-landing-system : lando
We then convert that to `#aarrggbb` in GeckoView for convenient use
with `android.graphics.Color`.
Differential Revision: https://phabricator.services.mozilla.com/D57689
--HG--
extra : moz-landing-system : lando
Talkback users expect that when you navigate past the end of the text in a node, Talkback will move into the next node and navigate there.
However, even though text navigation is async (client performs an action on the focused accessible and then waits for a text traversal event), firing a traversal event with a different accessible from the focused accessible is not supported by Talkback.
Firing a11y focus on the new node (as we did previously) doesn't fix this, but instead causes the entire node to be reported, among other weird behaviour.
1. Don't fire a11y focus for text traversal.
Aside from Talkback reporting the entire node, this was also confusing Talkback, causing it to try to navigate several times into the new node.
2. When navigating text, cache whether we're at either edge.
We do this because we need to be able to synchronously query whether we're at the edge, but we do navigation async.
Special handling is needed for words at the end because words don't include trailing space.
3. When performing a text navigation action, check if we're already at the edge using the cache described above.
If we are, synchronously return false, as Talkback expects.
Talkback will then move to the next/previous node itself and navigate the text there.
Differential Revision: https://phabricator.services.mozilla.com/D57926
--HG--
extra : moz-landing-system : lando
Right now we only detect `onCrash` on mochitests/reftests and `onKill` on junit
tests.
This change makes it so we wait for both on every type of test.
Differential Revision: https://phabricator.services.mozilla.com/D57895
--HG--
extra : moz-landing-system : lando
remove unused Fennec components in mobile/android/components (only the geckoview or extensions subdirs are used by GeckoView).
Differential Revision: https://phabricator.services.mozilla.com/D57394
--HG--
extra : moz-landing-system : lando
Add a document.addCertException function to about:certerror pages, and use it on the desktop certerror page.
Also, as the CallerIsTrusted* functions expect URLs like about:certerror, but GeckoView error pages are data URLs, and so need to be handled differently for these special error-page methods to be exposed on their documents.
Example usage of document.addCertException:
document.addCertException(
true|false /* true == temporary, false == permanent */
).then(
() => {
location.reload();
},
err => {
console.error(err);
}
);
Differential Revision: https://phabricator.services.mozilla.com/D56974
--HG--
extra : moz-landing-system : lando
This also fixes a lifetime issue where we may have been leaking the
native instance of `WebResponse.Support`.
Differential Revision: https://phabricator.services.mozilla.com/D56994
--HG--
extra : moz-landing-system : lando
Along with this comes a new test server for use with GeckoView JUnit
tests based on AndroidAsync. This allows us to have more control
over responses and gets us off of the end-of-lifed Jetty we were using
before.
Differential Revision: https://phabricator.services.mozilla.com/D56993
--HG--
extra : moz-landing-system : lando
We have implemented new audio focus management in bug1565689 which would allow us to have one tab playing audio at the same time no matter we're using e10s or Fission.
Therefore, we can remove the old pref dom.audiochannel.audioCompeting and dom.audiochannel.audioCompeting.allAgents, which are only work on non-e10s mode.
In addition, the audio competing is only used by default on Fennec, but Fennec is now no longer following the latest m-c, it's using ESR68. So even if our new audio focus management is not on by default on Android, it won't affect current behavior on Fennec. We can 100% sure that we won't need those code for old audio competing anymore.
Differential Revision: https://phabricator.services.mozilla.com/D44749
--HG--
extra : moz-landing-system : lando
Add a document.addCertException function to about:certerror pages, and use it on the desktop certerror page.
Also, as the CallerIsTrusted* functions expect URLs like about:certerror, but GeckoView error pages are data URLs, and so need to be handled differently for these special error-page methods to be exposed on their documents.
Example usage of document.addCertException:
document.addCertException(
true|false /* true == temporary, false == permanent */
).then(
() => {
location.reload();
},
err => {
console.error(err);
}
);
Differential Revision: https://phabricator.services.mozilla.com/D56974
--HG--
extra : moz-landing-system : lando
`port.connectNative` is synchronous, so there is the slim possibility that a
message could be sent before the app has been notified that the port has been
created. Similarly, if the app has not attached a listener yet, the port
message gets lost.
In either case, we now store this message in a list that we check when a
delegate is attached to the port object.
Differential Revision: https://phabricator.services.mozilla.com/D57511
--HG--
extra : moz-landing-system : lando
The controller will be used in a later patch to listen to delegates updates.
Differential Revision: https://phabricator.services.mozilla.com/D57366
--HG--
extra : moz-landing-system : lando
This also fixes a lifetime issue where we may have been leaking the
native instance of `WebResponse.Support`.
Differential Revision: https://phabricator.services.mozilla.com/D56994
--HG--
extra : moz-landing-system : lando
Along with this comes a new test server for use with GeckoView JUnit
tests based on AndroidAsync. This allows us to have more control
over responses and gets us off of the end-of-lifed Jetty we were using
before.
Differential Revision: https://phabricator.services.mozilla.com/D56993
--HG--
extra : moz-landing-system : lando
* We add bidirectional messaging to `TestCrashHandler`:
1. The test sends a message to the `TestCrashHandler`, notifying it that an
upcoming crash is intentional and its intent should be checked.
2. Upon receipt of the crash report, the service reviews the contents of the
crash intent, and then sends a message back to the test with the test results.
3. The service deletes any crash dump artifacts belonging to crash intents
that have been evaluated so that the harness doesn't pick up any
intentional crashes.
* We remove `crashContent` from `CrashTest.kt` and create `ContentCrashTest.kt`
for that case. The `crashParent` test remains unchanged other than switching
its crash handler over to `TestCrashHandler`.
* We remove the `CrashTestHandler` service, as both `crashContent` and
`crashParent` tests now use `TestCrashHandler`.
Differential Revision: https://phabricator.services.mozilla.com/D56854
--HG--
rename : mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/crash/CrashTest.kt => mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/ContentCrashTest.kt
rename : mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/crash/CrashTest.kt => mobile/android/geckoview/src/androidTest/java/org/mozilla/geckoview/test/crash/ParentCrashTest.kt
extra : moz-landing-system : lando
This change modifies all tests that use key3/cert8 to use the new files. It
removes test_sdr_upgraded_with_password, as without the upgrade part that is now
the same test as test_sdr_preexisting_with_password.
Differential Revision: https://phabricator.services.mozilla.com/D55708
--HG--
rename : security/manager/ssl/tests/unit/test_sdr_preexisting/key4.db => security/manager/ssl/tests/unit/test_broken_fips/key4.db
extra : moz-landing-system : lando
This change modifies all tests that use key3/cert8 to use the new files. It
removes test_sdr_upgraded_with_password, as without the upgrade part that is now
the same test as test_sdr_preexisting_with_password.
Differential Revision: https://phabricator.services.mozilla.com/D55708
--HG--
rename : security/manager/ssl/tests/unit/test_sdr_preexisting/key4.db => security/manager/ssl/tests/unit/test_broken_fips/key4.db
extra : moz-landing-system : lando
For paragraphs, divs, spans, etc., a11y focus on Android goes to text leaf Accessibles, rather than to the HyperTextAccessible container.
This does make sense, as these containers frequently embed other content, so the text needs to be reachable as a separate item.
However, previously, performing text navigation on these text leaf Accessibles returned the HyperTextAccessible parent.
This isn't supported by Talkback, and even if it were, it causes other problems; e.g. a11y focus being lost if the user was focused on a child other than the first child of such a container.
Therefore, if text navigation was performed on a text leaf Accessible, we now return a result within the text leaf Accessible if possible, rather than the HyperTextAccessible.
1. Make AccessibleWrap::GetTextContents support text leaf Accessibles (for both local and remote proxied Accessibles).
This is used when providing text for text traversal events.
2. When navigating text on Android, we use Pivot::Next/PrevText.
However, this will always return a HyperTextAccessible, even when starting on a text leaf.
Therefore, if the result from Pivot::Next/prevText resides entirely within the same text leaf, translate the offsets from the HyperTextAccessible so they're relative to the text leaf and return the text leaf.
3. Pivot::Next/PrevText already supported starting from a text leaf Accessible.
However, they ignored the offsets, which meant that navigating from a text leaf would always navigate to the start/end of the text leaf.
Now, if a text leaf is passed to Pivot::Next/PrevText, the offsets (if specified) are translated to the HyperTextAccessible parent first.
4. Adjust the existing character/word/line tests so they ensure that navigation returns the node that has a11y focus; i.e. the text leaf.
Differential Revision: https://phabricator.services.mozilla.com/D57269
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
This change removes the legacy libnssdbm database that we migrated away from since Firefox 60.
This change modifies all tests that use key3/cert8 to use the new files. It
removes test_sdr_upgraded_with_password, as without the upgrade part that is now
the same test as test_sdr_preexisting_with_password. It otherwise removes support for libnssdbm everywhere in Gecko.
Differential Revision: https://phabricator.services.mozilla.com/D55708
--HG--
rename : security/manager/ssl/tests/unit/test_sdr_preexisting/key4.db => security/manager/ssl/tests/unit/test_broken_fips/key4.db
extra : moz-landing-system : lando
Since bug 1514429 window.inner{Width,Height} don't return the visual viewport
size so once after the content scale changed, i.e. the visual viewport size
doesn't match window inner size, GeckoView::ScrollBy and ScrollTo don't work
as expected. This commit has JUnit tests to generate the situation by calling
nsIDOMWindowUtils.setResolutionAndScaleTo.
Differential Revision: https://phabricator.services.mozilla.com/D56321
--HG--
extra : moz-landing-system : lando
This will allow us to know whether a certain window is controlled GeckoView or
not in the content process.
Differential Revision: https://phabricator.services.mozilla.com/D56651
--HG--
extra : moz-landing-system : lando
The GeckoView is listening OnContentBlockingEvent in the content process.
As we move the event into the parent process, we have to change it to
listen the event in the parent process.
This patch also adds a workaround in the test
ContentBlockingControllerTest#getLog(). This workaround adds a 500ms
delays before we check the ContentBlockingLog. This is needed because there
is a delay between the notification of OnContentBlockingEven in the parent
process and the actual recording of the log in the content process. This
workaround will be no longer needed once we move the log entirely to the
parent process (Bug 1599046).
Differential Revision: https://phabricator.services.mozilla.com/D56749
--HG--
extra : moz-landing-system : lando
We had to do it because firefox android doesn't use that file. There is a
mobile.js file for that purpose. We had to move all recording preferences to
all.js and add the android only preference to mobile.js to be able to handle
that better.
Differential Revision: https://phabricator.services.mozilla.com/D56719
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
MOZ_PGO_PROFILE_USE is used to enable certain features in the automation
mozconfigs for profile-use builds, including the MOZ_PROFILE_USE
configure option. They aren't easily combined into one flag due to the
extra settings that are enabled only in automation mozconfigs.
Renaming the former variable to TASKCLUSTER_PGO_PROFILE_USE makes it
slightly more obvious where it comes from and avoids confusion.
Differential Revision: https://phabricator.services.mozilla.com/D56117
--HG--
extra : moz-landing-system : lando
And don't call setFixedBottomOffset in GeckoSession.onCompositorReady if it's not
been changed since the initialization.
Differential Revision: https://phabricator.services.mozilla.com/D56324
--HG--
extra : moz-landing-system : lando
That is, we consume the synthesized mouse move events without doing
anything in PressCaretState and DragCaretState.
Differential Revision: https://phabricator.services.mozilla.com/D52113
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
Non-AddonManager extensions are invisible to GeckoView, so when a message like
"open a new tab" comes to GeckoView we will ignore them unless the extension is
properly registered.
Because of this, we need to register them in tests too.
Differential Revision: https://phabricator.services.mozilla.com/D56035
--HG--
extra : moz-landing-system : lando
This is a pre-requisite for making extensions persistent, as sometimes we have
to fetch state from Gecko, so getting the extension needs to be async.
Differential Revision: https://phabricator.services.mozilla.com/D55579
--HG--
extra : moz-landing-system : lando
GeckoView will install extensions from the native UI so it doesn't have a
browser object to pass into this method.
Differential Revision: https://phabricator.services.mozilla.com/D55726
--HG--
extra : moz-landing-system : lando
Non-AddonManager extensions are invisible to GeckoView, so when a message like
"open a new tab" comes to GeckoView we will ignore them unless the extension is
properly registered.
Because of this, we need to register them in tests too.
Differential Revision: https://phabricator.services.mozilla.com/D56035
--HG--
extra : moz-landing-system : lando
This is a pre-requisite for making extensions persistent, as sometimes we have
to fetch state from Gecko, so getting the extension needs to be async.
Differential Revision: https://phabricator.services.mozilla.com/D55579
--HG--
extra : moz-landing-system : lando
GeckoView will install extensions from the native UI so it doesn't have a
browser object to pass into this method.
Differential Revision: https://phabricator.services.mozilla.com/D55726
--HG--
extra : moz-landing-system : lando
It looks like there is going to be a period of LSNG being disabled on some channels for a while.
Making the test conditional on the pref will make it pass in all situations and would allow us to keep the test enabled.
It doesn't help with the fact, that on some version we're clearing storage despite the flag not being set, but since it's clearing more, rather than less, it's at least not as critical in terms of privacy.
Differential Revision: https://phabricator.services.mozilla.com/D55526
--HG--
extra : moz-landing-system : lando
also freeze the presshell when setActive(false) is called to stop requestAnimationFrames
Differential Revision: https://phabricator.services.mozilla.com/D55343
--HG--
extra : moz-landing-system : lando
Some of these were obvious typos. Others probably reflect once-correct components
that have been combined, split, or otherwise obsoleted; for these I've tried to
use the component associated with the bugs for recent changes to the affected files.
Differential Revision: https://phabricator.services.mozilla.com/D55756
--HG--
extra : moz-landing-system : lando
Installed extensions are available after the manifest is read, so the initial
default action information could be missed by the delegate. We now just trigger
an update after a delegate has been registered to work around this.
Differential Revision: https://phabricator.services.mozilla.com/D55021
--HG--
extra : moz-landing-system : lando
This patch rolls up all the required changes for this purpose. Since the
whole crash reporting flow must understand the new format it's not possible
to land this as separate patches as individually they would be broken. This
patch includes the following changes:
* Changes to the crash reporting machinery to write out annotations as JSON,
these includes changes to the DLL blocklist code that must be run at crash
time.
* Modifications to the crash reporter client so that it can read and
submit the new format; this includes platform-specific changes to the
Breakpad libraries it uses for submitting crashes.
* Modifications to the minidump-analyzer to understand and process the new
format correctly.
* Modifications to the crash manager to understand and process the new format
correctly.
* Modifications to GeckoView's crash handler to understand and submit the
new format correctly.
* Added new tests to cover the new format and modified existing ones to
accomodate the new one.
Differential Revision: https://phabricator.services.mozilla.com/D46848
--HG--
extra : moz-landing-system : lando
ARIA role="combobox" gets a Gecko role of EDITCOMBOBOX.
However, there are two kinds of ARIA comboboxes:
1. ARIA 1.0 comboboxes are contentEditable. Text is entered into the combobox itself.
2. ARIA 1.1 comboboxes are not contentEditable. Instead, they have a textbox child into which text is entered.
On Android, traversal skipped EDITCOMBOBOX Accessibles altogether.
This meant that while 1.1 comboboxes were accessible (because we'd walk inside and land on the textbox), 1.0 comboboxes were not.
We still don't want to land on 1.1 comboboxes because the container isn't useful to the user.
Therefore, only stop on EDITCOMBOBOX Accessibles which are editable.
Differential Revision: https://phabricator.services.mozilla.com/D55224
--HG--
extra : moz-landing-system : lando
Gecko's link role is used even for <a> elements without href or onclick.
Actionable links are indicated using the linked state.
However, Android doesn't have a concept equivalent to the linked state.
Thus, on Android, we must not expose an element as a link at all if it does not have the linked state.
Differential Revision: https://phabricator.services.mozilla.com/D55207
--HG--
extra : moz-landing-system : lando
An error means that javadoc is being copied to the incorrect folder as the {project} variable is incorrectly formatted
Differential Revision: https://phabricator.services.mozilla.com/D54731
--HG--
extra : moz-landing-system : lando
Do not dispatch SELECT_ALL selection action if the input is empty or all the text is already selected.
Differential Revision: https://phabricator.services.mozilla.com/D53828
--HG--
extra : moz-landing-system : lando
Examples are currently in github. They should be kept alongside the documentation and code and built along with other projects in Android Studio.
Differential Revision: https://phabricator.services.mozilla.com/D53978
--HG--
extra : moz-landing-system : lando
To get an accurate backtrace if the run task crashes, we need the
symbols from the instrumented build.
Depends on D53716
Differential Revision: https://phabricator.services.mozilla.com/D53717
--HG--
extra : moz-landing-system : lando
Examples are currently in github. They should be kept alongside the documentation and code and built along with other projects in Android Studio.
Differential Revision: https://phabricator.services.mozilla.com/D53978
--HG--
extra : moz-landing-system : lando
On Chrome, visual viewport resize event is fired repeatedly during dynamic
toolbar transitions and visual viewport height obtained by the VisualViewport
API is also changed, but in terms of layout the height value is never used
until the dynamic toolbar height reaches to zero or is changed from zero.
The height used at the time is the height for vh units when the toolbar height
reaches to zero and the ICB height when the toolbar height is changed from zero.
To do so, we need to have another visual viewport size in parallel to the
original one and use them depending on situations.
Differential Revision: https://phabricator.services.mozilla.com/D52338
--HG--
extra : moz-landing-system : lando
The dynamic toolbar transition doesn't affect on background tabs since to
switch tabs the dynamic toolbar should be restored to its original state (i.e.,
completely visible state).
Differential Revision: https://phabricator.services.mozilla.com/D52336
--HG--
extra : moz-landing-system : lando
Do not dispatch SELECT_ALL selection action if the input is empty or all the text is already selected.
Differential Revision: https://phabricator.services.mozilla.com/D53828
--HG--
extra : moz-landing-system : lando
Slightly reorganize file structure to make copying files over easier. Needs to land in conjunction with https://github.com/mozilla/geckoview/pull/94, which should land first.
Differential Revision: https://phabricator.services.mozilla.com/D48564
--HG--
rename : mobile/android/docs/geckoview/Gemfile => mobile/android/docs/Gemfile
rename : mobile/android/docs/geckoview/_config.yml => mobile/android/docs/_config.yml
extra : moz-landing-system : lando
This matches desktop's TabTracker. Also, remove Tab:Selected which is an event
that was coming from Fennec.
Differential Revision: https://phabricator.services.mozilla.com/D52252
--HG--
extra : moz-landing-system : lando
This class allows GeckoView embedders to decode images using Gecko's image
library.
Differential Revision: https://phabricator.services.mozilla.com/D49038
--HG--
extra : moz-landing-system : lando
We're going to replace this implementation from scratch so we remove it here to
avoid a confusing diff.
Differential Revision: https://phabricator.services.mozilla.com/D51917
--HG--
extra : moz-landing-system : lando
This patch rolls up all the required changes for this purpose. Since the
whole crash reporting flow must understand the new format it's not possible
to land this as separate patches as individually they would be broken. This
patch includes the following changes:
* Changes to the crash reporting machinery to write out annotations as JSON,
these includes changes to the DLL blocklist code that must be run at crash
time.
* Modifications to the crash reporter client so that it can read and
submit the new format; this includes platform-specific changes to the
Breakpad libraries it uses for submitting crashes.
* Modifications to the minidump-analyzer to understand and process the new
format correctly.
* Modifications to the crash manager to understand and process the new format
correctly.
* Modifications to GeckoView's crash handler to understand and submit the
new format correctly.
* Added new tests to cover the new format and modified existing ones to
accomodate the new one.
Differential Revision: https://phabricator.services.mozilla.com/D46848
--HG--
extra : moz-landing-system : lando
This matches desktop's TabTracker. Also, remove Tab:Selected which is an event
that was coming from Fennec.
Differential Revision: https://phabricator.services.mozilla.com/D52252
--HG--
extra : moz-landing-system : lando
