I thought about just moving the parse failure message handling to queueMessage, but that quickly turned into a minefield of pain. This gets the job done for now.
Many older devices do not support the Let's Encrypt CA, for various
reasons. This causes connection issues for sites using Let's Encrypt to
support HTTPS connections. This commit adds a hack that can be enabled
with a switch in callbacks.js to try to detect when the user's browser
does not trust the certificate and permit the user to connect to an
insecure endpoint instead.
Unfortunately, the AJAX API does not allow to distinguish between *why*
a request fails, so the best we can do is detect that the HTTPS request
failed, try to make a request over plain HTTP, and if it works, assume
the HTTPS request failed due to a certificate error. It's not 100%
foolproof since the HTTPS endpoint could just be down for some reason,
but it should work well enough in most cases.
Closes#602
The `from` field has existed for ages, but was never actually displayed.
Displaying it to users reduces confusion about who is making the
announcement.
The channel settings emote list is now paginated and leverages the same
basic code as the emote browser, but with a different renderer. Fixes
#594 and kills an ugly function.
The error messages were a bit difficult for users to understand due to a
combination of including useless technical information and lacking
userful user information. The error messages are more verbose now and
give a better indication of what went wrong.
Also combined adminflair and modflair into one button (the button has 2
states if you're a moderator, or 3 states if you're a site
administrator). Resolves#517
Refactored the ffprobe stream-selection logic to handle rejected files
better:
* Streams tagged as a non-default disposition are not considered
* If a file has any video stream, the audio stream will be ignored
This should prevent videos from being misreported as invalid audio
codecs, etc.
If clients call it quickly in succession with large playlists, it can
cause node to get stuck stringifying socket.io frames and cause an out
of memory crash.
When the changeMedia frame loads a new Google Drive video, @yt is still
set from before and moreover @yt.ready is still true, so calling play()
can result in a TypeError if the new embed hasn't loaded yet (this
seemed to happen consistently in Chrome and I was unable to make it
happen in Firefox).
