Skip to content
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

[fixed] Focus trap when reentering document (#742) #791

Merged
merged 9 commits into from
Dec 9, 2019
Merged

[fixed] Focus trap when reentering document (#742) #791

merged 9 commits into from
Dec 9, 2019

Conversation

holloway
Copy link
Contributor

@holloway holloway commented Dec 6, 2019

Fixes #742

Changes proposed:

Upgrade Path (for changed or removed APIs):

  • N/A

Acceptance Checklist:

  • The commit message follows the guidelines in CONTRIBUTING.md.
  • [ ] Documentation (README.md) and examples have been updated as needed. N/A I think
  • If this is a code change, a spec testing the functionality has been added.
  • [ ] If the commit message has [changed] or [removed], there is an upgrade path above. N/A I think

@diasbruno
Copy link
Collaborator

Legit. @holloway Have you found what broke the tests?

@diasbruno
Copy link
Collaborator

@holloway Ping me if you need anything...not sure if I'm receiving the notifications from this repo or if I'm skipping without looking... :)

@coveralls
Copy link

coveralls commented Dec 8, 2019

Coverage Status

Coverage increased (+0.8%) to 87.135% when pulling 30b406e on springload:fix/modal-body-focus into 98dd5be on reactjs:master.

@holloway
Copy link
Contributor Author

holloway commented Dec 8, 2019

@diasbruno Yeah the test bug was caused by making those trap elements in componentDidMount rather than the constructor (or, presumably, willMount).

So that's passing now.

import portalOpenInstances from "./portalOpenInstances";
// Body focus trap see Issue #742

let before, after, instances;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ýou can initialize instances with an empty array.

src/helpers/bodyTrap.js Show resolved Hide resolved
src/helpers/portalOpenInstances.js Show resolved Hide resolved
@diasbruno diasbruno merged commit eb20444 into reactjs:master Dec 9, 2019
@diasbruno
Copy link
Collaborator

Thanks, @holloway. I merged your PR and will run a few tests on it.
Don't let me forget to make a release. :)

@diasbruno
Copy link
Collaborator

diasbruno commented Dec 9, 2019

@holloway When the page gets the focus back - testing on firefox -, I'm seen that I need "a extra tab" because <html> is getting the focus. Is this the correct behavior or a difference between browsers?

@holloway
Copy link
Contributor Author

holloway commented Dec 10, 2019

@diasbruno hmm... I can't reproduce that behaviour in Firefox v71 (Linux), and I haven't heard of Firefox overriding JS-controlled focus in that way. What are the exact reproduction steps? For me, in Firefox and in Chrome, it restores focus to the button that it opened from. But you're seeing a change in behaviour compared to the ReactCommunity Codepen examples?

fyi I have tested focus management by running this to log the current element every second,

setInterval(function(){ console.log(document.activeElement); }, 1000);

And then interacting with the page to see how focus is moved around, and that part (when the page gets focus back) seems to behave as it was before this PR.

@diasbruno
Copy link
Collaborator

diasbruno commented Dec 10, 2019

Thats look correct. Maybe this happens when I click on the browser's console and type document.activeElement.

Steps

  • Open modal
  • Click on the browser's address
  • Tab until it reaches the page view
  • Go to browser's console and type document.activeElement (maybe this is why I'm getting the <html>)

@diasbruno
Copy link
Collaborator

Firefox 71 here.

@holloway
Copy link
Contributor Author

Ah then yes that might move focus to <html>. The trap elements are in <body> so if the focus is on <html>, before the trap, then they haven't walked into the focus trap yet.

There's a legitimate question about whether focusing <html> should move focus to the modal. I'm not sure of the answer to that, but I'll ask around with some accessibility experts that I know. If so, that would need a different approach than these trap elements, however in my testing it's basically harmless to allow <html> to be focused as the other content under the modal is still bypassed.

I guess the idea of using a setInterval was to poll the activeElement without needing to interact with the console which might change the activeElement and trigger a window blur event and react-modal changes (ie, I see focusManager.js responds to window blur).

@diasbruno
Copy link
Collaborator

LGTM. When we get more info about this, we can do something about this.

@holloway
Copy link
Contributor Author

@diasbruno fyi I'm told that the extra tab in Firefox is expected behaviour that we wouldn't want to interfere with when a modal is open. FF users are in the habit of hitting tab twice, so this PRs' approach is still appropriate.

(@jasonkiss)

@holloway
Copy link
Contributor Author

@diasbruno

Don't let me forget to make a release. :)

bump! 😄

@diasbruno
Copy link
Collaborator

🤦‍♂️

Thanks, @holloway.
I'll make a release today.

@diasbruno
Copy link
Collaborator

Release 3.11.2.

@holloway
Copy link
Contributor Author

No probs, thanks @diasbruno !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Modal doesn't trap focus when re-entering document
3 participants