Fix modal focus trap with additional elements and arrow navigation

[ShGKme]

☑️ Resolves

• Fix [BITV]: Not possible to navigate the tabs in sidebar nextcloud/server#39415

Two problems with focus trap break navigation with modal.

Problem 1: When Viewer is opened with sidebar, focus on the sidebar is not possible
Source: additionalTrapElements are not used on init but only on change.

Problem 2: NcModal intercept arrow navigation for slider (next/prev)

🖼️ Screenshots

🏚️ Before

before-1.mp4

before-2.mp4

🏡 After

after.mp4

🚧 Tasks

• Also use additionalTrapElements on init
• On keyboard navigation handler check if there is an active element.
  • If there is an element and it's outside the modal, then it is
    • either element from additionalTrapElements
    • or some pop over element like emoji picker or nc actions that also have its own navigation
  • Alternative solution: always disable arrow navigation if there is an active element

🏁 Checklist

• ⛑️ Tests are included or are not applicable
• 📘 Component documentation has been extended, updated or is not applicable

[ShGKme]

There is one more problem: when the next or prev slide is a video, then tab navigation goes to visually hidden video controls. But this should be fixed in Viewer (I'll make a PR later)

[ShGKme]

PR is updated.

Only arrow navigation ignores elements outside (which is the problem in mentioned issue), while ESC still closes the modal as it was before, regardless of focus.

It is a problem for elements that uses ESC itself. For example, closing NcSelect by ESC. But I think, it's better to fix it on such components sides (with stop propagation of ESC keydown). Otherwise even focus on sidebar element after click prevents closing Viewer by ESC.

[Pytal]

Suggested change

	// Esc can be used without stop in content or additionalTrapElements where it should not deacxtivate modal's focus trap.
	// Focus trap is deactivated on modal close anyway.
	escapeDeactivates: false,

Not used anymore?

[ShGKme]

Hmm... I'm not sure if it is required, I need to re-check.

But disabling escapeDeactivates is definitely safe:

• If a modal is closed by ESC, trap is deactivated anyway
• If a modal is not closed by ESC, the focus trap should also not be deactivated.