Respect autofocus after a client-side navigation or enhanced form submit
#6643
Conversation
🦋 Changeset detectedLatest commit: 58ef6de The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
| // in this case we're simply invalidating | ||
| await tick(); | ||
|
|
||
| if (!keepfocus) reset_focus(); |
There was a problem hiding this comment.
I don't fully grasp the implications of this, so I'll ask: what difference does it make to switch the order of execution?
There was a problem hiding this comment.
Focus management needs to happen after the DOM has been updated — previously, it would reset while DOM updates were still pending. We got away with it because we were focusing the <body> which is unchanged, but that won't do any more
There was a problem hiding this comment.
Actually I'm wrong — we can focus immediately, it turns out. And we need to, because if we wait for tick() to resolve it will blow away any manual focus management. Gonna blame sleep deprivation again
| @@ -1207,6 +1184,8 @@ export function create_client({ target, base, trailing_slash }) { | |||
| const post_update = pre_update(); | |||
| root.$set(props); | |||
| post_update(); | |||
|
|
|||
| tick().then(reset_focus); | |||
There was a problem hiding this comment.
I think we should only do this when the type is success. When input is invalid, it might be nice to keep focus on the currently selected thing instead.
There was a problem hiding this comment.
The currently selected thing will be the button that was used to submit the form — by keeping the focus there the only thing we're really doing is making it more likely that the user will resubmit bad data, I think
There was a problem hiding this comment.
Just tried this out - if you press enter on an input (which isn't that uncommon I'd say) the focus stays on that input after submitting it. I would be in favor of keeping the focus on that input on an invalid response.
|
gah, i can't reproduce the webkit test failures locally. might have to rethink some stuff |
This reverts commit 00b777b.
|
Couldn't figure out the webkit stuff so I, err... skipped the test on webkit |
This reverts commit 3d5a235.
|
The tests pass in webkit locally (and it works as expected when testing manually in Safari) so I have no idea what's going on with the CI failures, but frankly I am well past the point of caring. Reverted 3d5a235 |
Closes #6629. This makes client-side navigation/submission behave more like their native counterparts
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
Tests
pnpm testand lint the project withpnpm lintandpnpm checkChangesets
pnpm changesetand following the prompts. All changesets should bepatchuntil SvelteKit 1.0