A short explanation about the context of that question
We have been fighting the whole day with a CSS bug on the Zoom window. We could figure out how to fix it, but we wanted to know where this bug comes from. So we did a few tests.
Starting state :
- Production: we currently do not have this bug on production, running with our code base released on Jan 07th & zoom web SDK NPM package downloaded when building that release on Jan 07th as well.
- Others environments: we have (or had now) this bug on our development and staging environments. Development is still using the web SDK 1.8.5 and staging is using 1.8.6 for testing purpose. The bug started to appear after this weekend. (the release date of the 1.8.6 on Jan 10th)
What we did as investigation:
- We verified our code (since we have multiple version under development / across the environments) to ensure this bug is not caused by an update on it.
- We roll-backed the web sdk version to 1.8.5 on staging : same bug as development or with 1.8.6.
- We tested in local (to be able to reproduce it) : same bug
- On local, we tested cross zoom’s “environment” (using our dev/stg/prod zoom account from our local environment) to eliminate the option of potential dynamic code injection through your web sockets being different from a Zoom account to another one : same bug
- We redeployed (and build a new docker image, which implies a redownload of the NPM package of the web SDK) with our code base from the 07th release and deploy on staging : same bug
- We redeployed on staging the docker image built for production on 07th : No bug
So it looks like the web SDK 1.8.5 NPM package have been updated between Jan 07th and today (maybe on Jan 10th), introducing this (small) bug on 1.8.5.
- Could you please confirm our assumption ?
- If that’s the case, is it a common practice ? Should not you release sub versions instead of patching without versioning ?
The bug mentioned
When opening the participant panel, the layout is incorrect:
Even worse when opening the chat panel as well: