LTO was enabled on Android back when the normal Android builds were the
ones we shipped. But now we have separate builds for what is shipped,
*and* they do PGO+LTO.
Differential Revision: https://phabricator.services.mozilla.com/D62872
--HG--
extra : moz-landing-system : lando
This allows `performAction` to immediately return false if a boundary is
reached and allow TalkBack to navigate past the web view.
Change viewport cache listener to reorder since it should catch all tree
mutations in the document.
Differential Revision: https://phabricator.services.mozilla.com/D63117
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
At bug 1614208, the line style value mapping was changed, but
`GeckoEditable.IME_RANGE_LINE_*` are not updated.
This patch makes the style in `TextRangeStyle` an enum class for making it
type safer, and updates `GeckoEditable.IME_RANGE_LINE_*`, and finally, adds
`FYI` comments in `TextRangeStyle` to make developers realize it requires
manual update.
Differential Revision: https://phabricator.services.mozilla.com/D62883
--HG--
extra : moz-landing-system : lando
`inputConnection` works again even if x86_64 emulator with e10s.
But the following tests still have timing issue and are sometimes failure.
So this is still turned off.
- `inputConnection_bug1133802`
- `inputConnection_setSelection`
Differential Revision: https://phabricator.services.mozilla.com/D61291
--HG--
extra : moz-landing-system : lando
So that the test can receive the expected event triggered by the
setVerticalClipping.
Differential Revision: https://phabricator.services.mozilla.com/D62868
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
Currently the sections regarding mma events and deeplinks are not properly
formatted making the text hard to read, follow and understand.
Use the `.. code-block:: json` formatting for Events. Found this in the history
for the previous documentation from central
Add a newline before the deep links bullet list so that each element would be
properly formatted.
Before and after screenshots of the docs are posted in the ticket.
Depends on D62730
Differential Revision: https://phabricator.services.mozilla.com/D62731
--HG--
extra : moz-landing-system : lando
Now that we don't rely on XPCOM accessibility anymore we shouldn't see
intermittents with accessibility on.
Differential Revision: https://phabricator.services.mozilla.com/D61773
--HG--
extra : moz-landing-system : lando
Wires up the addon manager update process to the GekcoView API. Adds
several basic tests for verifying the udpate steps. Adds a new way to
automatically bundle new test addons into xpi files and registers them
with the example.com server.
Differential Revision: https://phabricator.services.mozilla.com/D61501
--HG--
extra : moz-landing-system : lando
Chrome prunes the subtrees of links and headings (with single text leaf
children) and we mimic this in Gecko. The problem is that sometimes a
heading can be a child of a link, and it would be impossible to reach
when navigating by headings.
The main reason we mimiced chrome is because we would getthe name of the
node and its subtree uttered, so you would hear the name of the node
twice. By using contentDescription we can suppress the subtree from
TalkBack's utterance and preserve the node's children for heading
navigation.
Differential Revision: https://phabricator.services.mozilla.com/D61766
--HG--
extra : moz-landing-system : lando
The fundamental issue here is that `ParentCrashTest` starts a second
`GeckoRuntime` via `RemoteGeckoService` within the same logical Android
Application.
This patch adds `RuntimeCreator.shutdownRuntime()` so that the test can
shut down the existing `GeckoRuntime` before starting up its own.
Differential Revision: https://phabricator.services.mozilla.com/D61249
--HG--
extra : moz-landing-system : lando
These values are not available right away after `onInstallEnded`, but are available after `Management.on("ready")` for the addon. We prefer not complicating the
situation for GV embedders, and instead only resolving the `installExtension` once the addon is ready.
Differential Revision: https://phabricator.services.mozilla.com/D61281
--HG--
extra : moz-landing-system : lando
It's possible that UpdateDynamicTollbarOffset is called repeatedly before we
actually fire a window resize event.
Differential Revision: https://phabricator.services.mozilla.com/D60812
--HG--
extra : moz-landing-system : lando
Blocking here causes a problem on startup with the socket server, and
apps don't do this anyway.
Differential Revision: https://phabricator.services.mozilla.com/D60973
--HG--
extra : moz-landing-system : lando
The prompts are annoying and are also making it hard to use GVE
in performance tests.
Differential Revision: https://phabricator.services.mozilla.com/D60851
--HG--
extra : moz-landing-system : lando
This patch is doing two things.
1. Make GeckoView directly gets the ContentBlockingLog in the parent
process when it gets the bundle event 'ContentBlocking:RequestLog'. It
will get the top-level browsingContext and get the log from the
WindowGlobal of this browsingContext.
2. Remove the GeckoViewContentBlockingChild. The child module of
ContentBlocking is no longer needed since it serves nothing after we move
the functionality of getting log to the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D57464
--HG--
extra : moz-landing-system : lando
This causes us to automatically deny the `desktop-notification`
permission if there is no user interaction, like desktop Firefox. This is
not enforced if the `dom.webnotifications.requireuserinteraction`
preference is set to `false`
Differential Revision: https://phabricator.services.mozilla.com/D60758
--HG--
extra : moz-landing-system : lando
This patch does not change any of the *internals* of process management in
`GeckoProcessManager`, however it upgrades the interface in preparation for
such changes.
* We add a java equivalent to Gecko's `GeckoProcessType` enumeration;
* We add the `GeckoProcessType.Selector` class which will be used for
identifying running content processes;
* We update `ContentParent::MarkAsDead` to use `GeckoProcessType.Selector` for
indicating which process should be marked.
Differential Revision: https://phabricator.services.mozilla.com/D60539
--HG--
extra : moz-landing-system : lando
This causes us to automatically deny the `desktop-notification`
permission if there is no user interaction, like desktop Firefox. This is
not enforced if the `dom.webnotifications.requireuserinteraction`
preference is set to `false`
Differential Revision: https://phabricator.services.mozilla.com/D60758
--HG--
extra : moz-landing-system : lando
This causes us to automatically deny the `desktop-notification`
permission if there is no user interaction, like desktop Firefox. This is
not enforced if the `dom.webnotifications.requireuserinteraction`
preference is set to `false`
Differential Revision: https://phabricator.services.mozilla.com/D60758
--HG--
extra : moz-landing-system : lando
This also fixes the tests, and adds a utility method for waiting one
round trip between the UI and Gecko thread.
Differential Revision: https://phabricator.services.mozilla.com/D60724
--HG--
extra : moz-landing-system : lando
1) Adds a basic functionality test.
2) Adds a tests to ensure storage is shared across private mode sessions.
Differential Revision: https://phabricator.services.mozilla.com/D60546
--HG--
extra : moz-landing-system : lando
Private browsing data kept getting cleared each time a new tab was created
since gecko thought there were no more private windows. Also, fixes a typo
in the case of "windowtype".
Differential Revision: https://phabricator.services.mozilla.com/D60330
--HG--
extra : moz-landing-system : lando
1) Adds a basic functionality test.
2) Adds a tests to ensure storage is shared across private mode sessions.
Depends on D60330
Differential Revision: https://phabricator.services.mozilla.com/D60546
--HG--
extra : moz-landing-system : lando
Private browsing data kept getting cleared each time a new tab was created
since gecko thought there were no more private windows. Also, fixes a typo
in the case of "windowtype".
Differential Revision: https://phabricator.services.mozilla.com/D60330
--HG--
extra : moz-landing-system : lando
This patch is doing two things.
1. Make GeckoView directly gets the ContentBlockingLog in the parent
process when it gets the bundle event 'ContentBlocking:RequestLog'. It
will get the top-level browsingContext and get the log from the
WindowGlobal of this browsingContext.
2. Remove the GeckoViewContentBlockingChild. The child module of
ContentBlocking is no longer needed since it serves nothing after we move
the functionality of getting log to the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D57464
--HG--
extra : moz-landing-system : lando
`viewport-fit` is hint that browser application can use cutout area. So we should expose it to GeckoView application to set `layoutInDisplayCutoutMode`.
When meta element is found or changed, `ContentDelegate.onMetaviewportFitChange` is called. Even if nothing, it will be called after DOMContentLoaded is fired.
Depends on D57398
Differential Revision: https://phabricator.services.mozilla.com/D55610
--HG--
extra : moz-landing-system : lando
We need to propagate `ContentParent::MarkAsDead` up to the Android java layer
so that it has a view of the state of content processes that is consistent
with the view of Gecko's content process management.
Differential Revision: https://phabricator.services.mozilla.com/D58564
--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
This patch adds a new menu item to GVE that allows users to install an
arbitrary extension given it's URL (usually from a.m.o, but we don't really
verify that).
Differential Revision: https://phabricator.services.mozilla.com/D59973
--HG--
extra : moz-landing-system : lando
Legacy extensions are no longer loaded, so we can drop the build config for it. We
still need flags for handling experimental APIs since what we require differs between builds
and distributions.
Differential Revision: https://phabricator.services.mozilla.com/D57413
--HG--
extra : moz-landing-system : lando
This is covered in other test suites, but it may be possible for
GeckoView to get this wrong, so add an explicit test.
Differential Revision: https://phabricator.services.mozilla.com/D59935
--HG--
extra : moz-landing-system : lando
Instead, subclass nsTextControlFrame. This simplifies the code and avoids
correctness issues.
I kept the localization functionality though it is not spec compliant. But I
filed a bug to remove it in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D57193
--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 don't need to package tests for builds that we don't actually run
tests from, but it is tricky to align this correctly by setting
MOZ_AUTOMATION_PACKAGE_TESTS=0 in relevant mozconfigs. Instead we can
set the environment variable in the task definition, and use a full
taskgraph verification check to ensure that the flag is only set on
builds that have tests.
The one tricky task is win64-aarch64-shippable/opt, which copies tests
from another build rather than building them itself. For this reason, it
explicitly sets MOZ_AUTOMATION_PACKAGE_TESTS: '0' in the environment
even though that is now the default. This is why the exception is only
raised if MOZ_AUTOMATION_PACKAGE_TESTS is not set at all, rather than
checking that it is set to 1.
Differential Revision: https://phabricator.services.mozilla.com/D59426
--HG--
extra : moz-landing-system : lando
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
