JavaScript Knowledge Base
Snippets of useful info can be found here allowing you to quickly see what to expect and why
This page will show you useful details that might affect some, or all revisions of our JS SDK, as well as all the interesting facts that might not be related to our SDK, rather to the browser or app that is being used. If you know something that is not mentioned here, just let us know of the same.
CSP friendly
Content Security Polices forbid usage of eval function among other restrictions. Our SDK is now following the best practices to make the implementations where CSP plays a big role a nice and simple thing to do.
EdgeHTML 15.15063 memory leak causing issues
The browser bug caused memory leaks which is a security issue however it also caused things to not work as expected. Our r27 revision address this by making a workaround the leak allowing our system to properly function.
FireFox buffer overflow caused FireFox to crash
This browser bug would cause the browser to crash at some occasions due to buffer overflow. After reporting it it turns out to be a Firefox bug known for some time, with the first clear steps on how to recreate it and sample code reported by us, so this should be resolved in FireFox versions that followed.
Uploading file sometimes not working when Modern theme is used
In some circumstances if v2 embedding is used with Modern theme it could happen that trying to upload a file would not work as expected
No sound recorded in Chrome
With some specific configurations it was possible to not have sound recorded when recording a video on Chrome.
Echo was found present within video recording
In some specific circumstances echo would be present due to our tests for microphone, which could lead to echo being present in the video recording. The tests were changed so that echo is no longer present.
Rerecorder is not working in completely desired manner
In specific configurations of v2 embeddings and rerecording process, there could be issues present for the re-recorder.
Flash Flickering when using Chrome 54 on Mac OS
When using v1 recorder and Flash, it is possible that due to race condition Flash seems to flicker. r21 introduces the workaround for the same
Console Errors - 412 Precondition Failed
412 Precondition Failed error was shown when something is missing during submission. In our embeddings this would usually happen while player tries to play back the video that is not yet available. This was reported correctly (per specs) as 412 error, however in console it seemed as incorrect as it should be treated as a notice instead. As such we have resolved this in r22 to not show error if the same should be treated as a notice.
WebRTC bug present in Chrome v57
There was a bug present in how Chrome v57 was working with WebRTC, which created an issue for some people. This browser bug is likely to impact all revisions before the fix is added to our SDK. As it impacts only some people, it is possible that it still works when you test it out.
Chrome 57 and Opera 44 WebRTC browser bug
Another Chromimum based browser bug that made things work not as expected. This one however has a higher severity as it would cause the video to be as long as 0.x seconds instead of 2 or more minutes of recording, rendering the video to be same as snapshot. This bug is within Chromium project, which means that Chromium based browser were impacted such as Chrome and Opera, however Chrome and Iron browsers (and any other that use Chromium for its base) could also have been impacted.
Edge issue causing player to show spinner instead of video
Edge is not following standards for video processing, which is causing it to show spinner on video load instead of allowing the playback to be started even though everything is ready and waiting.
Internet Explorer issue causing player to show spinner instead of video
Internet Explorer is not following standards for video processing, which is causing it to show spinner on video load instead of allowing the playback to be started even though everything is ready and waiting.
HD videos recording on iOS devices through web interface
Mobile devices have great resolutions and most of them are HD, still your videos could end up as SD. The reason for this is that some systems, such as iOS are not allowing the camera recording to be of high quality if the recording is made for browser. What this means is that even if your system settings are set for highest resolution, your iOS system can return very small resolution of video instead. This saves network, makes browser faster and battery life longer. With release of iOS 11 it seems that they will support WebRTC, which should allow us to capture the full quality of video.
Time limitations on mobile devices
Mobile devices OS developers have made a choice or two in what the native apps will allow and accept and what it will not. As such the time limitation imposed by the code would not be accepted, rather the limitation is at the option of person recording the video. To "fight" this we have made 2 things - we will detect the limitation set by you and then cut the video at that length, alternatively, you can use enforce-duration parameter in your embedding to show that the video is rejected due to its length. Until Android and iOS developers decide that they will allow the same to be controlled through browser, there is no way around it. Our r23 revision and newer have support for time limit through Cordova / PhoneGap, however it might not work in all cases.
Rerecordings setup on mobile devices
While there is code from our side to watch for the number of re-recordings it is good to point out that some versions of native apps on mobile phones will allow you to rerecord video without telling us that rerecording was made. In such cases (when such native option is shown and used), all we would know is that video was recorded and uploaded and it would seem as the original recording.
Pausing recording on mobile devices
Mobile app can show people recording video (depends on the app and system) and option to rerecord the video if they are not happy with it. This will be possible even if we send it the instructions to only allow one. The reason why that is possible is because native apps will ignore most if not all of the parameters sent through code within a mobile browser (or webview element) and will not report if the recording was done in one or more takes.