bug(cdk/testing): harnesses treat tabs different depending on test environment

[e-hein]

Reproduction

https://travis-ci.org/github/e-hein/test-tabkey/branches

• without tab everything works as expected: last-working-sample-without-tab
  (build log|stackblitz)

• using tab will lead to different behavior: broken-by-using-the-tab-key
  (build log|changes|stackblitz)

• workaround: workaround-with-emulate-tab
  (build log|changes|stackblitz)

Expected Behavior

If I can switch from karma/jest to protractor I'd expect the same harness test to lead to the same results. In this case, I'd expected that senden TestKey.Tab to an TestElement it should select the next selectable element (or at least try to do so in the most common cases).

Alternative Behavior

Sending TestKey.Tab writes a \t into an input field in both environments.

Actual Behavior

• Sending TestKey.Tab in ProtractorEnvironment selects the next input (=expected Behavior)
• Sending TestKey.Tab in TestbedEnvironment does nothing (not even write \t)

Environment

• Angular: 9.1.9
• CDK/Material: cdk 9.2.4, material 9.2.4
• Browser(s): Chrome, Firefox
• Operating System (e.g. Windows, macOS, Ubuntu):
  Angular CLI: 9.1.9
  Node: 12.18.0
  OS: darwin x64 / Linux

[e-hein]

additional information:

the story behind

I'm developing an app using angular/material that is for professionals and needs to be controllable by keyboard only users. So I have to ensure it's controls does properly react on keyboard entries (including the tab key) as soon as possible.

bug or feature

I'd call it a feature but different behavior in different environments of a wrapper that should work in both environments - that's a bug for me, sry.

involvement

I've got some free resources until the end of the month (next week). So if we could find a definition how it should work soon, I'd be able to support implementing this.

[crisbeto]

The problem is that Protractor sends out an actual tab key press, whereas for TestBed we simulate one which invokes the proper event listeners, but it won't trigger the native browser action of moving focus forward. This may be tricky to solve, because the browser doesn't have an API to move focus forward programmatically.

[e-hein]

Yes, in fact it is tricky and after investigating 3 days I didn't find a library which tried to solve this nor I'm sure if all browsers do exactly the same things on tab keypress (e.g. select existing text in a target input). I think the question is, if an 80% solution would be better than the actual 5% solution or if it's better letting tests fail fast so users write other test instead of relying on the 80% ...
For me the 80% solution (see workaround) works much better and I can test the behavior earlier. So I think it's worth to try - what do you think?

[mmalerba]

Unfortunately, I think this is just one of those cases where it would be too hard to get the same behavior in both environments. We do make a note of this in the harness docs:

Please note that harnesses may not behave exactly the same in all environments. There will always be some difference between the real browser-generated event sequence when a user clicks or types in an element, versus the simulated event sequence generated in unit tests. Instead, the CDK makes a best effort to normalize the behavior and simulate the most important events in the sequence.

[mmalerba]

Oh sorry @e-hein I just noticed that you started working on a PR for this. I'd be willing to take a look at what you come up with and see if its something we want to add. Please add me as a reviewer when you're ready

[e-hein]

Thanks for reopening :-)

Current status:
I already had my workaround before I opened the bug and this workaround would work much better, if it's placed in the unit-test-element itself. Then I realized, that emulating tab can't be the first step. So my steps were:

1. Pay attention to selections and cursor position when inserting keys into an input (commit)
2. Share and align tests between protractor e2e env and testbed unit test env to get an overview what's equal and where are differences (commit).
   -> result: the behavior is already really close! 👍
3. Integrate tab emulation (topic of the issue) into fake-events/type-in-element (commit)

Now I learned much about the internals of cdk/testing (and the bazel build environment) and have a working solution - but it got "a bit larger" than I thought. I think I have to review it myself first, rebase on head and do some linting/clean-ups. I think I will open a PR tomorrow (it's short past midnight, here) and if you do not like it at all - I still have my workaround.

[e-hein]

Do you think I should split it into 3-4 PRs? (alignment of tests, sharing tests between environments, emulate text selection + backspace, emulate tab)