-
Notifications
You must be signed in to change notification settings - Fork 332
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
fix(detached): open keyboard on input focus #762
Conversation
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 42eb2c5:
|
75b8cc4
to
f741b7e
Compare
4567289
to
31183f4
Compare
No idea why CodeSandbox fails to build the dependencies, but this is testable locally. |
const tempInput = environment.document.createElement('input'); | ||
const { top, left } = inputElement.getBoundingClientRect(); | ||
|
||
tempInput.style.position = 'absolute'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
personally I'd rather see this as intentional browser behaviour instead of trying hacky fixes. I like the refactor and simplifications in the main file, but personally wouldn't do the temporary input
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I copied exactly the hack, I'll check if this works without.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant that I'm not fan of having a hack in a library, I feel like it might have unexpected side effects in the future
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, and it currently does actually—there's a regression introduced by the fact that we no longer batch, and it might require additional code which will increase the library's size.
I suggest we close this and mark as wontfix for now. We can revisit later if it resurfaces.
This introduces a hack to force the keyboard to open when opening the search modal in detached mode.
Summary
iPhones (and probably Android phones as well) don't let you programmatically assign focus, just like they don't allow you to autoplay videos, etc. We can set focus if this is done within a user event callback (which is the case here and it works) but we can't open the keyboard, this only happens when the user deliberately taps the input (we can't even simulate it).
Nike found a hacky workaround which was extracted in this StackOverflow question. I haven't found other workarounds.
Note that it doesn't work when called within
requestAnimationFrame
, which is why I had to remove it at least for the opening of the modal. Dropping this optimization is a trade-off, but since this isn't a DOM update that happens a lot (only when opening the modal) it's likely fine.Tests
Unfortunately I don't think there's a way to test this behavior for now. AFAIK the virtual keyboard isn't available in the browser, and Cypress.io can't run tests on real mobiles, so we can't even take screenshots with our current setup.
Investigating alternatives for end-to-end on mobile might be an option in the future, if we think it's worth it.
fix #653