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

The previous focus change that was applied to dialog close has unexpected behavior for non-modal dialogs #8904

Closed
sirisian opened this issue Feb 17, 2023 · 5 comments · Fixed by #9178
Labels
topic: dialog The <dialog> element

Comments

@sirisian
Copy link

This change: #6531

See this for an example: https://jsfiddle.net/sirisian/9f7t5pbm/1/

Source
<p>
Click on the right input, then the left, then wait.
</p>
<ul>
  <li>Clicking on the right sets the previous focus</li>
  <li>Pointerdown on the left shows the dialog remembering the previous focus was the right</li>
  <li>5 seconds pass, then the close reverts the focus. Unexpected, and annoying when using blur events.</li>
</ul>
<input id="left" type="text"><dialog id="dialog"><p>test</p></dialog>
<input id="right" tabIndex="0" type="text">
const $left = document.getElementById('left');
const $right = document.getElementById('right');
const $dialog = document.getElementById('dialog');

$left.addEventListener('focus', e => {
  console.log('focus left');
});
$left.addEventListener('blur', e => {
  console.log('blur left');
});

$right.addEventListener('focus', e => {
	console.log('focus right');
});
$right.addEventListener('blur', e => {
	console.log('blur right');
});

$left.addEventListener('pointerdown', async e => {
	console.log('show');
  $dialog.show();
  setTimeout(() => {
    console.log('close');
    $dialog.close();
  }, 5000);
}, { once: true });

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.

@domenic
Copy link
Member

domenic commented Feb 17, 2023

cc @josepharhar @nt1m @sefeng211

@sefeng211
Copy link
Contributor

Yeah I agree, this is annoying.

I think for non-modal dialog case, the previous focused element should be latest focused element that is not a descendent of the dialog. I think this can fix this?

@josepharhar
Copy link
Contributor

I think for non-modal dialog case, the previous focused element should be latest focused element that is not a descendent of the dialog. I think this can fix this?

The inputs in the jsfiddle aren't descendants of the dialog though are they?

@sefeng211
Copy link
Contributor

Yeah, so the previous focused element should be the left input which is not a descendent of the dialog. So dialog.close() won't move the focus to the right input.

@domenic domenic added the topic: dialog The <dialog> element label Mar 15, 2023
josepharhar added a commit to josepharhar/html that referenced this issue Apr 17, 2023
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.
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Apr 17, 2023
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
@josepharhar
Copy link
Contributor

I opened a PR for this: #9178
It does the same thing as this PR for popovers: #9018

annevk pushed a commit that referenced this issue May 12, 2023
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.
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue May 12, 2023
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
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue May 12, 2023
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
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue May 17, 2023
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
aarongable pushed a commit to chromium/chromium that referenced this issue May 17, 2023
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}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue May 17, 2023
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}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue May 17, 2023
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}
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue May 25, 2023
… 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
ErichDonGubler pushed a commit to erichdongubler-mozilla/firefox that referenced this issue May 27, 2023
… 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
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this issue May 31, 2023
… 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
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this issue May 31, 2023
… 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
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this issue May 31, 2023
… 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: dialog The <dialog> element
Development

Successfully merging a pull request may close this issue.

4 participants