Closed Bug 1091537 Opened 5 years ago Closed 5 years ago
Link clicker UI IE support
The TokBox IE plug-in helps provide support for IE8 through to IE11. This is enabled on the TokBox SDK from release 22.214.171.124 This bug tracks the process to support the IE plug-in from TokBox on Firefox Hello link clicker UI.
let's investigate what it takes to fix this. let's see how big the changes are to get working.
backlog: --- → Fx37+
As discussed over Vidyo. This, along with bug 1073415 should get calls working. I'd like to test it with you when you are reviewing this.
Assignee: nobody → jaws
Status: NEW → ASSIGNED
Attachment #8517679 - Flags: review?(dmose)
Iteration: --- → 36.2
Points: --- → 3
OS: Windows 8 → All
Comment on attachment 8517679 [details] [diff] [review] Patch Review of attachment 8517679 [details] [diff] [review]: ----------------------------------------------------------------- r=dmose for the code changes themselves. I'm happy to test on a call with you in the morning.
Attachment #8517679 - Flags: review?(dmose) → review+
Sorry, but I don't even know what qe-verify means for this bug: A simple manual verification with any version of IE on any Windows which shows that the link clicker page loads and shows the start is probably doable. Doing the same thing from IE 8 all the way to IE 11 and across all different version of Windows would be substantial effort. Actually verifying that calls work with all version of IE on all Windows flavors is even more effort. Verifying that all features in an established call works as expected is even more effort. Doing all this in an automated way is even more unrealistic, as we at Mozilla don't have the tools, experience or resources to test features like this on IE. There is a long list of open question from my perspective, which should have been answered before this landed: - How are users going to report bugs for the IE plugin? Bugzilla doesn't even allow you to specify IE as your browser, or? - Who is going to take care of the bug reports? - How do we debug and solve problems on code, which we don't own?
Flags: qe-verify+ → qe-verify-
(In reply to Nils Ohlmeier [:drno] from comment #6) > There is a long list of open question from my perspective, which should have > been answered before this landed: > - How are users going to report bugs for the IE plugin? Bugzilla doesn't > even allow you to specify IE as your browser, or? I think we need to remember that the standalone client is basically a web page - just like our other websites - and we accept bugs on those which are IE (or another browser) specific. There's a lot of infrastructure around the IE plugin (and the SDK) to set up and make the calls actually work. That's what we need to be testing and ensuring works. In theory, we have this issue for all reasonably current browsers (i.e. the at least the "browser unsupported" view should work in most cases - see bug 1092239 for example). > - Who is going to take care of the bug reports? There's at least two levels of bugs here: 1) things that the standalone client tries to do which IE doesn't support. Just like this bug. 2) issues in the IE plugin and SDK supplied by TokBox (or even their servers). > - How do we debug and solve problems on code, which we don't own? I think we already have this with the SDK itself - if we have an issue, then we analyse to see if its in our code or theirs. If we think it is in the sdk then we have a discussion with support folks and it gets fixed (or they explain what we're doing wrong). Given the plugin is something extra to the sdk, and not cross-browser, it might be worth setting up an additional component for bugs that we think are the plugin-only, but it may be too early for that just yet. In case there's something I've missed with respect to how we intend on handle these types of bugs, needinfoing RT and Adam as they will know more.
Mark I agree with what you say. Safari support will also come at some point through the SDK (coming with March 2015 SDK release) and there are considerations for iOS and Android support through apps leveraging again the SDK for iOS and Android.
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Before I can mark this qe-verify+ I think we need to have a meeting about what QE can support. The last time we discussed this (a couple weeks ago) it was agreed to that QE would not need to support this. There are significant resourcing concerns and we are just now beginning to test Firefox 35 features. I am not willing to put people on supporting this until we've at least verified our own builds work. In other words, we need to support Firefox before IE and we've not yet reached a point where I can confidently say Firefox is well enough supported.
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #10) > In other words, we need to support Firefox before IE and we've not yet > reached a point where I can confidently say Firefox is well enough supported. Flagging myself so I know to come back to this asap.
And sorry for spamming this bug with these high level question and concerns, but I'm not aware of any meta bug or other high level IE feature integration documentation where the expectations and responsibilities are properly documented.
I think as Anthony said in comment 10 we need to have a meeting on what we can do, the expectations etc. As Anthony's already flagged it to himself, I'll let him take this further.
Comment on attachment 8518495 [details] [diff] [review] Patch w/ r+ Approval Request Comment Landed on aurora per IRC with lsblakk with a=loop-only
Attachment #8518495 - Flags: approval-mozilla-aurora?
Attachment #8518495 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(In reply to Mark Banner (:standard8) from comment #15) > I think as Anthony said in comment 10 we need to have a meeting on what we > can do, the expectations etc. As Anthony's already flagged it to himself, > I'll let him take this further. Indeed I did - I plan to suggest a support proposal in tomorrow's 10:30am PT meeting. Assuming we agree to the proposal or some modification of it, I will follow up here in this bug.
I'm sympathetic to the problems that Nils raises, but these are fundamentally the same issues as we have with Chrome interop at the moment. If we run across a problem, we isolate it to "our code" or "not our code," and if it's not our code, we hand it off to TokBox. The value proposition of the toolkit includes isolating us from the vagaries of different browser implementations (including the IE plugin), and we should plan our testing accordingly. That said, we do need some short list of browsers we're going to test the standalone client in. The list of candidates gets big quickly: * Firefox Linux * Firefox Mac * Firefox Windows * Firefox Android * Chrome/Chromium Linux * Chrome/Chromium Mac * Chrome/Chromium Windows * Chrome/Chromium Android * sBrowser Android * Bowser iOS * Internet Explorer Windows * Opera Linux * Opera Mac * Opera Windows * Opera Android ...and that's ignoring the multiple versions of the browsers. The problem gets even bigger when native WebRTC support comes to IE and Safari (assuming this happens at some point). I'm tagging Romain here so that he can make a priority call about which platforms we need to actively test against. If we need a larger testing team to support what we need to support, then we should take steps to figure out how we're resourcing that.
Flags: needinfo?(adam) → needinfo?(rtestard)
I think our principles should be: 1 Prioritize testing on Firefox always 2 Testing in third party browsers should be done in order of browser usage share on the link clicker page (the scope of the testing being obviously limited to what features we support on specific browsers). 3 Browsers with less than 1% hits on the clicker page should be considered non supported We don't have reports regarding browsers most used on the link clicker page although I'll see what could be done on Kibana with Katie. The list will probably look like what follows although I'll confirm once I get clearer stats from the link clicker page: 1 Firefox Windows 2 Firefox Mac 3 Firefox Android 4 Firefox Linux 5 Chrome/Chromium for Windows 6 Chrome/Chromium for Mac 7 Chrome/Chromium for Android 8 Safari for iOS 9 IE11 (Windows) 10 Android sBrowser 11 Safari for Mac 12 IE8 (Windows) 13 Opera for Windows 14 IE9 (Windows) 15 IE10 (Windows)
Clearing NI as we decided not to support IE plug-ins.
(In reply to Romain Testard [:RT] from comment #20) > Clearing NI as we decided not to support IE plug-ins. Just closing the loop here on what QA could theoretically support if we ever decide to change that decision (this applies to *any* browser we'd want to support with plugins). Regarding test coverage, we have web automation in place for loading the standalone page in WebRTC-supported browsers. In addition, Nils is working on an end-to-end test that should help for Firefox but this will not benefit the plugin. We will depend on Tokbox's test coverage for their plugin, whether it be automated or manual. Regarding bug investigations, we can provide some support for initially investigating bugs that involve users outside Firefox. However, we will rely on Tokbox to investigate issues involving their plugin. The priorities in comment 19 seem sane to me. QA will always put Mozilla's products first, third-parties who support WebRTC second, and all others last. That said our team has limited resources and any future test coverage will need to be prioritized against our new 2015 priorities. For any further questions on this I recommend contacting Marc Schifer and/or Clint Talbert.
You need to log in before you can comment on or make changes to this bug.