Closed jpiesing closed 3 years ago
yes it makes sense to mention it in the "Running Tests" section on mobile/desktop or on any platform where autoplayback requires user gesture. each Browser has a different menu. we will check this next week.
yes it makes sense to mention it in the "Running Tests" section on mobile/desktop or on any platform where autoplayback requires user gesture. each Browser has a different menu. we will check this next week.
I'm not convinced it's purely a documentation issue. There should be some way of recovering a test run if the test operator misses providing the user input in time.
If you can find instructions for re-enabling autoplay on recent versions of Chrome (e.g. Chrome 90) then it would be good to include that. A search with Google only finds instructions that rely on Chrome options that have been removed.
The play error now gets caught and added to the sessions result and report. After catching the error, the next test is executed.
OK. I can't reproduce it right now. I'll re-open it if a problem comes back.
When trying the tests on my Android tablet, it fails with an error;
"player.js:84 Uncaught (in promise) DOMException: play() failed because the user didn't interact with the document first. https://goo.gl/xX8pDD"
Here's the output when monitoring via USB.
I don't know if you can do anything in the code (even if it's just prompt the test engineer) or if this is a documentation issue.