Open bilogic opened 1 week ago
- Press F5,
Reload site
pops up
We do not have any such reload, this is handled by the browser not jitsi-meet, isn't it?
Yes, the prompt showed probably because jitsi-meet told Chrome that there is some dirty info on the page.
So the issue here is probably because jitsi-meet did not handle the return.
Can you show a screenshot of that dialog? There is no such thing handled in jitsi-meet. So I don't see what we can do about it.
Cancel
is clicked, jitsi has to prevent the page from refreshing + not interrupt the recordinghttps://dev.to/chromiumdev/sure-you-want-to-leavebrowser-beforeunload-event-4eg5 For the record, JS is not my regular language, but I have sufficient understanding that this prompt can be handled correctly by any JS
There is no such thing handled in jitsi-meet. So I don't see what we can do about it.
Then it might be a case of adding a handler to deal with it
When I do the shortcut for reload the page reloads. There is no dialog. This is what I experience. That's why I ask for screenshot cause there is no such dialog implemented in jitsi-meet and I think this is something external that has nothing ti do with jitsi-meet.
Did you start recording in step 1?
Thanks for the video. You are right, I was skipping that part, sorry and I was not aware of the dialog. We do have it, but still it is the browser one and so the strings in it are not available in jitsi-meet. https://github.com/jitsi/jitsi-meet/blob/639114f2e19ad2e619ba81d8c6552b2385169c81/react/features/base/conference/middleware.any.ts#L302 I'm not sure you can detect whether the user has clicked cancel or not https://developer.mozilla.org/en-US/docs/Web/API/Window/beforeunload_event
I'm not sure you can detect whether the user has clicked cancel or not https://developer.mozilla.org/en-US/docs/Web/API/Window/beforeunload_event
Yes you can, that is the sole purpose of that dialog, to prevent users from closing their window resulting in a catastrophic disaster, i.e. loss of data
In fact, it would be great if jitsi always pops this dialog for any refresh as I see no use case for a refresh. I reported an issue here https://github.com/jitsi/jitsi-meet-electron/issues/986
Refresh is actually an important part of the meeting experience. Anytime a client gets into an inconsistent state (connected to new backends, failure in existing connections) that cannot be resolved internally, a reload is triggered to rejoin the meeting.
Yes you can, that is the sole purpose of that dialog, to prevent users from closing their window resulting in a catastrophic disaster, i.e. loss of data
If you can detect when the user clicks Cancel, please share it with us or create a PR. I'm not familiar with that and a simple search shows that this is not possible with current browser API.
ok will do, give me a while
https://jsfiddle.net/2tc3krz4/4/ has different behaviors when clicking Reload
vs Cancel
I think jitsi is lacking the preventDefault()
, as a result, the refresh bubbles upwards causing the jitsi to refresh
The problem is that when the reload confirmation dialog appears if you click cancel the local recording is stopped and saved. How in the code in that jsfiddle do you determine whether the user has clicked cancel?
Have you been able to check the code I posted above? It is already calling preventDefault()
.
How in the code in that jsfiddle do you determine whether the user has clicked cancel?
Seems there is no reliable way to do that for now.
Can I suggest blocking F5 and ctrl+R for refreshing and allow refreshes only when a user clicks on the browser's refresh button or click on URL and press enter
In other words:
F5
/ctrl+R
does not trigger the prompt (see https://vscode.dev/, both keys do not refresh the page)After looking at the code snippet mentioned by @damencho I understand that regardless the user clicks reload / cancel the browser will stop the recording first as it is notified that a possible unload is about to occur thus triggering the before unload event which is a justified approach.
To my knowledge there was only one person in that meeting and reloading the page should technically close that meeting as the only recipient left the meeting thus saving the recording, have you tried this with multiple users in the meeting? We could probably add a condition where if the meeting isn't empty the recording shouldn't stop.
@SakkyOP
beforeunload
limitations head on, a simple straight forward way can be to prevent the prompt from showing, e.g. disable F5/ctrl+R to deal with the OP while still leaving some options to refreshI think a better approach would be to shift the stop recording functionality to take place when the pagehide
/ visibilitychange
event occurs
Also I noticed that the use of returnValue
is wrong in beforeunload
event handler, the prompt is shown when preventDefault()
is called which is correct but in legacy versions the prompt appears when the returnValue
property is set to a truthy
value ( it is set to null
in the current version which is falsy
)
F5
and ctrl + R
visibilitychange
and pagehide
unload
event I was going to suggest the unload
event but it is deprecated alternatives are mention in the Usage Notes section.beforeunload
event This mentions when the dialog box appears.@SakkyOP
From what I understand of your approach:
Reload
prompt to show, but recording continuesReload
, pagehide
will run and stops the recordingCancel
, prompt closes and no refreshing takes placeCorrect? If yes, then I agree yours is the better approach
@bilogic
Yes that's exactly what I'm trying to say 👍
You cannot execute async code in those events, it is unreliable.
@damencho then are we better off with blocking F5 and ctrl+R?
I don't think we will want to block that.
You can configure it on your deployment via some of the empty file hooks in index.html.
What happened?
https://github.com/user-attachments/assets/85f739eb-bb15-4d28-9fb4-ce40eb12bc97
Reload site
pops upCancel
My jitsi runs in docker using this commit https://github.com/jitsi/jitsi-meet/commit/24ae69348bdafe7dba229dcc8fa8d943c16e9469
Platform
Browser / app / sdk version
Chrome 129.0.6668.100 (Official Build) (64-bit) /
Relevant log output
No response
Reproducibility
More details?
No response