feat(cdk/focus-trap) Add ConfigurableFocusTrap classes

[vanessanschmitt]

ConfigurableFocusTrap is part of a new FocusTrap design that will trap more
than just tab focus.

This commit sets up the classes for the new design, and implements the primary
strategy for preventing focus outside the trap (an event listener that
refocuses the trap). Logic to trap screen reader focus and wrap tab
without the hidden tab stops will be in future commits. Migration of
cdkTrapFocus, MatDialog, etc. will also be in future commits.

This commit does not enable ConfigurableFocusTrap anywhere.

[vanessanschmitt]

@stevenyxu Could you take a look as well?

[jelbourn]

I'm going to re-target this PR onto a branch called focus-trap-v2 so we can get everything in before merging it into master

[vanessanschmitt]

Relates to #13054

[crisbeto]

Closest isn't supported in some browsers.

[vanessanschmitt]

Yeah, I saw I failed some browser tests for that reason. I copied the polyfill from here: https://github.com/angular/components/blob/master/src/cdk-experimental/popover-edit/polyfill.ts

into my own polyfill.ts file. Is that okay, or should I move the popover-edit polyfill code somewhere it can be shared?

[vanessanschmitt]

I'm going to re-target this PR onto a branch called focus-trap-v2 so we can get everything in before merging it into master

The next commit I was planning was to migrate MatDialog to use ConfigurableFocusTrap. I created cl/289706346 (internal to Google) to try running all the presubmits, and they look pretty good. Should I do things in a different order?

These were the four ConfigurableFocusTrap implementation commits I was planning:

1. Implement FocusTrapManager and EventListenerFocusTrapInertStrategy.
2. Update logic to find and cache first/last focusable elements, add document Tab event listener, and remove hidden tab stops.
3. Implement AriaHiddenScreenReaderStrategy.
4. Implement DisabledFocusTrapInertStrategy.

I was going to migrate MatDialog (and hopefully cdkTrapFocus, pending what we decide to do about directly referencing EventListenerFocusTrapInertStrategy) after commit 1. Mainly because it fixes a known issue with MatDialog (#13054), which isn't dependent on commits 2-4.

Commit 2 shouldn't be too much code, so we could also migrate after that one. Commit 3 is more code, and MatDialog won't be using that strategy anyways for the time being, because it already has its own logic to apply aria-hidden. Commit 4 is still pending more investigation as to whether it's worth the work of implementing, given the expected bad performance.

What do you think would be a good point to merge into master?

[jelbourn]

Ah, I didn't know you were planning to work on dialog right after this. In that case we can retarget this for master. My thinking was that we would want to have the other strategies done before releasing this publically, and developing on a branch would remove any time pressure; I'm not super worried about it, though, since master is targeting 9.1 and we still haven't finalized 9.0 yet, so there's should be plenty of time.

[jelbourn]

LGTM

I'll run this through TGP tonight

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}