twiddlingbits
Please do a bit of testing on the 2.5.0 release
Hi Johnathon,
I released 2.5.0 to npm and github. I did a fair amount of testing, and found issues mostly related to the npm package, which i fixed. But i did all my npm testing using the npm pack command.
Please do a clean download from npm and verify that (a) unbundled examples run w/o building (using server.py), and (b) examples build and run (bundled and unbundled)
Also please test online examples on mac, if you have one (I don't, do you?). https://twiddlingbits.dev/examples/dist/index.html. Test bundled and unbundled.
Thanks
All of the tests seem to work fine from a fresh install from NPM. However, I do seem to get an invalid hash from the extended drawimage function that I'll need to look into.
As for testing on Mac, I don't have one to test on either.
Strange, the hash tests all worked for me.
On the mac, i will send you my log in info for https://www.browserstack.com/
Please test a mac/safari combo, then we can close this.
Issues with Mac:
A. It seems like many of the hashes used from tests-d2d are invalid for Mac:
B. For some reason Mac is having issues with loading the audio files in the tests-audio test. However, it only seems to happen when using the
C. I originally ran using MacOS Ventura which used Safari 16.5. However, canvas.reset() used by Pong doesn't seem to be supported until Safari 17.2 (supported by the latest two MacOS versions Sonoma and Sequoia), so I did the rest of my testing with MacOS Sonoma using Safari 17.2
It seems like many of the hashes used from tests-d2d are invalid for Mac:
not surprising, that's not a bug.
Safari 17.2
Are all the tests passing with this version?
Every test except the ones in tests-audio that play directly from the file URL.
It seems to be an auto-playback issue. Most browsers have a whitelist for which websites can automatically play audio on a web page. This is one of the reasons you have to hit a button to start the audio tests as the button click, at least for Firefox and Chrome, acts as a user interaction to unlock audio playback. However, that seems to only partially work for Safari. My best guess is that there's an extra check for HTMLMediaElement's since they're usually supposed to be visible (and clickable), so the user has to specifically interact with the element itself to get it to play. Meanwhile, the method that loads the entire file uses an AudioContext (which isn't usually an HTMLElement) so it bypasses it somehow. I'm not quite sure if that's the right answer, but it's the best I could find. I'm not quite sure how to fix that other than just loading the entire file similar to how the other functions use.
For now, I'm going to fix it to at least go through the test rather than get stuck until a better solution is decided upon. Also, I noticed that audio.play() can fail asynchronously. It's currently available to both normal and asynchronous modules so I can't just return the error. So, should I setup a way to handle errors, such as a callback?
on the safari auto playback issue, it sounds like we should create a seperate issue for that and we will try and work through it.
For the audio.play, i'd need to understand the issue a little better to have an opinion. Maybe we could talk tomorrow? Are you free? I am free at 2pm or late CT, or 10am or before CT. I'm also around this weekend.