This keeps a coarser-grained `toplevel` property rather than `user`
and `session`. It also synthesizes a `streams` field within it with ids.
This makes it easier to put the streams in the URL by id.
I had to disable more of the Login tests to get this to work.
Frustrating, but I just can't figure out how to fake jest timers,
msw, and the testing libraries to all get along anymore.
For whatever reason, these aren't caught in my current setup. I'm trying
to upgrade the whole frontend mess (typescript version, react-scripts
version) and they're caught then.
This requires a bunch of package name changes. See
[https://mui.com/blog/material-ui-is-now-mui/] for their rationale.
[https://mui.com/guides/migration-v4/] lists the changes:
```
@material-ui/core -> @mui/material
@material-ui/system -> @mui/system
@material-ui/unstyled -> @mui/core
@material-ui/styles -> @mui/styles
@material-ui/icons -> @mui/icons-material
@material-ui/lab -> @mui/lab
@material-ui/types -> @mui/types
@material-ui/styled-engine -> @mui/styled-engine
@material-ui/styled-engine-sc ->@mui/styled-engine-sc
@material-ui/private-theming -> @mui/private-theming
@material-ui/codemod -> @mui/codemod
@material-ui/docs -> @mui/docs
@material-ui/envinfo -> @mui/envinfo
```
We only use a few of these.
When you select the first camera in the drop-down on a grid square
that isn't the top left, then select a camera in the top-left, it
behaves strangely.
The root cause is that I had a dumb mistake in how I assigned React
keys. I used the camera index when a camera is selected, and the
inverse of the selected index when one is. But 0 == -0!
As written in the changelog: Live streams formerly worked around a
Firefox pixel aspect ratio bug by forcing all videos to 16:9, which
dramatically distorted 9:16 camera views. Playback didn't, so anamorphic
videos looked correct on Chrome but slightly stretched on Firefox. Now
both live streams and playback are fully correct on all browsers.
* run node 12, 14, and 16 (next to be supported) on CI. This will catch
node version-specific problems like that solved in dad9bdc.
* mention 12 and 14 in build instructions and link to instructions for
installing that version.
* follow this in Dockerfile, installing version 14. This addresses
a "Cannot find module 'worker_threads'" error introduced in
39a63e0, which (inadvisedly) upgraded gzipper 4->5 in addition to
the material-ui upgrade.
* use utf-8 encoding rather than ascii in live part parser. Those
builds apparently don't support ascii. iThey must use "small-icu" or
have ICU disabled, as described here:
https://nodejs.org/api/util.html#util_encodings_supported_when_node_js_is_built_with_the_small_icu_option
This worked fine on my workstation with node 12. But on CI or my laptop
with node 14, it failed. Apparently there @testing-library/user-events
expects a peer @testing-library/dom dependency. At least copying the
"npm install --save-dev @testing-library/user-event @testing-library/dom" command
from the top of https://testing-library.com/docs/ecosystem-user-event/
made it work again on my laptop; fingers crossed about CI.
This is a surprisingly complex upgrade. Some relevant changes from
[their CHANGELOG](https://github.com/mui-org/material-ui/blob/v5.0.0-beta.3/CHANGELOG.md):
* @material-ui/core/styles no longer re-exports some stuff from
@material-ui/styles
* there's no more defaultTheme, so tests need to provide one
* select's onChange has a new type; match that. I haven't actually
tried that the string form (apparently from autofill) works correctly.
* checkboxes no longer default to the secondary color; explicitly
request this in some places.
* checkbox no longer has a checked argument; use event.target.checked
instead.
* date pickers have switched to the new style system, so I had to
redo how I was overridding their spacing for desktop.
* LoadingButton now has a loading property, not pending
* createMuiTheme is no createTheme
To improve reliability of live streams (#59) on Safari.
Safari was dropping the cookie from websocket update requests.
(But it worked sometimes. I don't get why.) I saw folks on the Internet
thinking this related to HttpOnly:
* https://developer.apple.com/forums/thread/104488
* https://stackoverflow.com/q/47742807/23584
but I still see this behavior without HttpOnly. SameSite=Strict vs
SameSite=Lax appears to make a difference. Try that instead.
SameSite=Strict is pointless for us anyway as noted in a new comment.
Turning off HttpOnly would be more unfortunate security-wise.
* don't error out on websocket error message. The close message has
more useful info. (Unfortunately though, for security reasons it
doesn't give too much to the script on initial connection failure.)
* restore normal (non-error/waiting) state when switching cameras.
* prefix all log messages with the camera name
* When the MediaSource is in error state (or busy, I think),
endOfStream throws an exception. This prevented the error from being
properly displayed in the UI. We don't really need to call
endOfStream, I guess.
* including an Event in a format string just said [Object object],
at least on Safari. Use the type instead, which I think is the
only useful info in the event anyway.
