User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36 Steps to reproduce: This is the official release of the JS SDK with support for data channels.

This applies the necessary patch, I've given it a run through with different browsers at each end and it seems fine. The initial tests with the data channel work seem to be good as well, so I think we might as well land this now.

Comment on attachment 8606274 [details] [diff] [review] Upgrade OpenTok library to v2.5.1. Review of attachment 8606274 [details] [diff] [review]: ----------------------------------------------------------------- rs=dmose. I haven't tried this; I'm assuming we may want to do a qe-verified+ here, perhaps suggesting running through all the MozTrap tests as well as the QA smoke tests that stepend put together? For future library upgrades, it would be nice to include a link to the release notes (in this case it's easy, since the release notes always appear to be at the same URL: <https://tokbox.com/opentok/libraries/client/js/release-notes.html> I'm quite excited to see that we'll be losing this spew from their logging in 2.5.1: 'Extra "no element found" errors logged in the web console in Firefox.' :-) I assume none of the other files under sdk-content have changed?

(In reply to Dan Mosedale (:dmose) - needinfo? me for response from comment #2) > rs=dmose. I haven't tried this; I'm assuming we may want to do a > qe-verified+ here, perhaps suggesting running through all the MozTrap tests > as well as the QA smoke tests that stepend put together? I would suggest that QA do a selection of call testing (direct & rooms), across different versions of FF, i.e. nightly - release, nightly to standalone etc. I don't know what MozTrap coverage there is - the changes here would only relate to items where two people are connected. The QA smoke tests are basically check it works in an unsupported browser (Safari), and check it works on Chrome. I've done both of those locally in my own smoke testing before requesting review. > For future library upgrades, it would be nice to include a link to the > release notes (in this case it's easy, since the release notes always appear > to be at the same URL: I didn't think this was a published release, so I hadn't gone looking. > I'm quite excited to see that we'll be losing this spew from their logging > in 2.5.1: > > 'Extra "no element found" errors logged in the web console in Firefox.' Actually, that was fixed in 2.5.0 I believe. > I assume none of the other files under sdk-content have changed? Nope. The css & js ones are the critical ones. I don't check the img ones as they aren't delivered in the package, but we don't display them anyway.

(In reply to Mark Banner (:standard8) from comment #4) > I would suggest that QA do a selection of call testing (direct & rooms), > across different versions of FF, i.e. nightly - release, nightly to > standalone etc. > > I don't know what MozTrap coverage there is - the changes here would only > relate to items where two people are connected. > > The QA smoke tests are basically check it works in an unsupported browser > (Safari), and check it works on Chrome. I've done both of those locally in > my own smoke testing before requesting review. We did a number of calls (rooms and direct) between latest Aurora 41.0a2 and Chrome, Opera, Firefox 39.0 RC, Firefox 40 beta 8, latest Aurora and latest Nightly across platforms (Windows 7 64-bit, Mac OS X 10.10.4 and Ubuntu 14.04 32/64-bit) and did not encounter issues during calls.