We are working on [enabling Tier 2 a11y-checks to ensure our products have basic accessibility built-in (bug 1692110)](https://bugzilla.mozilla.org/show_bug.cgi?id=1692110) and before that, we need to prepare the existing code base. While we triage and investigate existent tests that would fail once the a11y-checks are enabled in the CI, we are going to skip the failing tests altogether and then handle each one of them individually.
This task is to skip with `fail-if` condition of the failing tests while we continue investigation into the reasons these tests failed and to be able to backtrack these tests once they're resolved.
Related bugs:
- Disabling tests: meta bug 1848402
- Investigation and remediation for components with disabled tests: meta bugs 1848394 and 1854227, component-specific bug 1854515
- Explore capturing click events for a11y_checks: bug 1692110
Differential Revision: https://phabricator.services.mozilla.com/D188918
We are working on [enabling Tier 2 a11y-checks to ensure our products have basic accessibility built-in (bug 1692110)](https://bugzilla.mozilla.org/show_bug.cgi?id=1692110) and before that, we need to prepare the existing code base. While we triage and investigate existent tests that would fail once the a11y-checks are enabled in the CI, we are going to skip the failing tests altogether and then handle each one of them individually.
This task is to skip with `fail-if` condition of the failing tests while we continue investigation into the reasons these tests failed and to be able to backtrack these tests once they're resolved.
Related bugs:
- Disabling tests: meta bug 1848402
- Investigation and remediation for components with disabled tests: meta bugs 1848394 and 1854227, component-specific meta bug 1854513
- Explore capturing click events for a11y_checks: bug 1692110
Differential Revision: https://phabricator.services.mozilla.com/D188917
We are working on [enabling Tier 2 a11y-checks to ensure our products have basic accessibility built-in (bug 1692110)](https://bugzilla.mozilla.org/show_bug.cgi?id=1692110) and before that, we need to prepare the existing code base. While we triage and investigate existent tests that would fail once the a11y-checks are enabled in the CI, we are going to skip the failing tests altogether and then handle each one of them individually.
This task is to skip with `fail-if` condition of the failing tests while we continue investigation into the reasons these tests failed and to be able to backtrack these tests once they're resolved.
Related bugs:
- Disabling tests: meta bug 1848402
- Investigation and remediation for components with disabled tests: meta bugs 1848394 and 1854227, Core: Credentials-specific bug 1854510
- Explore capturing click events for a11y_checks: bug 1692110
Differential Revision: https://phabricator.services.mozilla.com/D188916
We are working on [enabling Tier 2 a11y-checks to ensure our products have basic accessibility built-in (bug 1692110)](https://bugzilla.mozilla.org/show_bug.cgi?id=1692110) and before that, we need to prepare the existing code base. While we triage and investigate existent tests that would fail once the a11y-checks are enabled in the CI, we are going to skip the failing tests altogether and then handle each one of them individually.
This task is to skip with `fail-if` condition of the failing tests while we continue investigation into the reasons these tests failed and to be able to backtrack these tests once they're resolved.
Related bugs:
- Disabling tests: meta bug 1848402
- Investigation and remediation for components with disabled tests: meta bugs 1848394 and 1854227, Tabbed Browser-specific meta bug 1854507
- Explore capturing click events for a11y_checks: bug 1692110
Differential Revision: https://phabricator.services.mozilla.com/D188915
We are working on [enabling Tier 2 a11y-checks to ensure our products have basic accessibility built-in (bug 1692110)](https://bugzilla.mozilla.org/show_bug.cgi?id=1692110) and before that, we need to prepare the existing code base. While we triage and investigate existent tests that would fail once the a11y-checks are enabled in the CI, we are going to skip the failing tests altogether and then handle each one of them individually.
This task is to skip with `fail-if` condition of the failing tests while we continue investigation into the reasons these tests failed and to be able to backtrack these tests once they're resolved.
Related bugs:
- Disabling tests: meta bug 1848402
- Investigation and remediation for components with disabled tests: meta bugs 1848394 and 1854227, Core: Event Handling-specific meta bug 1854503
- Explore capturing click events for a11y_checks: bug 1692110
Differential Revision: https://phabricator.services.mozilla.com/D188914
We are working on [enabling Tier 2 a11y-checks to ensure our products have basic accessibility built-in (bug 1692110)](https://bugzilla.mozilla.org/show_bug.cgi?id=1692110) and before that, we need to prepare the existing code base. While we triage and investigate existent tests that would fail once the a11y-checks are enabled in the CI, we are going to skip the failing tests altogether and then handle each one of them individually.
This task is to skip with `fail-if` condition of the failing tests while we continue investigation into the reasons these tests failed and to be able to backtrack these tests once they're resolved.
Related bugs:
- Disabling tests: meta bug 1848402
- Investigation and remediation for components with disabled tests: meta bugs 1848394 and 1854227, Webextensions-sepecific meta bug 1854461
- Explore capturing click events for a11y_checks: bug 1692110
Differential Revision: https://phabricator.services.mozilla.com/D188913
We are working on [enabling Tier 2 a11y-checks to ensure our products have basic accessibility built-in (bug 1692110)](https://bugzilla.mozilla.org/show_bug.cgi?id=1692110) and before that, we need to prepare the existing code base. While we triage and investigate existent tests that would fail once the a11y-checks are enabled in the CI, we are going to skip the failing tests altogether and then handle each one of them individually.
This task is to skip with `fail-if` condition of the failing tests while we continue investigation into the reasons these tests failed and to be able to backtrack these tests once they're resolved.
Related bugs:
- Disabling tests: meta bug 1848402
- Investigation and remediation for components with disabled tests: meta bugs 1848394 and 1854227, Password Manager-specific meta bug 1854454
- Explore capturing click events for a11y_checks: bug 1692110
Differential Revision: https://phabricator.services.mozilla.com/D188912
We are working on [enabling Tier 2 a11y-checks to ensure our products have basic accessibility built-in (bug 1692110)](https://bugzilla.mozilla.org/show_bug.cgi?id=1692110) and before that, we need to prepare the existing code base. While we triage and investigate existent tests that would fail once the a11y-checks are enabled in the CI, we are going to skip the failing tests altogether and then handle each one of them individually.
This task is to skip with `fail-if` condition of the failing tests while we continue investigation into the reasons these tests failed and to be able to backtrack these tests once they're resolved.
Related bugs:
- Disabling tests: meta bug 1848402
- Investigation and remediation for components with disabled tests: meta bugs 1848394 and 1854227, component-specific meta bug 1854448
- Explore capturing click events for a11y_checks: bug 1692110
Differential Revision: https://phabricator.services.mozilla.com/D188911
We are working on [enabling Tier 2 a11y-checks to ensure our products have basic accessibility built-in (bug 1692110)](https://bugzilla.mozilla.org/show_bug.cgi?id=1692110) and before that, we need to prepare the existing code base. While we triage and investigate existent tests that would fail once the a11y-checks are enabled in the CI, we are going to skip the failing tests altogether and then handle each one of them individually.
This task is to skip with `fail-if` condition of the failing tests while we continue investigation into the reasons these tests failed and to be able to backtrack these tests once they're resolved.
Related bugs:
- Disabling tests: meta bug 1848402
- Investigation and remediation for components with disabled tests: meta bugs 1848394 and 1854227, component-specific meta bug 1854444
- Explore capturing click events for a11y_checks: bug 1692110
Differential Revision: https://phabricator.services.mozilla.com/D188910
We are working on [enabling Tier 2 a11y-checks to ensure our products have basic accessibility built-in (bug 1692110)](https://bugzilla.mozilla.org/show_bug.cgi?id=1692110) and before that, we need to prepare the existing code base. While we triage and investigate existent tests that would fail once the a11y-checks are enabled in the CI, we are going to skip the failing tests altogether and then handle each one of them individually.
This task is to skip with `fail-if` condition of the failing tests while we continue investigation into the reasons these tests failed and to be able to backtrack these tests once they're resolved. A separate task to investigate the failed Tier 2 a11y_checks will be filed for an appropriate component.
Related bugs:
- Disabling tests: meta bug 1848402
- Investigation and remediation for components with disabled tests: meta bugs 1848394 and 1854227, Desktop UI bug 1854233
- Explore capturing click events for a11y_checks: bug 1692110
Differential Revision: https://phabricator.services.mozilla.com/D188909
Drag/drop generates click events, but these aren't actually a click event intended to activate a control.
Therefore, we don't want to run accessibility checks for the target.
To achieve this, EventUtils.synthesizeDropAfterDragOver instructs AccessibilityUtils to ignore click events while the event is being sent.
This requires that EventUtils has the reference to AccessibilityUtils set by the browser test harness.
As such, some tests had to be adjusted so that they use EventUtils from the browser test scope, rather than loading their own copy of EventUtils.
Differential Revision: https://phabricator.services.mozilla.com/D185776
These failures occur in common, reusable widgets, so it doesn't make sense to make exceptions in individual tests.
See the code comments for explanations of each case.
Differential Revision: https://phabricator.services.mozilla.com/D190004
Previously, we ran a11y checks in EventUtils.sendMouseEvent.
Unfortunately, many tests don't use this, instead using some other method of clicking.
This meant that a11y checks lacked a lot of coverage.
Rather than trying to adjust all existing tests to use sendMouseEvent and trying to maintain this somehow for future tests, we instead capture click events and run a11y checks then.
Differential Revision: https://phabricator.services.mozilla.com/D118126
Update the output during a Lando-try push to indicate the contents more clearly.
Indicate when the push will only include the try config commit, and use better
phrasing when the stack is just 1 commit and the try config commit.
Differential Revision: https://phabricator.services.mozilla.com/D190219
The token verification code path checks the ID token is valid and not expired,
however the ID token and the access token have different expirations, causing
pushes to be rejected by Lando after local verification succeeds. Since
`auth0-python` doesn't provide an access token verification, we decode the
access token and manually verify the token is not about to expire.
Differential Revision: https://phabricator.services.mozilla.com/D190296
Calling ClientWebGLContext::UniformData() many times causes the
command buffer to fill up and we spend a fair amount of time flushing
the old buffer and allocating a new one, as well as serializing the
values.
The uniforms themselves are very small but they add up over a large
number of calls. We already have some code to track whether the
uniform values are dirty to avoid some redundancy, but a) this doesn't
cover every uniform, and b) we invalidate them all when switching
program.
This patch makes us track the value of every uniform that gets set
dynamically, and tracks the values separately for each program
used. It then uses these to avoid calling UniformData redundantly.
Differential Revision: https://phabricator.services.mozilla.com/D190269
Right now we were relying on the OS colors
(-moz-dialog/-moz-dialogtext/ActiveCaption/CaptionText).
The titlebar ones did the right thing but -moz-dialog and co didn't.
This caused two issues:
* With the titlebar checkbox on, we'd use the system colors even
without prefers-contrast. This is specially noticeable on macOS.
* With prefers-contrast. We used -moz-dialog for the background and the
toolbar on macOS. This caused little contrast.
Support the -moz-headerbar colors in all desktop platforms, and use
those on Linux + HCM, and use browser-custom-colors on Windows / macOS
to override the toolbox background explicitly to fix it.
This setup is a little bit more consistent with all other colors.
Differential Revision: https://phabricator.services.mozilla.com/D190200
For initial about:blank, nsSubDocumentFrame::Init might not have an
extant browsing context yet. Some code did deal with that properly
(MaybeUpdateEmbeddedColorScheme for example), but some other didn't.
Consistently propagate data to our browsing context after ShowViewer to
fix this.
Differential Revision: https://phabricator.services.mozilla.com/D190275
