Confusing session lock error message shown if tab re-opened shortly after closing it

[ManuelHu]

Steps to reproduce

1. being logged in the element web instance
2. Close the tab
3. open a new tab with the same element web instance in a time frame shorter than 30s

Outcome

What did you expect?

Element opens again - as with Element 1.11.40 - without any user intervention

What happened instead?

The message "%(brand)s is open in another window. Click "Continue" to use %(brand)s here and disconnect the other window." is shown [%(brand) has bee redacted by me]

Note that at the time, no other instance is running and no tab/window is open, so the message is confusing to users. Apart from that, the re-startup after clicking continue is annoyingly long.

---

See:
matrix-org/matrix-react-sdk#11425
matrix-org/matrix-react-sdk#11416

Operating system

Windows, Linux

Browser information

Firefox 117, 118

URL for webapp

No response

Application version

Element 1.11.41

Homeserver

Synapse 1.92.1

Will you send logs?

No

[richvdh]

I wasn't able to reproduce this. Closing the tab should cause the session lock to be dropped so that the new tab opens immediately.

Are you able to provide any more details to help me reproduce the problem?

[ManuelHu]

Sadly, I do not really have any more insight currently. I have just tested it again on FF 118 (beta) on Linux, and it still reproducible. But this is not a linux-only problem, a user of my element instance could also reproduce it with Firefox on Windows.

My test sequence:

• open Firefox window
• open Element tab and another new tab, activate the Element tab
• Ctrl+W and Ctr+Shift+T in short succession (< 1 second!)
• (the empty new tab is just that firefox does not close)

I have tried without any adblockers and firefox tracking protection, but the problem still persists.

The problem does not occur every time. Depending on how fast I manage to open the tab again, roughly 50 - 90% of my trials to produce the confusing session lock message "succeed"...

---

In the browser console I see:

getSessionLock[<new session guid>] Last ping (from <old session guid>) was 11204ms ago, waiting bundle.js:2:3221130
getSessionLock[<new session guid>] Last ping (from <old session guid>) was 30023ms ago: proceeding with startup bundle.js:2:3221130

so the UI is showing correctly and the old lock is still there - So somehow the clearing mechanism does not work reliably?

[richvdh]

right yes, I can reproduce that. Thanks.

[richvdh]

Hrm, the pagehide event isn't firing.

It's difficult to see this as other than a Firefox bug, and I have opened https://bugzilla.mozilla.org/show_bug.cgi?id=1854492 to track it. However, I fear we'll have to work around it.

I avoided the unload event since apparently it's unreliable and comes with big warnings, but on this basis, the pagehide event is even less reliable. Maybe we should listen to both and drop the lock when either happens...

[ManuelHu]

I read the linked page, and I cannot find a hint that unload should be less reliable than pagehide - but it additionally disables the bfcache. At least the page only mentions the same scenarios for unload/pagehide (i.e. mobile browsers that cannot observe their own termination).

But of course, the "alternative" visibilitychange event is certainly not an option - Element should be able to work in the background :-)

[ManuelHu]

I did some quick testing and replaced paghide with unload in the vendor bundle on my Element instance. On firefox this fixes the session lock not being cleared.

[ZanderBrown]

Instead of using events documented to be unreliable to try detect a tab closing, why not use a BroadcastChannel to simply ask other tabs if they are alive?

Between browser crashes, restarts to update, or even just accidentally hitting reload, I'm hitting this several times a day and it's getting a teensy bit old :-)

[richvdh]

Instead of using events documented to be unreliable to try detect a tab closing, why not use a BroadcastChannel to simply ask other tabs if they are alive?

And wait how long for a reply? Too short and we risk starting up while there are two sessions running, corrupting the data store. But any timeout is just even more time waiting for Element to start.

[ManuelHu]

I'd like to implement the solution outlined by @richvdh above, so to listen to both events, but only run the event handler once. This certainly would have some 'benefits' over the current solution:

• it works on firefox, as the unload event gets fired reliably (in my tests with a patched Element)
• the unload event handler also blocks Element from ever getting into the bfcache, which is - as far I understand the comments in the session lock code - never desired
• If Chrom(e|ium) really is firing pagehide more reliably than unload on Desktop systems (which I highly doubt), Element would still have a handler for it.

I will be preparing a pull request

[richvdh]

@ManuelHu that sounds great, thank you!

[ManuelHu]

@richvdh It just came to my mind that it might be helpful to update the mozilla upstream bug, as now develop.element.io is fixed.
If I remember correctly, there is at least one site providing (all) old element releases online?—but I do not remember what it was called...

[t3chguy]

@ManuelHu https://riots.im/

[richvdh]

I have to say I can no longer reproduce this even on older versions such as https://riots.im/1.11.46 :/