User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:25.0) Gecko/20130710 Firefox/25.0 (Nightly/Aurora) Build ID: 20130710030205 Steps to reproduce: * Request camera and/or mic access with getUserMedia. * The camera/mic permission dialog will be displayed in firefox. * Alt+Tab or click on another window. You can try this scenario out by logging in to https://gittogether.com, click on "Test Call" and start a call. Actual results: The permission dialog disappears causing the user to be stuck. Expected results: The permission dialog should not disappear.

I'm able to reproduce this bug on MacOS X. The permission dialogue by reloading the page and clicking the test call button again. I'm not sure if this would be a Core:DOM or a WebRTC bug, though.

The permissions pane that opens when you make a call in gittogether using WebRTC.

After clicking anywhere out of this tab in Firefox, the permissions pane disappears. The huge green arrow remains, though! Go, huge green arrow!

The behavior is the same in Firefox 22 and in the current Nightly.

> The permission dialog disappears causing the user to be stuck. The user is not stuck, the permission dialog is merely "minimized". Clicking on the camera icon in the URL bar makes it visible again. It seems like getUserMedia inherited this behavior from Geo-location, which works the same way, so there is a chance that this is by design. - Let me ask (need-info) someone who may know. I agree with you it is confusing, as I myself got confused by it ~20 times before I managed to deduce how I could bring it up again. > I'm not sure if this would be a Core:DOM or a WebRTC bug, though. If this is a bug, then DOM I think. If this is a feature gUM inherited from Geo-location, then it might be worth re-asking 1) whether the same behavior fits gUM, 2) whether the behavior should differ, or 3) whether this new use-case makes us rethink the original behavior (as a bug). As it is now, the panel effectively turns into a very subtle button (at least on desktop) if you leave and come back to the tab/window. - I can sort of see how that might be OK for Geo-location, since knowing the user's location is often not critical to using an application (though for some apps, it may be). It seems wrong for gUM, though one might argue that gUM may be more ancillary in future apps than it is in most current apps. Google Chrome's dialog strikes a different bargain with it's own issues (harder to spot initially but persists). I'll let others decide.

Like comment 5 says, this is how all popup notifications behave by design. They aren't modal dialogs. When they "disappear", the notifications aren't gone but can be re-opened by the user by clicking their anchor icon.

The problem is that our users are completely confused by this. None of them have figured out that you can re-open the gUM prompt when it disappears and they end up being stuck in a state where they think they are making a call (it is ringing), but it will never succeed (unless they somehow found the anchor icon, which they never do).

Even though this behaviour maybe by design, it is confusing to normal users. I would request the usability team to take a look at this and see if it can be made better.

I'm afraid this is a design choice that's inherent to popup notifications. If we made the popup more persistent, we'd also make it more annoying, and would probably be better served with a tab-modal prompt.

Dao - Yes notification may not be the right way to do this then. When you call getUserMedia(), the user has to complete the action by a allow/deny and it needs a modal. Let us know the right way to handle this. Do you want us to file a separate bug request?

We can re-purpose this bug. It's a little tricky, because getUserMedia isn't that different from other content permissions, so what to do for getUserMedia probably can't be answered in isolation.

This is a thorny problem. I doubt UX will go for a modal dialog that blocks users, as we're moving away from those. Maybe instead we could add a mechanism to help content react and account for when the popup is minimized? That way at least the big green arrow could be moved to point to the head of the URL bar where the user must click rather than the big gap where the popup used to be. Or perhaps a gUM constraint that provides "Fail on Access minimized"? Sorta modal. I'm thinking of workarounds until this gets resolved: You could poll document.hasFocus() in a SetInterval() function while the green arrow is up to detect if the browser looses focus, and if it does, reposition your big green arrow to point to where the head of the URL bar where the access button usually is. - Don't know if that catches switching to other tabs.

We thought about moving around the "big green arrow". We won't be able to point exactly at the head of the URL bar since we can't position it outside of the browser window though (it's just HTML/CSS).

We will probably have to move it below the url bar in the browser window with a text that says 'Click on the video icon'.

(In reply to Jan-Ivar Bruaroey [:jib] from comment #12) > This is a thorny problem. I doubt UX will go for a modal dialog that blocks > users, as we're moving away from those. > > Maybe instead we could add a mechanism to help content react and account for > when the popup is minimized? That way at least the big green arrow could be > moved to point to the head of the URL bar where the user must click rather > than the big gap where the popup used to be. This sounds like a weird workaround for a fundamentally flawed design. If content actually needs the user to react before it can move on, then the permission dialog should just be modal. Historically, such dialogs were frowned upon because they blocked the whole browser UI, but in this case the dialog would only block content in the current tab.

I think "modal" (user cannot click anywhere else until they dismiss the dialog) is too restrictive for what's needed here. The problem is that the option for moving forward is obscured, but the user has many other options for moving around or clicking other buttons. No need to reduce the choices down to two IMHO. If the popup never minimized for gUM, or came back after a few seconds after being minimized (so you could see below it) or when the user re-engaged with the page after leaving it) then I think we'd have what we need here.

(In reply to Jan-Ivar Bruaroey [:jib] from comment #16) > If the popup never minimized for gUM, or came back after a few seconds after > being minimized (so you could see below it) or when the user re-engaged with > the page after leaving it) then I think we'd have what we need here. This sounds like a more annoying poor man's modal dialog and contradicts the basic idea of popup notifications: that you can ignore them and get them out of your way easily.

It would be more persistent, not modal, which is not the same thing. You'd still be allowed to click elsewhere. But yeah it might be annoying if it isn't tuned right. I agree you want to be able to ignore popups, except when you don't, like in the case of vline's web page, which is a dedicated calling app that doesn't do anything useful without this permission. When you make a call here you don't want to ignore the popup. But not all web pages need be like that. Other web pages may have camera as merely an optional benefit, like a game or a customer service page that also offers text chat and document sharing for instance. In those cases, a modal dialog seems wrong. And if we offered web pages a choice of behavior, then annoying web pages would choose the more annoying one. --- But the problem seems to be that people don't know that they can click the button at the start of the URL bar. That seems like a flaw with gUM, geo-location AND mixed-content blocking! - Do we have any data that people know about these buttons?

(In reply to Jan-Ivar Bruaroey [:jib] from comment #18) > It would be more persistent, not modal, which is not the same thing. You'd > still be allowed to click elsewhere. But yeah it might be annoying if it > isn't tuned right. You couldn't interact with the part of the page covered by the popup. A popup that reappears unaskedly after being dismissed seems like a no-go to me, no matter how it's tuned. It basically says "feel free to ignore me, but... answer me, please answer me!", which makes it _feel_ modal. It's a workaround for not having the right design at hand in the first place. It's true that there are cases where camera or microphone access was requested without being crucial to a page, but that use case wouldn't really be broken by requiring the user to click "don't share".

> A popup that reappears unaskedly after being dismissed seems like a no-go to me, > no matter how it's tuned. Totally agree. I should have clarified my suggestion: If the user *dismisses* the popup by making a choice or hitting 'x' then it should not come back. If the user *ignores* the popup then I think there is room for tuning to avoid the confusion mentioned when people tab/focus away and don't know how to bring it back. I'm not tied to my suggestion, but in the bottom of Comment 18 I also question whether geo-location and mixed-content popups have the same problem of users not knowing how to un-minimize, because how can the usability trap we hear here NOT apply there as well?

Larissa has some thoughts on improving doorhangers. If we're going to revisit how our permissions UI works, it should be in a holistic context and not as a one-off hack for WebRTC. I know the current UI isn't perfect, but it's the baseline for how this works in Firefox today for a multitude of different permissions.

(In reply to Justin Dolske [:Dolske] from comment #21) > Larissa has some thoughts on improving doorhangers. If we're going to > revisit how our permissions UI works, it should be in a holistic context and > not as a one-off hack for WebRTC. I know the current UI isn't perfect, but > it's the baseline for how this works in Firefox today for a multitude of > different permissions. I agree with Dolske. I think the proposal for multiple degrees of doorhanger notifications will actually address this use case. But I prefer to get everyone on the same page with a consistent proposal rather than doing a one-off. For reference, here is the design-in-progress(may change): http://people.mozilla.com/~lco/Permissions%20UI/130806%20design%20patterns-permissions%20UI.pdf

> http://people.mozilla.com/~lco/Permissions%20UI/130806%20design%20patterns-permissions%20UI.pdf Thanks for the link! - I have some comments (broken up in three parts): USABILITY I like the idea of adding a delay, but not just a small one to avoid accidentally clicking-through. I think a slightly larger delay to disassociate the disappearance of the popup (and its relevance) with anything the user did, is warranted. As users, when we click/press, we worry that we've "moved on" past some point that we cannot return to, at least in our minds ("I did something, how do I undo it?") I like the idea of animating back into the permissions icon, as it begins to address the core usability problem here that users think that the "option to pick permission" is gone. I think we need visibly to convey that the option is still there, and temporally to convey that it didn't go away in response to anything the user did. If we fix those two things, I think we're good. --- Looking at the current animation when the popup appears, I think that the disappearance would have to animate a lot slower. Some blinking or flashing of the icon itself that outlasts the animation by several seconds may help as well. Better yet: how about a second popup that explains what just happened and "here's the icon you click to get it back", with an "[x] I get it" checkbox? CASE STUDIES I would love it if we could add a gUM case-study to your document. It seems appreciably different both in usability respects (for instance, there's rarely an alternate experience, like in geo-location, and there's often no visibly impacted area of the page, like in the case of click-to-play), as well as in audience (lots of people who aren't technically experienced or detail oriented are going to care about making calls). --- DESIGN As to the "multiple degrees of doorhanger": The "Persistent" door hanger type in the doc seems mislabeled, as I can close it without even glancing at it, which doesn't seem very persistent to me. In fact, the "Disappearing" door hanger sounds more persistent when faced with a user who is not idle. As these are the most persistent display types in your doc, I don't see how breaking things out into different display types addresses the usability problem raised here. I think I would prefer one good doorhanger that behaved predictably, with perhaps a range of delays from slow (most pressing) to fast (minor). The doc says "remains onscreen until the user selects an action or dismisses it", which sounds great, except I think it's a stretch to say that the user has dismissed the popup by clicking outside it. I think of "dismiss" as "to order or allow to leave; send away" Since people are accustomed to popups in the world that are more persistent than ours (the "You have Windows/Apple updates" popup comes to mind, which you have to explicitly dismiss by clicking the [x]), I question the premise that any click or press outside the popup marks an intent in the user's mind to dismiss the popup (especially a user who doesn't know how to bring it back). To me, clicking the [x] or a negative choice action button qualifies in my mind as a strong "intent to dismiss", whereas clicking outside it qualifies as a weak "intent to dismiss" at best, or maybe no intent to dismiss at all. Our current design doesn't distinguish between the two. Maybe we could leverage this difference?

Will any of the changes proposed by Larissa be worked into development in the future? The disappearing doorhangers have been a huge usability issue for users of our product, as functionality depends on accepting camera permissions, and users cannot find the permissions.