Hi @gianni.zoom,
WebCodecs will be part of Chrome 94, which will be released on Sept. 21. If WebCodecs is causing the video issues with Web SDK 1.9.8, as many users reported here, will Zoom be releasing any fix for that? We have just released our app with Web SDK 1.9.8 last night without the WebCodecs origin trial, and we are afraid that we will encounter same issues once Chrome 94 is released.
Regards,
Lara
hello, ifrancia, are you use the mac chrome 93 & 94 ?
HI @JackYang,
The issues I reported here happened on Chrome 93 + Web SDK 1.9.8 + SIMD + SharedArrayBuffer + Web Codecs as mentioned in the following comment.
We will retest on Chrome 94 beta as well.
Lara
Hi @JackYang,
Our team has just tested our application, which is using Web SDK 1.9.8 + SIMD + SharedArrayBuffer Origin Trial, on Chrome v94.0.4606.38 Beta on the following devices. Please refer below for the result.
And below is the screenshot of how it looks. The “client” took this screenshot.
This will be a critical issue for us as soon as Chrome Browser v.94 is released so, we would really appreciate it if you can fix it before Chrome 94 is released.
Please let us know if you need more information.
Regards,
Lara
Hey @lfrancia ,
Thanks for sharing your findings. We are looking into this. 
@nvivot ,
Yes.
We will update our docs to mention this property here: https://marketplace.zoom.us/docs/sdk/native-sdks/web/advanced/web-isolation (DEVELOPERS-1819)
Console warning for SAB shows up using OT, but it works the same way as with CORP headers
To our understanding there is no reason to use COEP Credentials. It seems less secure than using SAB + WebCodecs and does not provide any advantage over the other two.
-Tommy
We have the same issue with the video on Mac only, and we have cross-origin isolation enabled. Here are some logs
macOS 11.5.2 | Chrome v94.0.4606.38 Beta
Windows 11 | Chrome v94.0.4606.38 Beta
Same as @lfrancia, the camera does work on Windows
To our understanding there is no reason to use COEP Credentials. It seems less secure than using SAB + WebCodecs and does not provide any advantage over the other two.
It’s not a question of being more or less secure, but to be able to use features required by Zoom without the web isolation strict mode.
Looks like either you did not realize that he SAB will ends in December and that after that, unless web isolation is set, the Zoom Web SDK will not work anymore.
So it’s all about being able to implement web isolation on time, before that SAB OT ends, and credentialless bring another mode for the web isolation, more permissive yes but that unblock the situation where it’s impossible to implement web isolation in its strict mode.
I understand that you - Zoom - within your very simple example application do not need it as you are not using anything else than your own services, but we - Zoom’s client - are doing integration of your products inside another larger application scope that potentially uses other services (like Datadog in our example) that cannot be used - yet - with the web isolation mode setup.
This is why in our cases the credentialless mode seems to be a good temporary solution to have features requiring web isolation mode to continue to work, but without the pain to be forced to implement the web isolation everywhere, especially when it comes to request this web isolation implementation to 3rd party vendors (they also have their own agenda that might not match with our or your)
I asked that question, because from our test, it’s obvious that the Web SDK do not care at all about the credentialless mode right now, since when we use it, the SharedArrayBuffer warning log saying “hey, you have to implement web isolation before…” still popup. I bet the current code check the value of the web isolation mode for the strict mode only since it was published before the OT for the credentialless mode being public.
Would be great if the SDK is a bit more flexible and take the credentialless mode into consideration. And because it’s a feature allowed by Google (after so many customers complained about them forcing this web isolation everywhere at last minute), you should de-facto support it and include that in the guide & your tests as your customers may use it - again, as a temporary solution, we all agree this is not a long term solution.
PS: if you don’t know what is the Credentialless mode for the web isolation, i invite you to read this. This mode will be definitively part of Chrome 96 by the way, so it’s real & official, not just an OT.
And let me quote this here to make sure this reply to your original answer:
With COEP: credentialless, we want to find a robust-enough protection against accidental cross-process leakage, without requiring an explicit opt-in from every subresource.
Seems this issues is only for Mac on both Chrome 93 and 94?
We also encountered issue on a windows machine and chromebox when we tested web sdk 1.9.8 + SIMD + SharedArrayBuffer + Web Codecs on Chrome v.93 as I have mentioned here Web SDK with WebCodecs on 1.9.8 not showing user/participant video - #7 by lfrancia but it just not happen all the time.
Thank you @tommy!
I hope Zoom can find a solution for this issue this week since Chrome 94 will be released on Sept 21 already! It is just 5 days away. Our business will be greatly impacted by this issue.
Regards,
Lara
@lfrancia I’m mainly testing on the Mac OS at the moment but have had people on Windows also having the issue.
Same for us. We have a lot of clients who rely on our inbuilt Zoom offering so it’s reflecting poorly on us when it’s perceived as working one week and not the next.
@tommy is there anything that us as a community can assist with to expedite a solution?
We are also experiencing the issue, we already enabled the trials through the headers method, which already working for the shared array buffer
Hey @nvivot , @lfrancia , @developer-whova , @mijodu , @giancarlo1 ,
disableCORP will have a default value starting in version 1.9.9 of:
disableCORP=!window.crossOriginIsolated
Moving forward, you should no longer need to touch the value.
As for Chrome 94, we are working on a new version to address the Webcodecs changes in Chrome.
For the No Video issue in Chrome 93, please see the following findings - the third scenario fixes the issue:
Chrome Version: 93
Meeting SDK Version: 1.9.8
disableCORP: true or false (had no affect)
Origin trails: None.
Send / Receive Video from SDK does not work.
Chrome Version: 93
Meeting SDK Version: 1.9.8
disableCORP: true or false (had no affect)
Origin trails: Shared Array Buffers, WebAssembly SIMD, WebCodecs.
Send / Receive Video from SDK does not work.
Chrome Version: 93
Meeting SDK Version: 1.9.8
disableCORP: true or false (had no affect)
Origin trails: Shared Array Buffers, WebAssembly SIMD.
Send / Receive Video from SDK works.
When not using WebCodecs Origin Trial it works.
Thanks,
Tommy
Hi @tommy,
Thank you for testing it and confirming our issues. We really appreciate it.
I hope next time that Zoom recommends certain origin trials (in this case Web Codecs) especially every time we report an issue, thorough testing is done on the Zoom supported browser versions on the Zoom side first. I am sorry to say this but based on the past issues that we had, it seems like we, the community, and your customers, did the testing for Zoom. The issues that we reported are easy to reproduce but it still took Zoom more than 1 week to acknowledge them wherein it should be Zoom who should have found out about the issues first before us. And for other customers here who trusted Zoom’s recommendation, these issues affected their businesses in many ways (financially, loss of customers’ trust, etc.).
And, since Zoom claims that they support the latest Chrome browser version based on Zoom’s documentation, Zoom should do beta testing weeks before it will be released. So, if ever there is any issue found, fix will be provided to us (your customers) at least a week before the browser major release and we will also have enough time to apply it on our app and test it. Just in case you don’t know yet, for Chrome browser, you can check this page Chromium Dash for their release schedule.
By the way, when is Web Meeting SDK 1.9.9 scheduled for release?
Regards,
Lara
Hey @lfrancia ,
Thanks for your feedback here. We totally understand and we have been working on improving our testing flows to ensure this does not happen again.
We are doing our best to keep up with the Frequent Chrome Breaking changes: https://groups.google.com/a/chromium.org/g/blink-dev/c/6knQoJRpje4
“WebCodecs will ship in M94. Breaking changes in future releases will be rare and will include a deprecation period. Thank you all for your patience as we iterated on the design!” - Chrome team
We will be releasing 1.9.9 on Monday with the Webcodecs fix for Chrome 93 and 94.
https://marketplace.zoom.us/docs/changelog
Thanks,
Tommy
Hi @tommy,
Glad to hear that the fix will be provided before the Chrome 94 release.
Thank you for your support.
Regards,
Lara
@tommy thanks for the communication on the above. I was wondering whether there was an update on the 1.9.9 release? We have a big event tomorrow using our Zoom integration so we need to ensure this update has been incorporated into our codebase beforehand.
Cheers,
Mike
I’ve been keeping at eye on the changelogs, the WebSDK repo and this forum and the only releases I’ve seen have been on the API side, so I’m guessing that there wasn’t a release in the end for the WebSDK. I don’t suppose there is an updated time-frame for this is there?
