Fix focus going to the DropZone after closing FileTrigger

[yihuiliao]

Closes https://github.com/orgs/adobe/projects/19/views/4?pane=issue&itemId=31784583

The issue of the focus going to the wrong element is caused by the onClick function. Originally, this was added so that users could click on the dropzone to paste. However, an unintended side effect is that when a user would click on the FileTrigger, that would trigger the onClick function which would cause the focus to move to the visually hidden button. I've updated it so that the onClick function will only focus on the visually hidden button when the currentTarget and target are the same. See #4451 (comment) for more context

As for the second issue mentioned in the ticket, where the VO cursor would disappear after closing the FileTrigger, I think that's a separate, unrelated issue which is not DropZone specific. It seems that this also happens when an regular html input. You can test it here https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/file on an iPhone and experience the same issue. So this PR doesn't fix that. Might be a VO bug?

✅ Pull Request Checklist:

• Included link to corresponding React Spectrum GitHub Issue.
• Added/updated unit tests and storybook for this change (for new code or code which already has tests).
• Filled out test instructions.
• Updated documentation (if it already exists for this component).
• Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:

Test any of the stories with a filetrigger + dropzone in RAC
When you open a FileTrigger and close it, the focus should remain on the FileTrigger

Go to the DropZone Example with Copyable Object story
You should be able to copy and paste with your keyboard and by clicking on the dropzone with your mouse and pasting it via command + v

🧢 Your Project:

[rspbot]

Build successful! 🎉

• View the storybook
• View the storybook-17
• View the storybook-16
• View the documentation

[snowystinger]

Could we instead stopPropagation of the click event? or cancel the click by preventingDefault on the pointer events (if memory serves)?
Or we could check the target vs currentTarget of the event?

[rspbot]

Build successful! 🎉

• View the storybook
• View the storybook-17
• View the storybook-16
• View the documentation

[rspbot]

Build successful! 🎉

• View the storybook
• View the storybook-17
• View the storybook-16
• View the documentation

[reidbarber]

LGTM

[LFDanLu]

LGTM

[rspbot]

Build successful! 🎉

• View the storybook
• View the storybook-17
• View the storybook-16
• View the documentation

[rspbot]

Build successful! 🎉

• View the storybook
• View the storybook-17
• View the storybook-16
• View the documentation

[rspbot]

Build successful! 🎉

• View the storybook
• View the storybook-17
• View the storybook-16
• View the documentation

[rspbot]

## API Changes

unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any', access: 'private' }
unknown top level export { type: 'any', access: 'private' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'identifier', name: 'Column' }
unknown top level export { type: 'identifier', name: 'Column' }
unknown type { type: 'link' }
unknown type { type: 'link' }
unknown type { type: 'link' }
unknown type { type: 'link' }
unknown type { type: 'link' }
unknown type { type: 'link' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }