[react-interactions] Prevent duplicate onPress firing for keyboard Enter #17266
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 9034656:
|
|
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 529a5dd:
|
trueadm
force-pushed
the
duplicate-on-press
branch
2 times, most recently
from
221bdba to
53bc9d4
Compare
trueadm
force-pushed
the
duplicate-on-press
branch
from
53bc9d4 to
8ac6c1e
Compare
| @@ -914,8 +914,7 @@ describe.each(environmentTable)('Press responder', hasPointerEvents => { | |||
| ReactDOM.render(<Component />, container); | |||
|
|
|||
| const target = createEventTarget(ref.current); | |||
| target.keydown({key: 'Enter'}); | |||
| target.click({preventDefault}); | |||
There was a problem hiding this comment.
Why was the click event removed from this test? When Enter is pressed is certain host elements it will cause a click to be dispatched
There was a problem hiding this comment.
Not if you preventDefault, meaning click will never fire.
There was a problem hiding this comment.
The reason we preventDefault on Spacebar it because otherwise it scrolls the window. Should we preventDefault on keydown for Enter though?
There was a problem hiding this comment.
I think so, unless you know of any reason why we should not?
|
@necolas You seem to know quite a bit about this logic. If you are happy and have time, please could you do some digging into it to help me? I'd really appreciate it :) |
Internally, we encountered an issue where the
LegacyPressresponder would double fireonPresswhen theEnterkeyboard key was pressed. Looking into this deeply, the reason for this was because the browser triggers aclickevent which passes the logic inisScreenReaderVirtualClick.I tried to find different discrepancies between screen reader clicks and the click that is fired from the browser when you press
Enterbut I couldn't see anything that stood out – so I took another approach and realized, by accident, the reason this doesn't happen when you pressSpaceornativeEvent.preventDefault. This means that the corresponding nativeclicknever gets triggered by the browser, but the responder still correctly fires theonPresscallback – this time only once though!I also noticed that is behavior didn't occur in the newer Press responder. I added support for the
Spacebarkey type there, but I also noticed a difference ininputandtextarealogic between the two responders that might be worth while tracking in a separate task – but maybe this is something @necolas has already considered.