This is the UX-piece of bug 1009760. The openh264 plugin is a GMP plugin that will be used for webrtc calling and perhaps also for <video> in the future. We need to inform the user when the plugin crashes and ask them to submit the crash report. Exactly or similar to what we do currently for NPAPI plugins? Some questions to answer: * Will we use a single openh264 instance for all tabs, or will it run per-tab? * Will this ever be used in the context of chrome, not running in a tab? * when a plugin crashes, will the page require a refresh, or will it be able to recover on its own?

(In reply to Benjamin Smedberg [:bsmedberg] from comment #0) > This is the UX-piece of bug 1009760. The openh264 plugin is a GMP plugin > that will be used for webrtc calling and perhaps also for <video> in the > future. We need to inform the user when the plugin crashes and ask them to > submit the crash report. Exactly or similar to what we do currently for > NPAPI plugins? > > Some questions to answer: > * Will we use a single openh264 instance for all tabs, or will it run > per-tab? Josh. > * Will this ever be used in the context of chrome, not running in a tab? I don't understand this question. These aren't really embedded in a page the same way that conventional plugins are. They're loaded from a WebRTC context, which is rooted in some JS object, not a DOM element. > * when a plugin crashes, will the page require a refresh, or will it be able > to recover on its own? When a plugin crashes in the context of WebRTC, the call will stop working. Presumably, if someone tries to create a new call, a new plugin will be created.

> > * Will this ever be used in the context of chrome, not running in a tab? > > I don't understand this question. These aren't really embedded in a page > the same way that conventional plugins are. They're loaded from a > WebRTC context, which is rooted in some JS object, not a DOM element. Well JS objects are typically associated with windows. The question is, do we expect that all webrtc contexts will be associated with content and therefore with a browser tab, or is it likely that chrome JS will be using these webrtc contexts? > > * when a plugin crashes, will the page require a refresh, or will it be able > > to recover on its own? > > When a plugin crashes in the context of WebRTC, the call will stop working. > Presumably, if someone tries to create a new call, a new plugin will be > created. That doesn't really help design the UI, though. Web pages typically don't expect NPAPI plugins to stop working, and so when one does, typically the only recourse that the user has is to reload the page. When this thing stops working, is that the advice we should give to the user, or do we expect that most pages will be able to recover from this transparently without user action?

(In reply to Eric Rescorla (:ekr) from comment #1) > (In reply to Benjamin Smedberg [:bsmedberg] from comment #0) > > This is the UX-piece of bug 1009760. The openh264 plugin is a GMP plugin > > that will be used for webrtc calling and perhaps also for <video> in the > > future. We need to inform the user when the plugin crashes and ask them to > > submit the crash report. Exactly or similar to what we do currently for > > NPAPI plugins? > > > > Some questions to answer: > > * Will we use a single openh264 instance for all tabs, or will it run > > per-tab? Right now we're doing one process per plugin. Our plan is to switch to process per origin.

Will Loop be outside of a tab? If so we may need separate UX for that case. Also need answers to comment #2.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #2) > > > * Will this ever be used in the context of chrome, not running in a tab? > > > > I don't understand this question. These aren't really embedded in a page > > the same way that conventional plugins are. They're loaded from a > > WebRTC context, which is rooted in some JS object, not a DOM element. > > Well JS objects are typically associated with windows. The question is, do > we expect that all webrtc contexts will be associated with content and > therefore with a browser tab, or is it likely that chrome JS will be using > these webrtc contexts? I'll leave this question to Adam Roach for Loop. > > > * when a plugin crashes, will the page require a refresh, or will it be able > > > to recover on its own? > > > > When a plugin crashes in the context of WebRTC, the call will stop working. > > Presumably, if someone tries to create a new call, a new plugin will be > > created. > > That doesn't really help design the UI, though. Web pages typically don't > expect NPAPI plugins to stop working, and so when one does, typically the > only recourse that the user has is to reload the page. When this thing stops > working, is that the advice we should give to the user, Yes. > or do we expect that > most pages will be able to recover from this transparently without user > action? No.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #2) > Well JS objects are typically associated with windows. The question is, do > we expect that all webrtc contexts will be associated with content and > therefore with a browser tab, or is it likely that chrome JS will be using > these webrtc contexts? It depends on whether you're asking from a permissions perspective or a UI perspective. The Loop project will be using this from a content context, but won't be in a tab in the conventional sense. We're creating a Loop service that is very similar to the social service. This loads the Loop UI via about: URIs; and the about redirector is configured to set these URLs up with content privs (there are a limited number of "special permissions" attached to it by way of a "Loop API", but these are pretty narrowly scoped to the things that Loop needs to be able to do). So, for example, if we were running a Loop call and the plugin crashed, you wouldn't want to replace the page with a crash reporting form, as you are likely to be in a tiny, unmovable, non-resizable "window" that hovers in the lower-right corner of the browser. If that answer is unclear or incomplete, I'm happy to hop on a quick call to talk through how this works.

This is a UX bug ;-) The OpenH264 plugin crashes. We need to associate that crash with one or more places that we should hang crash reporting UI. If the crash affects a particular tab, and especially if it affects a particular <video> element within that tab, we can probably show the existing plugin crash UI. If the crash could affect something that is not a normal tab, we need to understand if and how we want to show the UI, and whether the user needs to take any other action to recover.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #7) > The OpenH264 plugin crashes. We need to associate that crash with one or > more places that we should hang crash reporting UI. If the crash affects a > particular tab, and especially if it affects a particular <video> element > within that tab, we can probably show the existing plugin crash UI. It's good to think about this in terms of <video> elements, but you also need to keep in mind the encoding side of the equation as well. If we have a camera streaming media to a remote browser and the codec crashes, then there's no obvious content UI to hang the failure notification on. We do have a camera thingamajiggy in the URL bar that you might be able to leverage, but you'd need to keep in mind that the camera might be going to several places, some of which would be unaffected by the codec crash. > If the crash could affect something that is not a normal tab, we need to > understand if and how we want to show the UI, and whether the user needs to > take any other action to recover. As far as I know, the only thing that can do this in anything other than a normal browser tab (at least in the foreseeable future) will be Loop, and we almost certainly want to add special handling for this specific case. For example, we probably want to have a specific call into the Loop code that tells us about the error, and then have Loop do something like pop up a "call failed -- retry?" dialog (assuming we're in a context where retrying is possible -- sometimes you'll get calls from contexts that can't be called back). I'm needinfoing Darrin here, since he's doing the UX for Loop.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #7) > This is a UX bug ;-) > > The OpenH264 plugin crashes. We need to associate that crash with one or > more places that we should hang crash reporting UI. If the crash affects a > particular tab, and especially if it affects a particular <video> element > within that tab, we can probably show the existing plugin crash UI. > > If the crash could affect something that is not a normal tab, we need to > understand if and how we want to show the UI, and whether the user needs to > take any other action to recover. I would like to argue that this is fundamentally not that like a plugin crash, since the plugin isn't something that really the user has any conscious awareness of, it's just some piece of machinery we use internally. I think it would make a lot more sense to just treat this like any other kind of internal error.

Process crashes require user opt-in to submit crash reports. Since the crash report is an essential part of fixing problems in the field, we need to show the UI somewhere. Having it be in the context of the thing they were doing is in general the best way to do that. We don't have good internal error reporting for non-crashes currently, but that's something I'm hoping to fix later this year.

I'm going to defer my needinfo to Romain for now, who is the PM for loop desktop. Once the requirements are solidified (which set of errors? which should the user see? etc.) I can take this bug back and incorporate the required UI into the design spec.

This actually isn't a Loop issue. The vast majority of WebRTC (and hence H.264) usage will be non-Loop. Rather, it's a WebRTC platform issue. Effectively, it's a crash of a piece of Firefox. It seems that Romain is the PM for that too, though. Maybe I'm digging a deeper hole, but say we really had E10S working completely and so different tabs and even different IFRAMES could be in the same process. How do we report crashes of those? Is your idea that it's within the defined visual context of the tab/iframe so nobody cares? What about service workers?

When e10s tab(s) crash we show the crash report UI in the context of those tab(s), yes. Are service workers a separate process? I believed that they were still thread-based.

Just to put a finer point on what was already said, we don't want to tie this functionality to Loop. In fact we can release OpenH264 without doing anything special with Loop. So I'd prefer to start simple and then build on it. For this bug, can we show a simple message for the process crash in the tab where it happened? (Nothing Loop specific, just generic and simple). For Loop, I'd like to file a separate, follow on bug that can be prioritize separately -- where we can have a specific call into the Loop code that tells us about the error. There we can design a UX where Loop does something like pop up a "call failed -- retry?" dialog. This follow up bug is where we need Darrin's and Romain's guidance. If we keep this bug simple (and treat it as a Firefox plugin crash), what UX do we need? What questions still have to be answered?

My understanding is that this can occur during call set-up but also during an ongoing call. Also my understanding is that reconnecting to the other peer after the crash is likely to make the problem go away. For the desktop client I mark this as blocking 1030077 (new error notification to the user during an ongoing call allowing him to re-connect to the other peer) and 1000186 (already existing error notification to the user when a failure to connect occurs during call set-up allowing him to retry connecting to the other peer). This won't apply to the link clicker UI given that if you click a link using the Firefox browser you'll be using the desktop client directly UI. There is a scenario if a URL clicker is in a conversation with a Firefox user who experiences a crash, the call should terminate and the link clicker should be notified so he can attempt to reconnect - this has UX but also server side implications. I although believe that for now only the Firefox browser will be supporting H264 and therefore we can ignore this scenario.

(In reply to Romain Testard [:RT] from comment #15) > My understanding is that this can occur during call set-up but also during > an ongoing call. > Also my understanding is that reconnecting to the other peer after the crash > is likely to make the problem go away. > > For the desktop client I mark this as blocking 1030077 (new error > notification to the user during an ongoing call allowing him to re-connect > to the other peer) and 1000186 (already existing error notification to the > user when a failure to connect occurs during call set-up allowing him to > retry connecting to the other peer). > > This won't apply to the link clicker UI given that if you click a link using > the Firefox browser you'll be using the desktop client directly UI. That is not the current behavior of Firefox and it seems reasonably likely that Firefox with H.264 will ship prior to that behavior changing. > There is a scenario if a URL clicker is in a conversation with a Firefox > user who experiences a crash, the call should terminate and the link clicker > should be notified so he can attempt to reconnect - this has UX but also > server side implications. I although believe that for now only the Firefox > browser will be supporting H264 and therefore we can ignore this scenario.

After a discussion with Maire we decided that this bug will be about generic OpenH264 support whereas a new one I created will track specific Loop support for this (1030097). This bug is higher priority than the Loop bug and I therefore remove the Loop dependencies which will be addressed in 1030097 separately once this bug is fixed.

(In reply to Eric Rescorla (:ekr) from comment #16) > That is not the current behavior of Firefox and it seems reasonably > likely that Firefox with H.264 will ship prior to that behavior > changing. > Thanks, in that case I'll address this now on the Loop specific bug so we make sure we inform the user accordingly.

Hi all, This bug got pretty complex with all the loop stuff, but now that it has been pulled into a separate bug, this one is now a lot simpler. After reviewing and cutting through the confusion with bsmedberg, UX's recommendation is to use the same notification bar/UI that appears when NPAPI plugins crash.

We'll need an appropriate string though -- what do we want to tell people at this point?

I don't understand. Is "The Cisco OpenH.264 plugin has crashed" not sufficient? That string already exists.

Hi Madhava, bsmedberg and I discussed this already and feel the current string ("The Cisco OpenH.264 plugin has crashed") is sufficient for the purposes of this bug.