Hi there again! Another problem regarding same token.
Previously there was a out of gas error that caused manifold gallery page to break for all tokens. This was fixed with contract upgrade and the HTML now loads properly:
There is still however second issue: the audio does not work. The problem seems to be only specific to the Manifold gallery page. If animation is opened using “View original animation”, the sounds work properly. Sounds also works properly in marketplaces such as Opensea:
The audio also works when the tokenURI is obtained through Etherscan
When animation is clicked and sound should start, instead of that an error is shown in browser console:
Uncaught (in promise) TypeError: Cannot read properties of undefined (reading ‘addModule’)
at initAudio (data:text/html;base64,PCFET0N
Would it be possible for someone to assist/investigate?
If this error would consistently happen in different marketplaces, I would suspect it to be problem in the smart contract. But it only happens in Manifold’s gallery page. If Manifold gallery does not support audio that is all I need to know. But if it should support, I think there might be some encoding problem going on.
Does anyone know if Manifold gallery works in testnets (Sepolia / OP Sepolia)? It would be really helpful if I could debug this issue also in my end outside mainnets. Its quite difficult to reproduce as it only is found to happen in Manifold gallery
Hey tokenfox, do you not have the error when just copy pasta’ing into chrome? I do, which should mean it’s issue with the JS running inside of the HTML itself to me.
May just need to tweak the JS served by your renderer. OS could be cached so it’s always hard to tell what they’re serving, I’d go off what’s in tokenURI.
Recreation steps:
Copy paste tokenURI from etherscan into the browser
My guess as a creative coder? You got the audio initialization deferring right in timing, but something is unhooked in the handler. Your audioWorklet is undefined.
Particularly it was helpful to know that manifold gallery works with Sepolia. I was able to make a test deployment to Sepolia and will debug it there moving forward:
With this I can now compare this to Opensea deployment.
I also believe that this problem is related to the use of data URI encoded AudioWorklet modules. For some reason they fail loading on Manifold gallery, but work on Opensea. Will update here if I figure what is causing this!
Extra question: is there any way to force Manifold Gallery to update tokenURI if it has changed?
Inside the iframe, I in this case attempt to initialize audioWorklet from BaseAudioContext (BaseAudioContext - Web APIs | MDN). The problem here is that the audioWorkletrequires Secure context to be available. Data URI is not treated as secure context by browsers, which means that audioWorklet is unavailable inside the iframe.
The only way I could see this being fixed is that Manifold Gallery changes implementation. I am not expecting of course you would do this, but if you would, I would see couple of options:
Option 1: Implement on-chain artwork detection to Manifold Gallery. If on-chain artwork is detected, it should be parsed and displayed using iframe with srcDoc instead of src.
Option 2: Implement CDN/caching and point the iframe with src to the cache instead of Data URI. This is the way Opensea has solved the problem (using seadn.io as CDN/cache).
Of course alternatively, I would need to change my implementation to not contain fully on-chain artwork for the animation and serve the animation from CDN. Or rework it to not use audioWorklet which is unfortunately key part of the artwork
Summarizing: this issue can be closed. Unfortunately, I don’t foresee a simple workaround for this issue. In case you are interested in exploring adding support to on-chain artworks to Manifold gallery, would be more than happy to join in to collaborate.
Ooooo I love this technical solve. Nice detective work tokenfox. Definitely going to see what I can do here because you’re completely right and the iframe is going to throw security issues if that’s what audioWorklet needs. I’ll see if srcDoc is secure enough for us to use when we detect data URIs we can parse out, and if so, you’ll def see that update soon.
Likewise appreciating your interest in going the extra mile. Feel free to continue conversation here or reach out to me in other channels if you want to continue the exploration further.
Will do, Imma leave this thread open to help me keep track of the new potential feature. Will report back if we decide not to go forward and your solution is indeed the final solution. Bless tokenfox, and dope art!
A bit of a follow-up after talking with other on-chain art developers:
iframe with srcDoc instead of src indeed would be the preferrable way to get the artworks rendered with necessary priviledges. If there is any update on this, let me know. Would be very interested in following up and helping as necessary!
