Video and Audio freeze when handling unload beforeunload

Meeting SDK Web
1

Description

Hello Zoom dev support.

We are currently using Zoom WEB SDK 1.9.1 in ReactJS app.

We are handling window beforeunload like to display browser confirm message before closing the application :


  const handleBeforeUnload = event => {
    event.preventDefault();
    event.returnValue = '';
  };

  function useBeforeUnload() {
    useEffect(() => {
      window.addEventListener('beforeunload', handleBeforeUnload);

      return () => {
        window.removeEventListener('beforeunload', handleBeforeUnload);
      };
    }, []);
  }

It will show browser popup like this when user leave the page (press ctrl + W, closing window) :
image

The Issue is that if the user click on cancel (to stay on the page), the video and the audio freeze.
Another issue is that even if the user leave / rejoin audio, disable / reenable audio, it will not fix the video and audio freeze.

We noticed this issue recently and we know that it was working on older WEB SDK version. So I guess this issues were introduced in recent changes.

Thank you,

Regards.

Loic.

2

Hey @ljacquel,

Thank you for reaching out to the Zoom Developer Forum. Just to clarify, the dialog shown is a custom dialog that you created? This sounds like it might fall outside our scope of support but I’ll do my best to help out.

First, if possible, please try testing this behavior on the latest version of the Web SDK (1.9.6).

Thanks,
Max

3

Hello MaxM,

Thank you for your response.

This is not a custom dialog. This is a dialog displayed by the browser by adding the code I showed to catch onbeforeunload event. For example there is same popup in many other sites, like gmail when you try to leave a page when you are editing email.

I think there is something in Zoom SDK that is unloading at a wrong timing on beforeunload event or somewhere similar. So there is nothing I can do on the application side to fix it I guess.

Of course if you do not show the popup, this issue is not a problem because window will close right after. But there is still a problem with the unload flow I think.

Since it was working on previous version, I guess you did some changes recently somewhere on the unload function.

I will try with latest SDK and let you know as well.

Loic.

4

I confirm you that the issue is also happening in 1.9.6
It is also happening in 1.8.6, so changes have been done before this version I guess.

5

Hey @ljacquel,

Thanks for following up. Are you also seeing this with the Sample Web App? So far I haven’t seen the same issue when testing on my end.

Thanks,
Max

6

Hello @MaxM ,

I am not able to reproduce with the sample app as it is now because as I explained you do not use the beforeonload event to display the browser popup. I think actually the issue might be happening (something wrong in the unload event), but since the page immediately close, it does not affect the user.

By the way, I was able to reproduce it simply by adding the beforeonload event like this

image
image1391×718 49 KB

(I am using chrome)

You can see documentation of this browser option on developer.mozilla.org
WindowEventHandlers.onbeforeunload - Web APIs | MDN

Let me know if you have any more informations,

Thank you,

Loic.

7

Hey @ljacquel,

Thank you for confirming. I was indeed referring to adding that event listener to the Sample Web App. I’m thinking this is something that changed recently because I was able to accomplish the same not too long ago.

On that same note, I tried reproducing this on my end but wasn’t able to. I tried on both MacOS and Windows using the latest version of the Sample Web App.

image
image703×138 9.49 KB

For MacOS, I used Chrome and saw that a system dialog is shown confirming the leave. With Chrome on Windows, I saw that a browser dialog confirming the leave. Neither instance showed me the Zoom dialog that you referenced.

Are you able to provide a bit more information on the OS and Browser that you’re using when you see this?

Thanks,
Max

8

Hello @MaxM ,

Thank you for your follow up.

I was able to reproduce on Windows 10 with Chrome 91.0.4472.77. But I think OS and chrome version does not really matter be cause it is reproducible in many other cases.

I think your miss understood the issue. You said you did not see the Zoom dialog I referenced, but I did not talked about zoom dialog.

The issue is that after displaying the browser message, if you click on “cancel” to say on the page, the video and audio freeze.

Can you try to reproduce again and let me know ?

Thank you,

Regards,

Loic.

9

Hey @ljacquel,

Thanks for following up. You mentioned this Zoom dialog (popup):

image

Which I never saw in my testing for some reason. When testing, I did try to click cancel on the browser dialog but didn’t see the same issue.

Please send an email to developersupport@zoom.us with a link to this thread. In that email, we can set up a time to debug the issue live.

Thanks,
Max

10

Hi Max,

Let me clarify it. What Loic reported is not a Zoom dialog, but a Browser dialog.
The exact same that you could reproduced, you said that on a previous post:

For MacOS, I used Chrome and saw that a system dialog is shown confirming the leave. With Chrome on Windows, I saw that a browser dialog confirming the leave. Neither instance showed me the Zoom dialog that you referenced.

So, all what you have to do is, with the changes mentioned:

  • Join a meeting through the modified demo app with a Participant A
  • Join a meeting through the modified demo app with a Participant B
  • Activate audio & video for both
  • On Participant A, try leaving the application by closing the browser window. This should display the browser dialog asking the confirmation whether you really want to leave or not. Cancel you leaving.
  • Audio & video on Participant A do not work anymore.
  • If i followed what Loic reported, you can play with the activate / deactivation of audio & video on the zoom window and it does not change anything

From that behavior, it seems that the Zoom SDK registers 1 or more of it’s components to react on the unload even of the Window element. But since it cannot know whether it has been cancelled or not, well, the component are deactivated / unload and no matter what you’re doing with the Zoom UI, if the component are not running anymore, it’s not going to work again.
That’s our assumption from the behavior we observed during tests.

Feel free to organize a meeting with Loic to clarify and have a demonstration of that bug.

11

Hey @nvivot,

Thank you for providing more detail. I’ll work to reproduce this on my end and see if I can find a workaround. After that, I’ll reach out to our engineering team if necessary.

I’ll let you know what I find.

Thanks,
Max

12

@nvivot @ljacquel

I was able to reproduce this issue today when using Chrome on MacOS but it looks like this issue isn’t present with the latest version of FireFox.

I’ve since reached out to our engineering team to see if they can provide a fix. I’ll go ahead and close our ticket as it looks like a meeting won’t be necessary now. (ZOOM-284203)

Thanks,
Max

13

@MaxM

Thank you for taking the time to reproduce it.

14

Of course, I’m glad that I could. Thanks for providing detailed information - that helped a ton!

I’ll keep you posted.

Max

15

Hey @nvivot,

Thank you for your patience. Our engineering team responded today with some more information around this issue and how we can avoid it.

First, it was our teams determination that using the SharedArrayBuffer Origin Trial with Chrome is likely the best method to avoid this issue. This is because without the SharedArrayBuffer APIs, the SDK uses fallback APIs which are less efficient and have been known to cause some of these stuttering and freezing issues in the past.

While we can’t confirm that this is the cause, using SharedArrayBuffer will improve SDK performance, provide a better UX, and allow us to quickly test if the issue is related.

While Chrome currently supports SharedArrayBuffer with Web Isolation it seems there were some problems implementing the Cross Origin Isolation within your app.

However, applying for the Origin Trial will allow your application to make use of the SharedArrayBuffer API without Web Isolation and potentially resolve some of these performance and audio/video freezing and stuttering issues that we’ve seen.

Let me know if that helps.

Thanks,
Max

16

Hi @MaxM,

I have just tested this on our application with Web SDK 1.9.6 and SharedArrayBuffers origin trial enabled. However, the issue is still there.

Regards,
Lara

17

Hey @lfrancia,

Thank you for testing that and for following up. I’ve reached out to our engineering team for further insight.

Thanks,
Max

18

Hi @MaxM,

This is just to let you know that this is still happening on Web SDK 1.9.7 with SharedArrayBuffer origin trial enabled.

Regards,
Lara

19

Hey @lfrancia,

Thank you for testing in the latest version! I’ve forwarded this info to our team.

Thanks,
Max

20

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.