Noticed this while looking at these `act` warnings. I didn't manage to
solve those, but at least this makes the tests more consistent with
current docs.
In the upgrade I managed to dust off some tests that I'd been skipping
for quite a while. It turns out one of them was pointing out a real
problem: in the network error case, we didn't display the error to the
user properly. It's really sad this reaches our code as a `TypeError`,
but it is what it is.
* update `msw` 0.49 -> 1.x. (2.x is out now, but small steps.)
* wrap some `jest.{runOnlyPendingTimers,advanceTimersByTime}` calls
in `act`.
* extend a timeout that had no slack at all
This gives much better information to the UI layer, getting rid of a
whole troubleshooting guide entry. See #119#132#218#219
I also restructured the code in anticipation of a new WebSocket event
stream (#40).
I was struggling to upgrade the version of mui stuff (material and date
picker). I'm hoping getting rid of the deprecated stuff eases this a
bit.
I don't love that I can't just use sx on plain HTML stuff and have to
wrap it in Box, but oh well. Looks like I'm not alone, fwiw.
https://github.com/mui/material-ui/issues/23220
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
