-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
The previous focus change that was applied to dialog close has unexpected behavior for non-modal dialogs #8904
Comments
Yeah I agree, this is annoying. I think for non-modal dialog case, the previous focused element should be |
The inputs in the jsfiddle aren't descendants of the dialog though are they? |
Yeah, so the previous focused element should be the left input which is |
Fixes whatwg#8904 This patch prevents the behavior where closing a dialog focuses the previously focused element from before the dialog was opened only if focus is in the dialog when the dialog closes. Without this, focus can unexpectedly shift away from an element which is not going away, like a text input that the user is currently typing into for example.
Context: whatwg/html#8904 This patch prevents the behavior where closing a dialog focuses the previously focused element from before the dialog was opened only if focus is in the dialog when the dialog closes. Without this, focus can unexpectedly shift away from an element which is not going away, like a text input that the user is currently typing into for example. This matches the behavior we recently implemented for popovers. Change-Id: Id95cacf36b2eb24d3514f59bc8a1f718d643860e
This patch prevents the behavior where closing a dialog focuses the previously focused element from before the dialog was opened only if focus is in the dialog when the dialog closes. Without this, focus can unexpectedly shift away from an element which is not going away, like a text input that the user is currently typing into for example. Tests: web-platform-tests/wpt#39579. Fixes #8904.
Context: whatwg/html#8904 This patch prevents the behavior where closing a dialog focuses the previously focused element from before the dialog was opened only if focus is in the dialog when the dialog closes. Without this, focus can unexpectedly shift away from an element which is not going away, like a text input that the user is currently typing into for example. This matches the behavior we recently implemented for popovers. Change-Id: Id95cacf36b2eb24d3514f59bc8a1f718d643860e
Context: whatwg/html#8904 This patch prevents the behavior where closing a dialog focuses the previously focused element from before the dialog was opened only if focus is in the dialog when the dialog closes. Without this, focus can unexpectedly shift away from an element which is not going away, like a text input that the user is currently typing into for example. This matches the behavior we recently implemented for popovers. Change-Id: Id95cacf36b2eb24d3514f59bc8a1f718d643860e
Context: whatwg/html#8904 This patch prevents the behavior where closing a dialog focuses the previously focused element from before the dialog was opened only if focus is in the dialog when the dialog closes. Without this, focus can unexpectedly shift away from an element which is not going away, like a text input that the user is currently typing into for example. This matches the behavior we recently implemented for popovers. Change-Id: Id95cacf36b2eb24d3514f59bc8a1f718d643860e
Context: whatwg/html#8904 This patch prevents the behavior where closing a dialog focuses the previously focused element from before the dialog was opened only if focus is in the dialog when the dialog closes. Without this, focus can unexpectedly shift away from an element which is not going away, like a text input that the user is currently typing into for example. This matches the behavior we recently implemented for popovers. Change-Id: Id95cacf36b2eb24d3514f59bc8a1f718d643860e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4436533 Reviewed-by: Mason Freed <[email protected]> Commit-Queue: Joey Arhar <[email protected]> Cr-Commit-Position: refs/heads/main@{#1145455}
Context: whatwg/html#8904 This patch prevents the behavior where closing a dialog focuses the previously focused element from before the dialog was opened only if focus is in the dialog when the dialog closes. Without this, focus can unexpectedly shift away from an element which is not going away, like a text input that the user is currently typing into for example. This matches the behavior we recently implemented for popovers. Change-Id: Id95cacf36b2eb24d3514f59bc8a1f718d643860e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4436533 Reviewed-by: Mason Freed <[email protected]> Commit-Queue: Joey Arhar <[email protected]> Cr-Commit-Position: refs/heads/main@{#1145455}
Context: whatwg/html#8904 This patch prevents the behavior where closing a dialog focuses the previously focused element from before the dialog was opened only if focus is in the dialog when the dialog closes. Without this, focus can unexpectedly shift away from an element which is not going away, like a text input that the user is currently typing into for example. This matches the behavior we recently implemented for popovers. Change-Id: Id95cacf36b2eb24d3514f59bc8a1f718d643860e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4436533 Reviewed-by: Mason Freed <[email protected]> Commit-Queue: Joey Arhar <[email protected]> Cr-Commit-Position: refs/heads/main@{#1145455}
… the dialog, a=testonly Automatic update from web-platform-tests Only restore dialog focus if focus is in the dialog Context: whatwg/html#8904 This patch prevents the behavior where closing a dialog focuses the previously focused element from before the dialog was opened only if focus is in the dialog when the dialog closes. Without this, focus can unexpectedly shift away from an element which is not going away, like a text input that the user is currently typing into for example. This matches the behavior we recently implemented for popovers. Change-Id: Id95cacf36b2eb24d3514f59bc8a1f718d643860e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4436533 Reviewed-by: Mason Freed <[email protected]> Commit-Queue: Joey Arhar <[email protected]> Cr-Commit-Position: refs/heads/main@{#1145455} -- wpt-commits: a2848420dbdb869afb53e11706814c029a9911eb wpt-pr: 39579
… the dialog, a=testonly Automatic update from web-platform-tests Only restore dialog focus if focus is in the dialog Context: whatwg/html#8904 This patch prevents the behavior where closing a dialog focuses the previously focused element from before the dialog was opened only if focus is in the dialog when the dialog closes. Without this, focus can unexpectedly shift away from an element which is not going away, like a text input that the user is currently typing into for example. This matches the behavior we recently implemented for popovers. Change-Id: Id95cacf36b2eb24d3514f59bc8a1f718d643860e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4436533 Reviewed-by: Mason Freed <[email protected]> Commit-Queue: Joey Arhar <[email protected]> Cr-Commit-Position: refs/heads/main@{#1145455} -- wpt-commits: a2848420dbdb869afb53e11706814c029a9911eb wpt-pr: 39579
… the dialog, a=testonly Automatic update from web-platform-tests Only restore dialog focus if focus is in the dialog Context: whatwg/html#8904 This patch prevents the behavior where closing a dialog focuses the previously focused element from before the dialog was opened only if focus is in the dialog when the dialog closes. Without this, focus can unexpectedly shift away from an element which is not going away, like a text input that the user is currently typing into for example. This matches the behavior we recently implemented for popovers. Change-Id: Id95cacf36b2eb24d3514f59bc8a1f718d643860e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4436533 Reviewed-by: Mason Freed <masonfchromium.org> Commit-Queue: Joey Arhar <jarharchromium.org> Cr-Commit-Position: refs/heads/main{#1145455} -- wpt-commits: a2848420dbdb869afb53e11706814c029a9911eb wpt-pr: 39579 UltraBlame original commit: 06a9f85dd269c956f131aa46b813e72a329257ef
… the dialog, a=testonly Automatic update from web-platform-tests Only restore dialog focus if focus is in the dialog Context: whatwg/html#8904 This patch prevents the behavior where closing a dialog focuses the previously focused element from before the dialog was opened only if focus is in the dialog when the dialog closes. Without this, focus can unexpectedly shift away from an element which is not going away, like a text input that the user is currently typing into for example. This matches the behavior we recently implemented for popovers. Change-Id: Id95cacf36b2eb24d3514f59bc8a1f718d643860e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4436533 Reviewed-by: Mason Freed <masonfchromium.org> Commit-Queue: Joey Arhar <jarharchromium.org> Cr-Commit-Position: refs/heads/main{#1145455} -- wpt-commits: a2848420dbdb869afb53e11706814c029a9911eb wpt-pr: 39579 UltraBlame original commit: 06a9f85dd269c956f131aa46b813e72a329257ef
… the dialog, a=testonly Automatic update from web-platform-tests Only restore dialog focus if focus is in the dialog Context: whatwg/html#8904 This patch prevents the behavior where closing a dialog focuses the previously focused element from before the dialog was opened only if focus is in the dialog when the dialog closes. Without this, focus can unexpectedly shift away from an element which is not going away, like a text input that the user is currently typing into for example. This matches the behavior we recently implemented for popovers. Change-Id: Id95cacf36b2eb24d3514f59bc8a1f718d643860e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4436533 Reviewed-by: Mason Freed <masonfchromium.org> Commit-Queue: Joey Arhar <jarharchromium.org> Cr-Commit-Position: refs/heads/main{#1145455} -- wpt-commits: a2848420dbdb869afb53e11706814c029a9911eb wpt-pr: 39579 UltraBlame original commit: 06a9f85dd269c956f131aa46b813e72a329257ef
This change: #6531
See this for an example: https://jsfiddle.net/sirisian/9f7t5pbm/1/
Source
I have multiple use cases with dialog show() where I get unexpected blur events because of this behavior. I'm required to unregister blur events before I call close and then reregister them afterwards. I'd argue that showing a dialog and allowing the user to change focus is the whole idea with a non-modal dialog. So having it revert to the previous focus that happened to be selected when the dialog was shown is not what's intended.
The text was updated successfully, but these errors were encountered: