You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ci: update remote browsers in saucelabs and browserstack (#24468)
* ci: update remote browsers in saucelabs and browserstack
Updates the remote browsers in SL and BS. We also updated
Chromium and Firefox recently through `dev-infra`.
* test: update cdk table sticky test to work with Safari v15
Updates the CDK table flex-layout sticky to work with Safari v15. The
test starts failing because the `position: sticky` does not work as
expected for the custom elements without an explicit `display`. Updating
the fixture to actually align columns in a row horizontally fixes this
and makes sense, given the name of the fixture being about flex-based table.
* fix(cdk/testing): harness click events inconsistently causing clicks on disabled elements
Currently the CDK harness implementation for `TestBed` tries to mimic user interactions,
like `click`. These helpers can then be called by harness authors or consumers.
Currently there is some inconistency across harness environments where `testElement.click()`
on disabled buttons, inputs etc. causes `click` events to be still emitted in `TestBed` for
Chromium-based browsers, while this is not the case for `TestBed` in `Firefox` and `Safari`,
neither in e2e-based clicks (like protractor or webdriver).
This seems to be inconsistency caused by browsers in the ecosystem. There are bug reports
in Firefox where they explicitly kept emitting `click` when explicitly dispatched programmatically
(seems reasonable to me). Chromium has a bug report where users complain about events being
prevented, even though dispatched programmatically.
https://bugzilla.mozilla.org/show_bug.cgi?id=329509.
https://bugs.chromium.org/p/chromium/issues/detail?id=1115661
In either way though, we should make this consistent with an actual user interaction (like with e2e environments)
and just skip the click event when the underlying element is disabled (we assume the `disabled` property is a sufficient
indicator for this). Note that the mousedown, mouseup event sequence continues to be emulated/synthesized.
* test: use `document.activeElement` instead of pseudo `:focus` query search
Some tests seem to use `:focus` instead of `document.activeElement` for test
assertions. This seems to work unreliably in Safari as sometimes the `:focus`
query returns `null`, unless `document.activeElement` is requested before (which
seems to indicate that `document.activeElement` does something under-the-hood
to determine the active element, while `querySelector(':focus')` does not have this.
The details on why `activeElement` is better in our case are a little hypothetical
but doesn't seem worth investigating a lot since in all other places in the repo
we haven't used this pattern for checking the active document element.
0 commit comments