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
waitForFileChooser + click race #6040
Comments
Update: after considering this a bit more: if chrome is guaranteed execute the received javascript in order, it might be enough to change registering our callback with the fileChooserInterceptors, before we await the enable call:
|
Sometimes get |
We're marking this issue as unconfirmed because it has not had recent activity and we weren't able to confirm it yet. It will be closed if no further activity occurs within the next 30 days. |
Same |
When "doing a tap and waiting for a file chooser", the docs suggest the following approach of using waitForFileChooser:
This is very racy, as the click might basically happen before the
Page.setInterceptFileChooserDialog
call (setting up browser to track file chooser) to the browser is done.Also the alternative form:
suffers from the same. Again, the
Page.setInterceptFileChooserDialog
call might not be complete before sending over the click data.The right order of things would be:
This is rather incompatible with the current signature of
waitForFileChooser
, as it would have to return 2 promises (or Promise of Promise). The first indicating setup went alright, the second indicating the file chooser has been launched.(In our testing setup, we workaround this issue by doing an extra race-less
await page._client.send('Page.setInterceptFileChooserDialog', {enabled: 1})
before usingwaitForFileChooser
)The text was updated successfully, but these errors were encountered: