Ensure toast timeout doesn't elapse when tab is in background

[fm3]

NML Upload for large NMLs can take several minutes. Users leave the tab and when they return, the error toast is gone and they don’t get to know what was wrong with their NML or the server.

Maybe we should do this only for large NMLs? Any opinions?

[philippotto]

I would have thought that the toast timeout only starts counting, after the user has interacted with the page (i.e., moving mouse or using keyboard). Not sure whether that's really the case, but this should be double-checked. In my opinion, that would also be the proper solution, but have no strong opinion here.

[fm3]

pretty sure that toast timeout is running in background tabs. can we do something about that? that would do the trick :)

[fm3]

@jstriebel also suggested to log the content of those (and maybe all?) toasts also in the js console, to enable copying their full content later, what do you think @philippotto ?

[philippotto]

@jstriebel also suggested to log the content of those (and maybe all?) toasts also in the js console, to enable copying their full content later, what do you think @philippotto ?

Good idea 👍

[philippotto]

pretty sure that toast timeout is running in background tabs. can we do something about that? that would do the trick :)

Yes, I think this should be solvable. Ironically, searching for this problem always brings up the opposite scenario (the browser slows down timeouts and intervals when the tab is in the background). I didn't find a solution which simply pauses a timeout, but I came up with the following heuristic idea (untested).

Use requestAnimationFrame to ensure that the tab is active before starting the timeout and after it has been completed. Something like this:

async function waitInForeground(timeout) {
	await requestAnimationFrame();
	// Now, the tab is active
	await sleep(timeout);
	// Now, the timeout has passed, but the user could have switched to another tab in the background.
	// As a heuristic, check whether the tab is active now.
	const then = Date.now();
	await requestAnimationFrame();
	if (Date.now() - then > 2000) {
		// The tab seems to be in the background. Restart the timeout.
	 	await waitInForeground(timeout);
	}
	return;
}

This solution is not super precise. For example:

• switching to another tab after the timeout has started and switching back to the tab before it finishes, will hide the toast after the provided amount of seconds (equal to the current implementation) --> the user sees the toast on two occasions, but not for the total intended duration
• switching to another tab shortly before the timeout will be finished and switching back to the tab a bit later will reset the complete timeout --> the user sees the toast longer than the intended duration

However, I think this trade-off is acceptable, since the above cases will be quite rare and still okay-ish. There's probably a better solution out there, but I couldn't come up with something better (which doesn't do some sort of busy-checking whether the tab is active). Maybe chopping a given interval into 5-seconds steps, and then calling waitInForeground for these chunks sequentially improves this approximation.

[fm3]

sounds fair to me :)