Ghost participants on refresh in recent Chrome


On recent version of Chrome (testing > 73) when refreshing the page the user reconnects successfully but a ghost participant (a thumb) of him persists for a ~minute.

What may cause this?


This is new in Chrome : “disallowed synchronous ajax during end-of-page events”
I think we should use strophe in async mode especially while disconnecting

Very annoying because if we do 10 refresh we could have 10 ghosts until prosody timeouts each connection.

Yep probably you had found the issue, we will check it at some point. We were also discussing some other ways of detecting those ghosts and removing them. It is on our roadmap.

Yes I noticed this, but still think that Strophe request is blocked by the recent Chrome policy.

Yep, I agree with that, we will be checking it.

Any news on this? @damencho I saw your post on
What’s the correct way of handling this?

This is still to be implemented. The correct way is using send beacon … not sure in jitsi-meet or lib-jitsi-meet, we are about to work on that in the following two weeks, but any help is welcome…


Oh this is very cool. Will test ASAP!!

Just to report that this fix is working.

However i applied this fix manually to jitsi-meet_3344 and its a little different(added sid and removed https before the url):

const body = this.connection._proto._buildBody()
			type: 'terminate'
	const pres = $pres({
		xmlns: Strophe.NS.CLIENT,
		type: 'unavailable',
		sid: this.connection.sid


	const res = navigator.sendBeacon(
		Strophe.serialize(body.tree()));`Successfully send unavailable beacon ${res}`);

Which prosody version are you using?
What is your bosh setting in config.js, does it start with ‘//’ or ‘https’?
Thank you for coming back to us!

bosh: ‘/http-bind’
prosody: 0.9.xx && 0.11.xx tested

However there is issue that makes me wait before update to the latest prosody:

Hum, that is strange. I had tested the changes about sending those messages with prosody-trunk we use and there was no problem with it. I will re-test again with 0.11. But I’m sure that the prefixing with https was needed … which makes it strange …