-
Notifications
You must be signed in to change notification settings - Fork 6.8k
build: update firefox to latest version #20014
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
build: update firefox to latest version #20014
Conversation
Updates our Firefox version that is used for Bazel unit tests to v78.0. Previously we were using v68. To update the Firefox version, we had to set up a custom Browser target with repositories as the version for Firefox is usually hard-coded in `rules_webtesting` and we cannot control that. See related change in the dev-infra package: angular/angular#38029.
…ations A small set of popover-edit tests relies on the bounding client rect. Assertions that the panel stretches over the first and last cell are correct but require an exact equality. This is not reliable as in some situations, browsers handle subpixels differently, resulting in small deviations in the bounding client rect positions. These differences are only noticeable less significant decimal places, but the overall assertion matches full pixels. This is sufficient for these tests so we just round all measurements/comparisons to full pixels.
5bd2f61
to
8922d45
Compare
@@ -564,6 +564,10 @@ matPopoverEditTabOut`, fakeAsync(() => { | |||
}); | |||
|
|||
describe('edit lens', () => { | |||
function expectPixelsToEqual(actual: number, expected: number) { | |||
expect(Math.round(actual)).toBe(Math.round(expected)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Usually I do Math.floor
or Math.ceil
for assertions like this, because with round you could get a mismatch for 1.4
vs 1.6
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that is tricky. I checked and saw lots of Math.round
assertions in our code base. We don't seem to do it consistently. One benefit of round will be that we potentially spot one-off issues easier (as the browser potentially will round the pixels depending). I'll switch it to Math.floor
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
The datepicker position tests seem to be thrown off in Firefox v78 where inputs have an uneven width (resulting in subpixel rendering that is not predictable and stable enough for our test assertions)
8922d45
to
2753c01
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Updates our Firefox version that is used for Bazel unit tests to v78.0.
Previously we were using v68.
To update the Firefox version, we had to set up a custom Browser target
with repositories as the version for Firefox is usually hard-coded in
rules_webtesting
and we cannot control that.See related change in the dev-infra package: angular/angular#38029.
This is an addition to: #19961