Some concerns were raised after finishing bug 1037162, so let's address them here +++ This bug was initially created as a clone of Bug #1037162 +++ In bug 1031424, we created a spec for screen sharing permissions that can be built within a short time, but only works under some constraints (most notably whitelisting). If we want to make screen sharing more widely available (and improve the general clarity and security of our device sharing), we need to make some adjustments. Here's an (incomplete) list of things to consider: - Sharing the browser is a special high-risk case - It looks like we are currently losing users in the permissions flow. We should find out if those users intentionally don't share anything or if it is a problem with our flow. - Some cases (e.g. sharing single windows or tabs) are not covered yet. - The current panels are a mix of arrowpanel and window

Here's an updated mockup. It expanded quite a bit because of the new requirements. Nonetheless, I think it does a good job at keeping the simple (and common) stuff simple. I'll needinfo a few people for feedback.

Florian, does this address the issues you've raised?

Randell, does this address the issues you've raised?

Michael, since you'll be working on the visual side of this, I'd love to get your feedback early on. I think the styling will be very important here in order to provide structure.

Looking good, Philipp. I believe this is enough for me to get started on the visual side of things.

Great progress! I think you indeed managed to keep the common cases simple while also taking into account all the possible bizarre edge cases. Would the changes proposed here be enough to let us remove the whitelisting for the screensharing feature? (This may be a question more for jesup than for Philipp by the way.) Here's some detailed feedback to clarify details: [meta feedback: for mockups with so many parts, it would be nice to number the images so that I can give precise feedback.] - Not sure about feasibility of the unified global indicator in the Mac menu bar (will check with Mac folks). If it turns out to be excessively difficult, maybe we can keep 3 separate icons but adapt them to reflect the mute status. - Why would we display the global sharing indicator if nothing has been granted yet? That indicator is a popup window on Windows/Linux, as a user I wouldn't want any webpage to be able to show it without me having accepted anything. - Is the string "Control access to camera, microphone and screen" intended to be displayed in all cases? I find the "and screen" part confusing in the context of a website that didn't request screensharing. Also "control screen" is vague; will it let the site change my screen resolution? Display ads outside the browser window? - I'm afraid the microphone meter bar is too tiny to be useful. What's the use case addressed here? Did you really intend to show it on the "request" part but not on the "currently sharing" one? - Should we also try to display a preview of the webcam? (I remember Boriss really wanted that) - Where is the "Never allow" item going? Is it buried in the drop down near "Allow access"? (As a user I'm not sure I would think of looking there.) Are we also changing the behavior of "Never allow" so that it becomes "never prompt" instead of the current "instant deny"? (I know we discussed this before, but I don't remember if we filed a bug) - The order of the icons isn't the same everywhere: in some places you have "camera, mic, screen", in other places you have "camera, screen, mic". Is this intentional? Could be that you have the gray icons always after the orange ones, but I find this varying order slightly surprising. - The order of the devices (in the expanded form where each device has its own "Stop sharing" button) is also not obvious to me. Should we sort by device type? By device name? - The "Stop sharing all devices" wording doesn't seem suitable for the case where only one device (eg. microphone) is being shared. Should we display a different string in that case, or just hide the button? - I'm not sure of the meaning of the "Multiple sites accessing devices" part. Is this when several hostnames on the same tab (with iframes) request devices, or are you suggesting that all webrtc doorhangers should show the streams for all tabs? - Is it possible to have several "Details" sections expended at once? (Assuming we auto-expand the sections with pending requests, 2 different frames requesting devices could lead to that edge case.) - What's the effect of clicking "Details" from the door hanger of the global indicator? Is it focusing the tab and showing the door hanger for that specific tab? Or is it just expending the section like it does when attached to the url bar? I think it's a useful feature to give a way to figure out where the tab using devices is. - I would have a few comments about some icons / some alignment issues on the mockup, but I assume this is not finished and will be covered by Michael's work.

Thanks for the detailed feedback Florian! I'll upload a new mockup shortly. Meanwhile, here are some answers. (In reply to Florian Quèze [:florian] [:flo] from comment #6) > [meta feedback: for mockups with so many parts, it would be nice to number > the images so that I can give precise feedback.] Excellent idea, I'll add those. > - Not sure about feasibility of the unified global indicator in the Mac menu > bar (will check with Mac folks). If it turns out to be excessively > difficult, maybe we can keep 3 separate icons but adapt them to reflect the > mute status. Hm, since all of the items would open the same doorhanger that would be strange behavior. If it really is impossible to do it as in the mockup, perhaps we can combine them into one icon. > - Why would we display the global sharing indicator if nothing has been > granted yet? That indicator is a popup window on Windows/Linux, as a user I > wouldn't want any webpage to be able to show it without me having accepted > anything. That is not the intention. Where do you see that happening? Perhaps the confusion comes from the fact that the indicator in the tab bar and the global indicator now look the same? > - Is the string "Control access to camera, microphone and screen" intended > to be displayed in all cases? I find the "and screen" part confusing in the > context of a website that didn't request screensharing. Also "control > screen" is vague; will it let the site change my screen resolution? Display > ads outside the browser window? You're right. The string should only list the devices that sites have requested access to. I changed that in the mockup. About »control screen«: I tried to mitigate that by phrasing it »Control access to screen« but I'm open to any suggestions here. > - I'm afraid the microphone meter bar is too tiny to be useful. What's the > use case addressed here? Did you really intend to show it on the "request" > part but not on the "currently sharing" one? The use case I had in mind was »Is this the right microphone? Does it get input?«. I agree that it is inconsistent to show it in one place but not the other. > - Should we also try to display a preview of the webcam? (I remember Boriss > really wanted that) I honestly didn't find a good way to integrate it without making the whole thing gigantic. But I see the value and I'll try again. > - Where is the "Never allow" item going? Is it buried in the drop down near > "Allow access"? (As a user I'm not sure I would think of looking there.) > Are we also changing the behavior of "Never allow" so that it becomes "never > prompt" instead of the current "instant deny"? (I know we discussed this > before, but I don't remember if we filed a bug) Good catch! It should definitely become »Never ask«. A menu next to the Deny button seems to be a good place for this. > - The order of the icons isn't the same everywhere: in some places you have > "camera, mic, screen", in other places you have "camera, screen, mic". Is > this intentional? Could be that you have the gray icons always after the > orange ones, but I find this varying order slightly surprising. The idea was to show them in the order that access has been requested. That way the icons don't change order during one session (which I think would be worse than changing order between sessions). As a side effect of that, the grey icons (no access granted yet) are always on the right. > - The order of the devices (in the expanded form where each device has its > own "Stop sharing" button) is also not obvious to me. Should we sort by > device type? By device name? Same as above. > - The "Stop sharing all devices" wording doesn't seem suitable for the case > where only one device (eg. microphone) is being shared. Should we display a > different string in that case, or just hide the button? I wouldn't hide or disable the button altogether. If possible, we should also avoid switching labels. The only downside I could imagine is that »Stop sharing all devices« could lead some users to the conclusion that other devices are shared that they don't know about. I'm not sure how real that concern is… > - I'm not sure of the meaning of the "Multiple sites accessing devices" > part. Is this when several hostnames on the same tab (with iframes) request > devices, or are you suggesting that all webrtc doorhangers should show the > streams for all tabs? I'm suggesting being able to control everything from anywhere. Of course only the context relevant section would be automatically expanded. > - Is it possible to have several "Details" sections expended at once? > (Assuming we auto-expand the sections with pending requests, 2 different > frames requesting devices could lead to that edge case.) I'd avoid that if possible. Could we auto-expand the first request and then, after the user has taken action on it, expand the second one? There's the edge case of the user not making any choice, but even in that case he can see the request in the collapsed sections. > - What's the effect of clicking "Details" from the door hanger of the global > indicator? Is it focusing the tab and showing the door hanger for that > specific tab? Or is it just expending the section like it does when attached > to the url bar? I think it's a useful feature to give a way to figure out > where the tab using devices is. It should just open the section (all these doorhangers should effectively look and behave exactly the same way). A »Show page« link is a great idea though – I'll add that. > - I would have a few comments about some icons / some alignment issues on > the mockup, but I assume this is not finished and will be covered by > Michael's work. Yes, that will be addressed when Michael makes this awesome :)

(In reply to Philipp Sackl [:phlsa] from comment #7) > > - Not sure about feasibility of the unified global indicator in the Mac menu > > bar (will check with Mac folks). If it turns out to be excessively > > difficult, maybe we can keep 3 separate icons but adapt them to reflect the > > mute status. > Hm, since all of the items would open the same doorhanger that would be > strange behavior. If it really is impossible to do it as in the mockup, > perhaps we can combine them into one icon. I'm really not sure what's possible there. Currently the icons we add in the menubar only support showing a native OS X menu; doing anything else (eg. showing our doorhanger) will need help from our Mac developers. I'll need to talk with them to see what they can do. > > - Why would we display the global sharing indicator if nothing has been > > granted yet? That indicator is a popup window on Windows/Linux, as a user I > > wouldn't want any webpage to be able to show it without me having accepted > > anything. > That is not the intention. Where do you see that happening? The gray image labeled "Sharing requested but not yet granted", it is larger than the url bar indicator displayed in the image labeled "Sharing indicator in the location bar", so I assumed it was the global indicator. > About »control screen«: I tried to mitigate that by phrasing it »Control > access to screen« but I'm open to any suggestions here. Suggestion: "Control screen capture". Not sure if it's better though :). > > - I'm afraid the microphone meter bar is too tiny to be useful. What's the > > use case addressed here? Did you really intend to show it on the "request" > > part but not on the "currently sharing" one? > The use case I had in mind was »Is this the right microphone? Does it get > input?«. The use case I have in mind for a microphone meter is "am I currently audible or should I move closer to the microphone?". > > - Should we also try to display a preview of the webcam? (I remember Boriss > > really wanted that) > I honestly didn't find a good way to integrate it without making the whole > thing gigantic. But I see the value and I'll try again. I have mixed feelings about the webcam preview actually, because that could mean the webcam (the green light) gets started automatically when a web page requests camera access; which could be a bad surprise. Or maybe we should just have a "Preview" button/link and have the panel expand if the user clicks it. > > - The order of the icons isn't the same everywhere: in some places you have > > "camera, mic, screen", in other places you have "camera, screen, mic". Is > > this intentional? Could be that you have the gray icons always after the > > orange ones, but I find this varying order slightly surprising. > The idea was to show them in the order that access has been requested. Ok, that sounds like 'not sorting at all', which indeed can make sense to match what the user has memorized. > > - The "Stop sharing all devices" wording doesn't seem suitable for the case > > where only one device (eg. microphone) is being shared. Should we display a > > different string in that case, or just hide the button? > I wouldn't hide or disable the button altogether. > If possible, we should also avoid switching labels. The only downside I > could imagine is that »Stop sharing all devices« could lead some users to > the conclusion that other devices are shared that they don't know about. I'm > not sure how real that concern is… Idea (not sure if it's good) : Make this button just "Stop sharing", and make the stop sharing buttons of each device less prominent (maybe just an [X] icon?). > > - I'm not sure of the meaning of the "Multiple sites accessing devices" > > part. Is this when several hostnames on the same tab (with iframes) request > > devices, or are you suggesting that all webrtc doorhangers should show the > > streams for all tabs? > I'm suggesting being able to control everything from anywhere. This feels strange to me, as this piece of UI is attached to the URL bar. I would almost suggest that when clicking "details" and expending a section, we should switch tab at the same time. But that would potentially not even keep the doorhanger in the same place on the screen if the relevant tab is in a different window. How would we represent 2 different tabs of the same domain using the same devices at the same time?

Mockup with updates…

(In reply to Florian Quèze [:florian] [:flo] from comment #8) > (In reply to Philipp Sackl [:phlsa] from comment #7) > > About »control screen«: I tried to mitigate that by phrasing it »Control > > access to screen« but I'm open to any suggestions here. > > Suggestion: "Control screen capture". Not sure if it's better though :). I used that for now. It's definitely a step into the right direction :) > > > - I'm afraid the microphone meter bar is too tiny to be useful. What's the > > > use case addressed here? Did you really intend to show it on the "request" > > > part but not on the "currently sharing" one? > > The use case I had in mind was »Is this the right microphone? Does it get > > input?«. > > The use case I have in mind for a microphone meter is "am I currently > audible or should I move closer to the microphone?". You're right, I now included the meter in all active microphone icons. It should be big enough to get a basic low/medium/high reading, which should be an appropriate amount of information. > > > - Should we also try to display a preview of the webcam? (I remember Boriss > > > really wanted that) > > I honestly didn't find a good way to integrate it without making the whole > > thing gigantic. But I see the value and I'll try again. > > I have mixed feelings about the webcam preview actually, because that could > mean the webcam (the green light) gets started automatically when a web page > requests camera access; which could be a bad surprise. Hm, I was thinking of perhaps having video previews in the dropdown (like with windows for screen sharing). But I think that would get too busy. > > > - I'm not sure of the meaning of the "Multiple sites accessing devices" > > > part. Is this when several hostnames on the same tab (with iframes) request > > > devices, or are you suggesting that all webrtc doorhangers should show the > > > streams for all tabs? > > I'm suggesting being able to control everything from anywhere. > > This feels strange to me, as this piece of UI is attached to the URL bar. > > I would almost suggest that when clicking "details" and expending a section, > we should switch tab at the same time. But that would potentially not even > keep the doorhanger in the same place on the screen if the relevant tab is > in a different window. > > How would we represent 2 different tabs of the same domain using the same > devices at the same time? After some back and forth, I'm pretty sure that we should limit tab switching as much as possible. It's hard to keep track of where you're going and the closing/opening of the doorhanger becomes distracting. The doorhanger always opens only with the section for the current page expanded. Getting into a different section is a very deliberate action, so it shouldn't be confusing. As for the case with two tabs of the same domain: I added a tooltip to the sections that shows the page title.

Comment on attachment 8483589 [details] Mockup v1.2 Overall: I really like it. The "revoke access" option is missing in #3 The audio level option is nice to have, but we may have to defer that. we'll have to see. It is technically possible (and something similar for video is also technically possible, though there may be more delay between changing the drop-down selection and seeing a frame capture.) Again, that might have to wait. (technically, we'd tell the backend to open the selected device and send back level data, or snapshot frames for video). You need to think hard about selecting windows that are not (currently) visible (hidden behind others or behind the dropdown you're using(!)) Perhaps the thumbnailing concept would help here (capture a thumbnail for each enumerated window. It should be asynchronous so as to not block putting up the requester.) Again, this would be a nice-to-have. Also, the thumbnails would not be live; they'd be point-in-time captures. (Mic level would be live, and maybe camera would be a low-fps series of snapshots (1fps?) - all assuming we have them.) There may be a security requirement if we start moving past whitelists for browser windows to require extra steps to share, so some anticipation of that might be required.

This should address the remaining issues.