The original debounce implementation (lodash) preserved the
caller's context - radash didn't, so it was failing and it wasn't noticed.
The new debounce implementation with the native function seems to preserve caller's context, but as a safety measure this commit binds the method to its appropriate scope.
There are a couple of hardcoded UA checks targeted at iOS endpoints
introduced circa 2.2-beta. One of those pops up an "unsupported" toast
when the device joins a conference - the other blocks camera
sharing.
Those checks are outdated since we transitioned to minBrowserVersions
approach that redirects the client to an unsupported view upon join. I
also assume the checks are bugged since, in some environments, it flags
iPadOS endpoints as iOS and version-checks it to a hardcoded "12.2"
threshold (which is incompatible with iPadOS versioning). That caused
camera sharing not to work, which is a false negative.
I consider the checks to be outdated, so I removed all references to
them.
There's a scenario where remote streams won't be attached again if the
sharer experienced a Meteor/client disconnection.
The disconnection empties some necessary user data temporarily, which
causes the corresponding video-list-item to be unmounted while the peer
persists for a little longer.
If the sharer re-connects fast enough, video-list-item will re-mount but
will 1) miss the current stream state (ie stuck in loading) 2) fail to
re-attach the streams since the peer was already flagged as attached.
Ensure remote camera streams are always attached and shown by:
- always propagating the current stream state on attachment
- refactoring the attachment pre-requisites away from a static boolean
to a required data + diff check (based on target and current
attached streams)
