WTI Contest Clocks don't count correctly when the browser is minimized.

[clevengr]

Describe the issue: please provide a clear and concise description of what the bug is.

PR #1034 added Elapsed Time and Remaining Time clock displays to the WTI user interface. These are driven by JavaScript setInterval() objects, which are essentially timers that tick (and invoke a specified function) at a selectable rate. These timers are quite accurate -- unless the browser window is minimized. (This is a documented feature of nearly all browsers, including Chrome, Firefox, IE, Edge, Safari, and Opera -- in other words, all the ones we most likely care about.)

To get around this, PR #1034 includes code to check for clock drift in the displayed times; if the drift is more than 5 seconds the PR code calls the PC2 server (via the WTI Server) to get the "correct" time. In addition, that PR also performs an "automatic resync" of the display clocks at a (build-time) specifiable interval defined in WTI-UI constants.ts (the value is currently every 15 minutes).

However, the above "fixes" are not really good solutions; the code should be updated to keep the clocks accurate regardless of the condition of being minimized or not.

To Reproduce:

• Choose a PC2 distribution that includes PR I1027 Add Contest Clock To WTI #1034.
• Start a PC2 server using --load sumithello.
• Start a PC2 Admin; use it to start the contest.
• Start a WTI Server using ./bin/pc2wti in the WTI Interface folder.
• Start a browser, login to PC2 as a team.
• Observe the times on the team screen header.
• Minimize the team browser.
• After some time, un-minimize the browser.

Expected behavior:

The team clocks should have been updating regularly.

Actual behavior:

If you watch closely when the browser is restored, you will see (for a split second) that the time displays show the values they had when the browser was minimized, rather than the correct (current) time. Note: this effect is difficult to see because the code subsequently applies the necessary "adjustment" to get the displays back in sync with the server.

Environment:

• PC2 Version : any which include PR I1027 Add Contest Clock To WTI #1034
• Browser : any

Additional context:

One possible solution to this problem is to keep track of "elapsed time" using a JavaScript WebWorker. This is a class which executes outside of (i.e. independently of) the browser's context -- meaning it is not affected by browser minimization. Such a class could use a setInterval() that doesn't get throttled; it could send messages to the main display code when timer ticks occurred.

However, I spent many hours trying to get this concept working -- but failed. Many of the problems I ran into had to do with the inability of our Angular build environment to recognize, and properly link to, the various libraries which support WebWorkers. In the interest of time, given that the current implementation provided by PR #1034 does work (although it's a bit hokie), I gave up on this approach.

For completeness, here are some links to pages I found that attempt to address some of the issues I encountered:

https://gist.github.com/nolanlawson/23eff93d27ad09ff44b7e4d56ffd1d54
https://stackoverflow.com/questions/38715001/how-to-make-web-workers-with-typescript-and-webpack
https://github.com/zlepper/typescript-webworker/blob/master/src/index.ts
https://github.com/Qwaz/webworker-with-typescript/tree/master/worker-loader/src

In fact, after many hours I was actually able to get WTI-UI to build with a combination of various approaches (the above, and others). However, when I tried to execute the resulting code in a WTI-UI team browser, I got messages which told me that it didn't support "Cross-Origin" access. In other words, the WebWorker code appeared (to the browser) to be coming from a different origin that the original WTI-UI code (which in a sense is true; the WTI-UI code was coming from the WTI-API server whereas the WebWorker code was coming from a TypeScript file that had been compiled into JavaScript and bundled into the build). Here are some links that talk about that kind of issue:

https://stackoverflow.com/questions/67326425/construct-worker-from-script-loaded-from-different-origin
https://stackoverflow.com/questions/21913673/execute-web-worker-from-different-origin
https://stackoverflow.com/questions/58098143/why-are-cross-origin-workers-blocked-and-why-is-the-workaround-ok
https://stackoverflow.com/questions/58099138/getting-failed-to-construct-worker-with-js-worker-file-located-on-other-domain\
https://stackoverflow.com/questions/75395907/my-url-createobjecturl-blob-creation-of-a-webworker-also-creates-a-failing-get-r

In any case, I have no more time to pursue this issue. In case someone in the future chooses to look further into it, there is a branch on my clevengr/pc2v9 fork which contains some code attempts at solving the problem: i1027_Contest_Clock_Worker_Thread.