On B2G, the grant information of gUM is not stored in the permission manager. So that every time when the apps need to use gUM, users have to press the button. It would be convenient for users that installed apps can remember the permission information. So that they don't need to grant the permission when someone calls them through the apps.

(In reply to StevenLee from comment #0) > On B2G, the grant information of gUM is not stored in the permission > manager. So that every time when the apps need to use gUM, users have to > press the button. It would be convenient for users that installed apps can > remember the permission information. So that they don't need to grant the > permission when someone calls them through the apps. This was done for privacy reasons - we can't allow remembering of a permission for gUM for apps until we implement support for permissions management for apps for gUM. This is probably to keep this bug open for enabling it again after we get the necessary permissions management in place.

(In reply to Jason Smith [:jsmith] from comment #1) > This was done for privacy reasons - we can't allow remembering of a > permission for gUM for apps until we implement support for permissions > management for apps for gUM. This is probably to keep this bug open for > enabling it again after we get the necessary permissions management in place. Hi Jason, Thanks for the reply. Is there any bugs or wiki that discussing about the permission management for gUM?

(In reply to StevenLee from comment #2) > (In reply to Jason Smith [:jsmith] from comment #1) > > This was done for privacy reasons - we can't allow remembering of a > > permission for gUM for apps until we implement support for permissions > > management for apps for gUM. This is probably to keep this bug open for > > enabling it again after we get the necessary permissions management in place. > Hi Jason, > Thanks for the reply. Is there any bugs or wiki that discussing about the > permission management for gUM? bug 898986 gives a lot of context behind the permissions management.

We should use this bug to discuss the design and implementation for persistent permission support in gUM on B2G. The B2G Loop app needs persistent permission support.

This should follow the same permission conventions as other APIs. cc'ing Jonas.

(In reply to Lucas Adamski [:ladamski] (plz needinfo) from comment #6) > This should follow the same permission conventions as other APIs. cc'ing > Jonas. IIRC, that got shot down originally when the feature was originally either security reviewed or privacy reviewed (can't remember which one). I think the concern derived from camera & microphone access being considered extremely privacy sensitive, so the conclusion was that remember my choice could be implemented if there was a corresponding easy way to revoke the permissions via something like a permissions manager. Permissions management right now isn't implemented for gUM permissions on Firefox OS, so that's something that needs to be solved first. Once that's solved, we should be able to meet the permissions management requirements to open up gUM to hosted, privileged, and certified apps with remember my choice.

Taking a step back, let's distinguish between apps and the browser. In the app context, as Steven says, we need some way to revoke the app's permissions. I don't know if that exists or not, but if it does, then great. If it doesn't, it should. In the web browser context, we need a way for the user to manage permissions grants for individual sites (as opposed to the browser as a whole) [0]. Once we have that, there's no reason why we can't allow persistent permissions for individual sites though not for the browser as a whole. In the specific case of Loop, I would anticipate that we would eventually want it to be part of the phone and come with automatic permissions to the camera and microphone, just like the camera app does and the dialer implicitly does. In the short term, I guess it will need to be a privileged app so we would want to ask for the permission only once. [0] And as a side note, the persistent grants must only be on HTTPS sites.

We already have a way for users to manage permissions for apps. The UI for this lives in the settings app. We *don't* currently have UI for managing websites permissions. Adding that should be relatively easy but obviously requires some work. We both need to add an API to enumerate all website permissions granted within a particular browser app, and then we need to add UI to the settings app that takes advantage of this API.

(In reply to Jonas Sicking (:sicking) from comment #9) > We already have a way for users to manage permissions for apps. The UI for > this lives in the settings app. Great. Then we should be covered for that. > We *don't* currently have UI for managing websites permissions. Adding that > should be relatively easy but obviously requires some work. We both need to > add an API to enumerate all website permissions granted within a particular > browser app, and then we need to add UI to the settings app that takes > advantage of this API. Note that we are going to need the same thing for desktop, so maybe we can factor out the common code.

(In reply to Eric Rescorla (:ekr) from comment #10) > (In reply to Jonas Sicking (:sicking) from comment #9) > > We already have a way for users to manage permissions for apps. The UI for > > this lives in the settings app. > > Great. Then we should be covered for that. It needs to work first & we already know by QA testing that it doesn't right now when we tried to enable it. The UI is currently disabled for both audio & video. So we need to fix these bugs to get the UI working: * bug 978660 * bug 945111

> Note that we are going to need the same thing for desktop, so maybe we can > factor out the common code. Desktop runs with chrome privileges, so it already has all the platform support it needs. FirefoxOS requires a content exposed API (though obviously limited to certified apps). And desktop doesn't need to worry about multiple browsers etc. So I think there will be very little common code.

(In reply to Jonas Sicking (:sicking) from comment #12) > > Note that we are going to need the same thing for desktop, so maybe we can > > factor out the common code. > > Desktop runs with chrome privileges, so it already has all the platform > support it needs. > > FirefoxOS requires a content exposed API (though obviously limited to > certified apps). > > And desktop doesn't need to worry about multiple browsers etc. > > So I think there will be very little common code. My assumption was that there was some underlying table of permissions by site. But maybe that's just the wrong way to think about it...

There is, it's nsIPermissionManager.

Still, nsIPermissionManager only stores permissions and the "remember me" bit. For gUM don't we also need to remember which device the permission applies to? Ie. "I agree to share my front camera" will not let getUM stream from the back camera?

if we want to separate those we can use "gum-camera-front" and "gum-camera-back" as permission names in nsIPermissionManager.

That should work, same hack we do with the access modes currently. I would prefer if we consider refactoring the permission manager with these use cases in mind. Currently we rely on making sure - when reviewing -that no-one comes up with a permission name that could collide with a generated one.

I'd be happy to see a nsIPermissionManagers rewrite, but that's not something we can rely on here. One thing we should keep in mind though is if we really should have separate permissions for the rear and front cameras. I'm worried that it'll lead to "security dialog fatigue". I.e. it might be worth communicating to the user that access is granted to use both front and rear camera when you push "yes" in the security dialog.

(In reply to Eric Rescorla (:ekr) from comment #8) > In the web browser context, we need a way for the user to manage > permissions grants for individual sites (as opposed to the browser > as a whole) [0]. Once we have that, there's no reason why we can't > allow persistent permissions for individual sites though not for > the browser as a whole. I agree, but I am wary of the UX challenges and limitations we had to get even the limited permissions UX into version 1. Note that this issue applies equally to all apps, not just the browser app - i.e. we already have the issue in FxOS that if an app frames or navigates to a different web origin, any permissions choices remembered by the user are not reflected in any UI in the settings app (the only option to reset the permission is to remove the app). This seems like a good use case to warrant this enhancement if we can get it included though. (In reply to Jonas Sicking (:sicking) from comment #18) > I'd be happy to see a nsIPermissionManagers rewrite, but that's not > something we can rely on here. > > One thing we should keep in mind though is if we really should have separate > permissions for the rear and front cameras. I'm worried that it'll lead to > "security dialog fatigue". I.e. it might be worth communicating to the user > that access is granted to use both front and rear camera when you push "yes" > in the security dialog. I agree - distinguishing between cameras that just seems to complicate things without providing much additional security protection. To try to summarize this thread form above comments: the security requirements for allowing users to be able to remember their gUM permission choice are: - the user must be able to review and edit the permission choice in the future - persistent grants must ONLY available on HTTPS web content (and available for app:// domains) Does that sound ok? So for content on Firefox OS, this translates to: Web Sites (loaded in browser app, window.open etc) - Prompt by default - No option to remember [1] Apps (type=web) - Prompt by default - Allow user to remember choice only if: a) requesting domain matches app domain [1] b) the app's origin is HTTPS [2] App (type=privileged) - Prompt by default - Allow remember choice, but only if requesting domain matches app domain - Default to remember permission choice (this is standard for b2g, but do we need to be more cautious here?) App (type=certified) - Prompt by default - Allow remember choice, but only if requesting domain matches app domain - Default to remember permission choice (this is standard for b2g, but do we need to be more cautious here?) [1] Until we have a way to display and edit permission on a per-site basis, inside apps. Thoughts?

A few corrections on the above proposal from a second read: Web Sites (loaded in browser app, window.open etc) - Prompt by default - No option to remember [1] Apps (type=web) - Prompt by default - Allow user to remember choice only if: a) requesting origin matches app origin [1] b) the protocol of the app's origin is HTTPS or app:// [2] App (type=privileged) - Prompt by default - Allow remember choice, but only if requesting origin matches app origin - Default to remember permission choice (this is standard for b2g, but do we need to be more cautious here?) App (type=certified) - Prompt by default - Allow remember choice, but only if requesting domain matches app domain - Default to remember permission choice (this is standard for b2g, but do we need to be more cautious here?) [1] Until we have a way to display and edit permission on a per-site basis, inside apps. [2] For packaged web apps, do we need to add CSP that enforces SSL for script-src? This sounds complicated to enforce, but important.

(In reply to Paul Theriault [:pauljt] from comment #20) > A few corrections on the above proposal from a second read: > > Web Sites (loaded in browser app, window.open etc) > - Prompt by default > - No option to remember [1] > > Apps (type=web) > - Prompt by default > - Allow user to remember choice only if: > a) requesting origin matches app origin [1] > b) the protocol of the app's origin is HTTPS or app:// [2] At this stage, I wouldn't offer the option to remember for web (neither hosted nor packaged unprivileged). So this would be equivalent to the first case. > App (type=privileged) > - Prompt by default > - Allow remember choice, but only if requesting origin matches app origin > - Default to remember permission choice (this is standard for b2g, but do we > need to be more cautious here?) > > App (type=certified) > - Prompt by default > - Allow remember choice, but only if requesting domain matches app domain > - Default to remember permission choice (this is standard for b2g, but do we > need to be more cautious here?) Hmm... I think that for PROMPT permissions there were an argument some time ago on if they should be pre-allowed for certified apps or not. In any case, this permission is very similar, from a risk perspective to the camera permission (which has camera: {app: DENY_ACTION, privileged: PROMPT_ACTION, certified: ALLOW_ACTION}). I don't think there's really anything an attacker could do with gUM that he cannot do currently with camera. So... whatever we have in place for the camera permission should be enough for this one also. > > [1] Until we have a way to display and edit permission on a per-site basis, > inside apps. > [2] For packaged web apps, do we need to add CSP that enforces SSL for > script-src? This sounds complicated to enforce, but important. I wouldn't go this way. CSP is needed for privileged apps, and in my experience it's being a PITA to tell the developers why they must include all the scripts they use on their app. I wouldn't extend that to all the packaged apps. We could try and enforce a specific CSP when some permission is used but... again I think that would be hell to explain. I believe that, in this case, it's better to just not allow remembering the permission for unprivileged apps and hosted apps or web sites.

(In reply to Paul Theriault [:pauljt] from comment #20) > A few corrections on the above proposal from a second read: Thanks Paul! I assume that in your proposal the idea is having one single permission for both cameras as Jonas suggests in comment 18, is it correct? This would allow users to change from one camera to other during a video call, that seems to be a product requirement.

Yes - to be clear, we currently have audio-capture and video-capture permissions in the permission table [1]. I don't feel like we need any more granularity than that from a security perspective. Hmm but that said, the user still needs to be able to switch cameras - on desktop the choice of camera is integrated into the prompt. On Firefox OS, there is no choice in the prompt yet (afaik, not sure what the plan is here). But lets assume for a second the camera choice was in the prompt - if we persist the permission the user is no longer shown a prompt. So I assume the app will need a way to programmatically change cameras? Is that the plan or I am off base here.

(In reply to Paul Theriault [:pauljt] from comment #23) > Hmm but that said, the user still needs to be able to switch cameras - on > desktop the choice of camera is integrated into the prompt. On Firefox OS, > there is no choice in the prompt yet (afaik, not sure what the plan is > here). But lets assume for a second the camera choice was in the prompt - if > we persist the permission the user is no longer shown a prompt. So I assume > the app will need a way to programmatically change cameras? Is that the plan > or I am off base here. Thanks Paul! The camera change is already implemented, you can check it in the camera application in a device with two cameras such as the Peak.

Assign to Omega from UX for the UX design. Hi Omega, Please help to provide the UX design for the "remember my choice support" in gUM permission prompt. Feel free to ask questions in this bug if any. Thank you.

As my understanding we can use the existing UI in Settings (correct me if I'm wrong), so here is a quick UX proposal. Let me know your feedback, thanks!

(In reply to Antonio Manuel Amaya Calvo (:amac) from comment #21) > At this stage, I wouldn't offer the option to remember for web (neither > hosted nor packaged unprivileged). So this would be equivalent to the first > case. I would like to err toward this approach too - any objections from the webrtc people for this approach - at least until we have support for reviewing/changing permissions on a per-page basis, in addition to a per-app basis? > Hmm... I think that for PROMPT permissions there were an argument some time > ago on if they should be pre-allowed for certified apps or not. In any case, > this permission is very similar, from a risk perspective to the camera > permission (which has camera: {app: DENY_ACTION, privileged: PROMPT_ACTION, > certified: ALLOW_ACTION}). I don't think there's really anything an attacker > could do with gUM that he cannot do currently with camera. So... whatever we > have in place for the camera permission should be enough for this one also. (That's a surprise, I wasn't aware of this change - it was deny before bug 982777) I do agree though agree camera should be same as gUM, which is what I proposed above, i.e. {app: DENY_ACTION, privileged: PROMPT_ACTION,certified: ALLOW_ACTION} I assume we keep the prompt separate for camera and video-capture ? This may be confusing to the user though since if an app requests both camera and video-capture, there will be presumably two separate entries in the settings app? > I wouldn't go this way. CSP is needed for privileged apps, and in my > experience it's being a PITA to tell the developers why they must include > all the scripts they use on their app. I wouldn't extend that to all the > packaged apps. We could try and enforce a specific CSP when some permission > is used but... again I think that would be hell to explain. I believe that, > in this case, it's better to just not allow remembering the permission for > unprivileged apps and hosted apps or web sites. Sounds fair enough to me, lets keep it simple and not allow remembered choices in regular web apps. (again until we have a way to revisit permissions on a per-origin basis in Firefox OS)

(In reply to Omega Feng [:Omega] from comment #26) > Created attachment 8403045 [details] > UX-proposal.png > > As my understanding we can use the existing UI in Settings (correct me if > I'm wrong), so here is a quick UX proposal. Let me know your feedback, > thanks! So that's basically what I was expecting too. But we need to consider what this will look like when an app requests both video-capture and camera permission. Maybe we should avoid the distinction for the user, as two camera permission settings/prompts will be confusing?

(In reply to Paul Theriault [:pauljt] from comment #28) > So that's basically what I was expecting too. But we need to consider what > this will look like when an app requests both video-capture and camera > permission. Maybe we should avoid the distinction for the user, as two > camera permission settings/prompts will be confusing? Yeah, it's simpler to use only one permission for both video-capture and camera.

Shouldn't we also be considering the ability to remember the audio permission? gUM allows to specify an audio only request [1], and so the permission dialog is different in that case. [1] https://developer.mozilla.org/es/docs/Web/API/Navigator.getUserMedia#constraints

If an app requests only audio permission, the wording should be different. I'll think it over and make a more detailed spec for this.

Here is the UX spec. Please see if you have any comments, thanks!

Hey Omega, thanks for the UX spec! I have some nits: On page 5 the string for Audio+Video is "%AppName would like to access your cameras". Shouldn't it be more explicit and say that it wants the microphone too? My impression as a security person (i.e. paranoid tinfoil hat wearer ;-)) is that we shouldn't keep this unmentioned.

Will wait for couple days for people to review the spec. and see if there is any questions or concerns. Hopefully we can start the implementation on this feature by next week which is sprint 1 of Firefox OS 2.0

FYR, current camera/mic string is: `Would you like to share your camera and microphone with {{app}}` https://github.com/mozilla-b2g/gaia/blob/master/shared/locales/permissions/permissions.en-US.properties#L55 Most permission messages share 'Would you like...' pattern. Please consider them if UX like to change other permission strings as well for consistency.

Another comment on the UX spec: Unlike in Firefox, if an app asks for Audio+Video there is no way to allow just one and deny the other. This use case should be included as well.

(In reply to Omega Feng [:Omega] from comment #32) > Created attachment 8409610 [details] > [1.5 Settings] App Permissions v1.0.pdf > > Here is the UX spec. Please see if you have any comments, thanks! So I am not a designer, but this UX seems to be going on the wrong direction by adding an additional prompt to select the camera. IIUC The point of this bug is removing the prompt, so apps the user trusts can use camera/microphone _without_ having to prompt the user. Maybe I am wrong about this, but allowing the user the remember the prompt for the permission, but then still prompting them about which camera they want to use every time doesnt seem like much of an improvement to me. Obviously if we don't prompt, we still need a way to choose a camera when the permission has been remembered. Is there a programatic way for an app to select which camera it wants? Or maybe we need chrome in the system/settings app, for the user to choose their 'default' camera, with a convenient way to change this. Can someone from the webrtc comment on this?

As far as I know, our API already allows the App to specify which camera to access in programmatic way. The case in this spec. is assuming that the App (that asks for the permission) does not specify the camera in programmatic way. Thus, we need another prompt for users to select the right one to get the expected media. If the app can following the step to specify the camera (main or front one), there won't be second prompt for the users to select camera. It's up to the app to use our gUM API. If second prompt does not make sense, how about we can just pick up a default camera (always main one) if the App does not specify which camera to access

This seems reasonable, though somewhat annoying to users. There are some complications, however, in leveraging a camera selection constraint to suppress a prompt on mobile. On desktop (and desktop-focused apps), the application is unlikely to ever specify a camera (and the only reasonable way to do so would be by ID, which would break if you changed your camera - and we don't support this yet). However, on desktop, we can default to the default OS camera for pages/apps given persistent permission -- and most desktops/laptops have one camera. This leaves mobile (which often has 2 cameras.) FxOS-focused apps (and perhaps mobile-focused apps) may include a facing mode constraint, but this is tricky: if it's a mandatory constraint, then it will fail (and fail to acquire a camera at all) on desktop and on any browser not implementing facing mode, or if the device doesn't have a device of that mode (like requesting user-facing and there's only environment-facing). So mandatory constraints are bad. If it's an optional constraint, we could suppress a prompt and not fail in the instances above - but then the user has no ability to override the setting, which some apps may assume they can do (i.e. if an optional constraint is assumed by the app to set an overridable default). The app itself would need to include options for setting the camera to use. Given the user is predicated on having given persistent permission to the app, this may be ok, but realize the app has no knowledge the user gave persistent permission, and may not give the user that selection ability. One reason we should not suppress in any case where persistent permission was not granted: A privacy issue would be that the user wouldn't know which camera was being enabled until it was actually live (and perhaps not even then if the app doesn't show a local image). This (and avoiding extra selection actions required of a user) is why selection and permissions are merged in all other implementations we have so far. So I'm not sure we can get away with suppressing the prompt in the general case (non-persistent permission-granted) For privileged/built-in apps and for mobile apps that have been granted persistent permission, this shouldn't be an issue.

Let me explain more about p.6 of the UX spec. Normally, when a well-designed app requests camera, it specifies which camera (front or rear) it wants. This kind of apps need the first dialog only. When a bad-designed app requests camera, it doesn't specify which camera it wants, so it needs the second dialog. We have 3 proposals for this case: 1) Use a combined dialog with permission and camera selection. (current implementation) 2) Separated dialogs: one is permission, and the other is camera selection. (which in p.6 of the UX spec) 3) We force a default (rear camera), so there is only permission dialog. (the simplest UX) After discussion, we want 3) most, however it may face some technical limitation issue if we want to do it now. For 1), the combined dialog is too ambiguous because the "remember my choice" checkbox doesn't and shouldn't remember the camera selection. So we suggest using 2) for now. Yes, 2 successive dialogs are annoying in proposal 2), but it happens not so often. First, because we are talking about apps, not websites, we can assume the bad-designed apps are just few. Second, for each bad-designed app, user will see the 2 successive dialogs for only one time (at the first time) if he remembers the permission.

Here is the 3 proposals mentioned in comment 40.

I don't like the distinction between a "well-designed app" and a website. In the end, we want websites to behave like apps, so we shouldn't require an extra step for them to feel native in our OS. My concern about not being able to just share one or the other (or both) when audio+video is requested has still not been addressed. I find this important, not only for privacy reasons.

(In reply to Frederik Braun [:freddyb] from comment #42) > I don't like the distinction between a "well-designed app" and a website. In > the end, we want websites to behave like apps, so we shouldn't require an > extra step for them to feel native in our OS. Sorry for being so blunt: I now realize this was about properly stated constrains in the gUM call ;)

(In reply to Omega Feng [:Omega] from comment #40) > Let me explain more about p.6 of the UX spec. > > Normally, when a well-designed app requests camera, it specifies which > camera (front or rear) it wants. This kind of apps need the first dialog > only. > When a bad-designed app requests camera, it doesn't specify which camera it > wants, so it needs the second dialog. I think I get your point here, but I don't think 'well-designed' is really the right wording here. Given that Firefox desktop and mobile both don't require the facing constraint to be set, FxOS would be the exception, rather than the normal case. (but this is true anyways, by virtue of allowing remembering of the gUM permission) > > We have 3 proposals for this case: > 1) Use a combined dialog with permission and camera selection. (current > implementation) > 2) Separated dialogs: one is permission, and the other is camera selection. > (which in p.6 of the UX spec) > 3) We force a default (rear camera), so there is only permission dialog. > (the simplest UX) Personally I much prefer option 1 since it avoids the double prompt. Prompt fatigue is issue, and note that for most content (web pages and regular web apps) we will not be allowing remembering the permission, so they will _always_ see two prompts. > > After discussion, we want 3) most, however it may face some technical > limitation issue if we want to do it now. For 1), the combined dialog is too > ambiguous because the "remember my choice" checkbox doesn't and shouldn't > remember the camera selection. So we suggest using 2) for now. > Yes, 2 successive dialogs are annoying in proposal 2), but it happens not so > often. As above, unless I mistaken, it happens every time for regular web pages and web apps. First, because we are talking about apps, not websites, we can assume > the bad-designed apps are just few. Second, for each bad-designed app, user > will see the 2 successive dialogs for only one time (at the first time) if > he remembers the permission. As with freddy, I would also prefer that we consider both audio and video options in the prompt, as we do on other platforms (e.g. FF Android: https://hacks.mozilla.org/wp-content/uploads/2013/09/prompt.jpg ) Im not sure this is essential, but it would seem to me to be better to be consistent with the UX on other platforms.

Hi Paul, Thanks for the discussion here. It looks like the proposal one is much preferred according to the comments above. If there is no further concerns or objection, I will find resource to start the implementation.

Option one is preferable to me, but as I said above can we please consider showing both audio and video options on the prompt, as we do on other platforms?

(In reply to Paul Theriault [:pauljt] from comment #46) > Option one is preferable to me, but as I said above can we please consider > showing both audio and video options on the prompt, as we do on other > platforms? I should note we don't ask about "which mic" on Android either; we let normal defaults happen (bluetooth/headsets when plugged in/connected, else primary mics). I think this is an unnecessary complication for the user here even if we could do it. The only interesting part for users is output selection (speakerphone mode), which is a separate issue which still requires work on general media elements. We and Google came to an agreement in principle on how to handle this recently (channels, basically, with options to enumerate), but we haven't implemented it yet on any platform.

need earlier to unblock testing several loop cases. Ivan asking fred if he can take. no later than end sprint 2 (20th of this month) target. Need to know if Fred can take priority and estimate.

Thanks Fred for taking this bug and he will start the implementation in sprint 2.

Please use the proposal one in the latest attached UX spec. (uploaded on 4/30)

Can we reconsider the option chosen and go for option 3 instead of option 1? The reason is that the library we are using for Loop from our WebRTC partner does not include the option to select a camera yet, and that implies user should be always prompted when receiving or making a call. I think that an extra prompt every time a call is made is bad for the user. We are working to get the partner to support camera selection, but given the tight timescales we have I’d prefer to be on the safe side.

(In reply to Ivan Tsay (:ITsay) from comment #38) > As far as I know, our API already allows the App to specify which camera to > access in programmatic way. The case in this spec. is assuming that the App > (that asks for the permission) does not specify the camera in programmatic > way. Thus, we need another prompt for users to select the right one to get > the expected media. > > If the app can following the step to specify the camera (main or front one), > there won't be second prompt for the users to select camera. It's up to the > app to use our gUM API. > > If second prompt does not make sense, how about we can just pick up a > default camera (always main one) if the App does not specify which camera to > access Hi Ivan! Correct me if I'm wrong, but for changing the camera during a WebRTC communication, we should change the 'constraints' previously defined (actually we are defining the constraint when asking about which camera we want to use). Change the constraints on the fly is based on the 'applyConstraints' method, which is not implemented yet [1] On the other hand, for listing the cameras available I guess you want to use 'mozCamera'[2], due to 'MediaStreamTrack.getSources' is not implemented as well... Do you know other way of changing programmatically from one camera to another? We are doing some tests for Loop and this is a feature that definitely we want to have. Thanks! [1] http://mxr.mozilla.org/mozilla-central/source/dom/webidl/MediaStreamTrack.webidl#42 [2] https://developer.mozilla.org/en-US/docs/Web/API/CameraManager.getListOfCameras

Borja: Constraints for facing mode are supported; but this requires a new getUserMedia call to switch, and thus a new PeerConnection. The sequence to switch now would be roughly: // On Desktops you can do this much later (right before SetRemoteDescription(), but not (all) Android/B2G old_mediastream.stop(); // This assumes you can't run both cameras at once. getUserMedia(different_facing_mode, success, failure) ... success(new_mediastream) { new_pc = new RTCPeerConnection(...); new_pc.addStream(new_mediastream); new_data_channel = new_pc.createDataChannel(....); new_data_channel.onMessage = ... etc; new_pc.createOffer(offer_ready, failed, constraints); } offer_ready(offer) { new_pc.setLocalDescription(offer, set_local_done, failed); old_pc_datachannel.send(offer); } set_local_done_and_answer_received_on_old_datachannel(answer) { new_pc.setRemoteDescription(answer, call_up, failed); old_pc_datachannel.close(); old_pc_datachannel = null; old_pc.stop(); old_pc = null; remote_video.mozSrcObject = null; etc } call_up() { // reassign things to make new_pc* the current pc* (datachannel, etc) // handle onaddstreams, etc. } The other side would create a new PeerConnection but re-use the existing MediaStream from gUM with it. Note this is also almost the same sequence used to add or remove video from a call. I've left out any ICE trickle processing; an exercise for the reader. You can send the new offer/answer via a server instead if you want the server to see it, but that will add delay in switching.

Update from Ivan 5/7: It is the Gaia work and Fred will start to implement it next Monday. Current estimation is around 1 week to land the code

After some initial work, I found existing layout is not fully sufficient for this scheme. ex: missing icon and the wording is not reflect current description. Will there be a more detailed UI spec or a further discussion that could help us implement it right? @Omega I need your help for: Confirm Test cases (Spec) if I understand it right: * in web mode still not show 'remember my choice' option on prompt * in app mode should show 'remember my choice' on prompt * in app mode should show with extra line 'Select a camera for %AppName' on prompt * show different dialog when in app mode and the choice is remembered provide correct UI: * check if the space is enough for extra lines... * the correct description * should `select a camera` dialog also come with an icon?

WIP, need add unit tests Could be used for gecko test

Reading your last comments, it seems that option 1 is the chosen one... As I say in Comment 51, option 3 would be better for Loop Mobile Client. Paul, what do you think?

The latest UX spec update.

@omega could you help find a designer to give some advice about proper layout space and font size since new spec involve some UI change?

@omega, please also help confirm the general permission dialog layout and space. Thanks!

Comment on attachment 8421483 [details] cam-selector.png A quick feedback: Use checkbox instead of switch, and put it at the beginning of "Remember my choice"

Carol, please give some advice about the proper layout space and font size to the dialogs. Thanks!

(In reply to Maria Angeles Oteo (:oteo) from comment #57) > Reading your last comments, it seems that option 1 is the chosen one... As I > say in Comment 51, option 3 would be better for Loop Mobile Client. > Paul, what do you think? I believe Fred started work on option one based on my comment, and Randal's comment 39 (iiuc). I'm open for discussion, but I'm not sure that we want to go with option 3 just to suit a specific library limitation. As Randal notes in comment 39, mandatory facing constraints cause issues with apps which do no supply them, or expect the browser to be providing chrome to choose the camera. Ultimately this isn't really my call since it isn't really a security issue either way. My feeling is that we should go with option one, since it allows apps to have a promptless UI experience, provided they specify which camera they want to use, but that's just my opinion, and I understand there are constraints on Loop. But ultimately I would defer to the module owner & UX teams here on this decision, with consideration for the needs of Loop. I also note that in comment 40, omega notes that there is some technical limitation in preventing the option 3 UX - Ivan can I ask for you to ask one of the implementers to elaborate on this UX. Is option 3 even an option, technically?

I found a reference that shows combine MediaStreamTrack.getSources() and getUserMedia optional sourceId could specify target camera in **chrome**. Any app that not specify the target camera could fallback to option 1. Once gecko support bellow usage, it's possible to adopt proposal 3. Ref: http://www.w3cplus.com/html5/node-webkit-for-photograph.html ``` var exArray=[]; MediaStreamTrack.getSources(function (sourceInfos) { for (var i = 0; i != sourceInfos.length; ++i) { var sourceInfo = sourceInfos[i]; if (sourceInfo.kind === 'video') { exArray.push(sourceInfo.label); } } }); navigator.getUserMedia({ video: { optional: [{sourceId: exArray[0]}] } }); ```

MediaStreamTrack.getSourceInfos() is going to be replaced by Navigator.getMediaDevices() in next version of gUM spec. However, the information provided by this API doesn't have a canonical way to identify front/back camera. I agree that proposal 3 is the ultimate goal for gUM permission prompt. In order to support proposal 3, Gecko needs to support multi-track MediaStream for WebRTC. In this case, app can retrieve all camera in one MediaStream and enable the suitable track according to the MediaTrackConstraints (which contains the facingMode information). We can only drop the camera selection UI until app developer can fully control the use of front/back camera via WebAPI.

Agree with Shi-Chiang. And let's see how's the discussion going on in tomorrow's meeting. The ultimate goal or the ideal proposal from UX point of view is proposal 3. But users should definitely have freedom to switch camera afterwards. Omega will join on behalf of UX and giving feedback after the meetings if needed.

So, for normal apps, proposal 1 or 2 is good to go. And, gUM is now supporting specifying camera programmatically. The problem is that, for Loop, it seems the partner library has some limitation on specifying camera programmatically. I come out the following solutions: 1) To push the partner library to support specifying camera programmatically. Pro: It's the most reasonable solution since the library should do it sooner or later. Con: Might not make it in time. 2) To add a value in manifest to specify camera (maybe in permissions > camera), so that Loop can do it itself without modifying the library. Pro: Easy to implement. Con: Hard to pass WebAPI team's review. 3) To force OS to specify a default camera (front) for Loop. Pro: Easy to implement. Con: Too hard-coded.

I'm still not sure I'd agree with the comments that option 3 is the "end goal" from a UX perspective, but perhaps it is the goal for apps that tell us "we have in-app camera selection" in the gUM() call. (See below). However, I think Omega's summary in comment 67 is good. Perhaps the best solution is his third one, forcing Loop on FxOS to use the front camera for now. To minimize the "hard-coded" impact of this, we could make it a default that can be overridden by the partner library when it does gain ability to specify. Perhaps add an optional constraint to Loop gUM requests (appended to the end of whatever the partner library gives us) that specifies front camera. Then if the library specifies, it takes precedence; if it doesn't, the default is used. While that works, that simply sets the default camera to use; if we combine that with either a) a rule that says if the app (with persistent permission only?) specifies a camera we suppress front/back prompting or b) a moz-specific constraint to suppress the front/back prompt (mozNoCameraSelection: true); this would indicate which camera will be shared if a permission prompt is shown (and nothing if persistent permission has been granted). We might propose this to the WG as well. Thus we can suppress the prompt for apps that either want a default always, or use in-app selection via constraints. jib, since you've been doing the constraints: comments on this? We're meeting later today to discuss.

Thanks for pointing me to this issue as I wasn't aware of it. Catching up, I have several comments. (I also mentioned this in meeting right now) First off, permission is granted per camera, so proposals like attachment 8415116 [details] that ask which camera to grant access to after after permission has been granted seem confusing to me. I want to see what I'm granting before granting it. Then there's "persistent permissions". In practical terms I think the whole point of "persistent permission" is "don't ask again", so a workflow that asks which camera every time, even when persistent permissions have been granted seems poor. I think "Remember my choice" means, "Remember what I did here in this dialog and don't show it to me again", i.e. "Remember my permission choice AND which camera I chose". e.g. remember that I've granted App X persistent permission to my rear camera, so do that - grant access to rear camera - and never ask again.

See Bug 997365 for info on our facingMode support on mobile.

(In reply to Randell Jesup [:jesup] from comment #68) > I'm still not sure I'd agree with the comments that option 3 is the "end > goal" from a UX perspective, but perhaps it is the goal for apps that tell > us "we have in-app camera selection" in the gUM() call. (See below). > > However, I think Omega's summary in comment 67 is good. Perhaps the best > solution is his third one, forcing Loop on FxOS to use the front camera for > now. To minimize the "hard-coded" impact of this, we could make it a > default that can be overridden by the partner library when it does gain > ability to specify. > > Perhaps add an optional constraint to Loop gUM requests (appended to the end > of whatever the partner library gives us) that specifies front camera. Then > if the library specifies, it takes precedence; if it doesn't, the default is > used. May I know where will this hard-coded constraints will be placed? I expect it'll appear in the client-side JS instead of Gecko. Somewhere like https://github.com/mozilla-b2g/firefoxos-loop-client/blob/master/libs/TB.v2.2.3.1.js#L3044. > > While that works, that simply sets the default camera to use; if we combine > that with either > > a) a rule that says if the app (with persistent permission only?) specifies > a camera we suppress front/back prompting or Yes, I already planned to do so, see Bug 978660.

(In reply to Randell Jesup [:jesup] from comment #68) > Perhaps add an optional constraint to Loop gUM requests (appended to the end > of whatever the partner library gives us) that specifies front camera. Then > if the library specifies, it takes precedence; if it doesn't, the default is > used. > > While that works, that simply sets the default camera to use; On re-reading, yes, while I'm not familiar with the partner library, but if we're able to add/modify constraints like this, then adding a regular non-required facingMode:"user" constraint if none is present effectively changes the default. > if we combine that with either > > a) a rule that says if the app (with persistent permission only?) specifies > a camera we suppress front/back prompting or > > b) a moz-specific constraint to suppress the front/back prompt > (mozNoCameraSelection: true); this would indicate which camera will be > shared if a permission prompt is shown (and nothing if persistent permission > has been granted). We might propose this to the WG as well. > > Thus we can suppress the prompt for apps that either want a default always, > or use in-app selection via constraints. I don't think we need a new constraint here. Make the constraint required (aka mandatory). If the user doesn't have the required camera, your call fails immediately without ever prompting the user, which is good, because you now have more information and can try again. This way the app is always explicit about what it wants, effectively suppressing any cam-selector assistance from Firefox.

We talked to Paul about this issue offline, and the idea is that Loop has a setting to allow user to specify the camera to be used for Video Calls. Loop will try to use it for any video call, so the options we would like to explore are: 1 – Check if Loop can work with current partner library and FF implementation (as Jan-Ivar suggested) so Loop can specify the camera to be used. 2 – Check if we can modify partner library so it can work with current FF implementation so that Loop can specify the camera to be used. If this is not working, we need a workaround to avoid continuous prompting for the camera to be used (e.g. Via remembering the camera chosen or providing a default one), but that is something we would like to avoid.

(In reply to Maria Angeles Oteo (:oteo) from comment #73) > 1 – Check if Loop can work with current partner library and FF > implementation (as Jan-Ivar suggested) so Loop can specify the camera to be > used. Sadly the partner library doesn't allow yet the user to specify the camera for the session. > 2 – Check if we can modify partner library so it can work with current FF > implementation so that Loop can specify the camera to be used. That's the plan until the changes we need get included in next releases.

Comment on attachment 8420814 [details] pull request redirect to github The function is done. Since this patch includes UI change. I'll send review once UX provide detail specs. Please refer app permissions spec 1.1 for usage flow. This PR depends on bug 978660 to provide `detail.isGranted` attribute. Main UI change 1. add permission-title to show app permission/web permission 2. remember-my-choice switch change to checkbox in the left 3. add description for device selection list 4. an extra camera selection dialog that contains [permission title, description, device selection list, single OK button] The change only effect app mode. Main detection logic is in L179. Other changes * test added * remove redundant this.sinon.stub.restore() since each test case is in a sandbox * move all `.hidden` attribute into single style rule

Hi, The attachment is gUM permission Visual Spec. thanks!

UX spec update. Revising message for Video + Audio Adding partial Deny rule Revising button wordings Adding single-camera flow

Thanks carol & omega for providing more detailed UI spec. I've some little question about how to styling `more info...` section, which is shown in geolocation and some other permissions. I'd like to make sure it also looks fine in other permissions dialogs.

I would like the UX to support the "pyjamas use-case": Imagine you want to join a gUM based video session in which the application asks for audio and video, but you want the video to be blank. On Firefox desktop you can just select "no video" on the doorhanger and then click allow. Nobody will see you in your pyjamas, but you are still able to participate ;) Can we get this in there somehow? I know it's tricky and the dialogs are already quite cluttered. But maybe we can save screen space with a dropdown list (instead of radio buttons)?

Hi Frederik, I'll suggest you file another bug for this new requirement.

Comment on attachment 8420814 [details] pull request redirect to github UI updated. Found orientation may cause issue since there're more items in gUM dialog. Since it's an existing issue. Fire at bug 1013854

Got feedback from carol offline. All is well. Thanks!

(In reply to Frederik Braun [:freddyb] from comment #79) > I would like the UX to support the "pyjamas use-case": Imagine you want to > join a gUM based video session in which the application asks for audio and > video, but you want the video to be blank. > On Firefox desktop you can just select "no video" on the doorhanger and then > click allow. Nobody will see you in your pyjamas, but you are still able to > participate ;) > > Can we get this in there somehow? I know it's tricky and the dialogs are > already quite cluttered. But maybe we can save screen space with a dropdown > list (instead of radio buttons)? Thanks for bringing this up. However, if we do this, I think there will be prompt every time even the permission is persisted. Per discussion with partner, I think we want to avoid the prompt after permission is granted and persisted. Moreover, I think such feature is doable in application itself. I'd like to remove the dependency of bug 1013838 for now.

Comment on attachment 8420814 [details] pull request redirect to github Please fix or address the fallen tests before reviewing.

Comment on attachment 8420814 [details] pull request redirect to github rebased and I think those homescreen marionette/py test fails are not related

PR updated. (CSS) make permission dialog content scrollable when exceed max size in landscape.

(In reply to Ivan Tsay (:ITsay) from comment #83) > (In reply to Frederik Braun [:freddyb] from comment #79) > > I would like the UX to support the "pyjamas use-case": Imagine you want to > > join a gUM based video session in which the application asks for audio and > > video, but you want the video to be blank. > > On Firefox desktop you can just select "no video" on the doorhanger and then > > click allow. Nobody will see you in your pyjamas, but you are still able to > > participate ;) > > > > Can we get this in there somehow? I know it's tricky and the dialogs are > > already quite cluttered. But maybe we can save screen space with a dropdown > > list (instead of radio buttons)? > > Thanks for bringing this up. However, if we do this, I think there will be > prompt every time even the permission is persisted. Per discussion with > partner, I think we want to avoid the prompt after permission is granted and > persisted. Moreover, I think such feature is doable in application itself. > I'd like to remove the dependency of bug 1013838 for now. I think it would be up to the app to provide this use case - just because the app has permission doesnt mean it has to transmit. Skype for example allows you to choose how you answer the call (audio or video).

Sure, all apps may do that. But I think *we* should be the ones providing safe defaults for all users. We could even hide two buttons (mute + facemute) in the entry for the notification bar...

(In reply to Paul Theriault [:pauljt] from comment #88) > (In reply to Ivan Tsay (:ITsay) from comment #83) > > (In reply to Frederik Braun [:freddyb] from comment #79) > > > I would like the UX to support the "pyjamas use-case": Imagine you want to > > > join a gUM based video session in which the application asks for audio and > > > video, but you want the video to be blank. > > > On Firefox desktop you can just select "no video" on the doorhanger and then > > > click allow. Nobody will see you in your pyjamas, but you are still able to > > > participate ;) > > > > > > Can we get this in there somehow? I know it's tricky and the dialogs are > > > already quite cluttered. But maybe we can save screen space with a dropdown > > > list (instead of radio buttons)? > > > > Thanks for bringing this up. However, if we do this, I think there will be > > prompt every time even the permission is persisted. Per discussion with > > partner, I think we want to avoid the prompt after permission is granted and > > persisted. Moreover, I think such feature is doable in application itself. > > I'd like to remove the dependency of bug 1013838 for now. > > I think it would be up to the app to provide this use case - just because > the app has permission doesnt mean it has to transmit. Skype for example > allows you to choose how you answer the call (audio or video). I have to disagree here. Firefox for Android & Desktop Firefox already do this because it puts the user first to make a decision on which devices they would like to share (e.g. they can choose a mic when camera/mic is requested). Taking this away reduces user control, as that assumes the application is going to give the user control, which may or may not be the case.

(In reply to Ivan Tsay (:ITsay) from comment #83) > (In reply to Frederik Braun [:freddyb] from comment #79) > > I would like the UX to support the "pyjamas use-case": Imagine you want to > > join a gUM based video session in which the application asks for audio and > > video, but you want the video to be blank. > > On Firefox desktop you can just select "no video" on the doorhanger and then > > click allow. Nobody will see you in your pyjamas, but you are still able to > > participate ;) > > > > Can we get this in there somehow? I know it's tricky and the dialogs are > > already quite cluttered. But maybe we can save screen space with a dropdown > > list (instead of radio buttons)? > > Thanks for bringing this up. However, if we do this, I think there will be > prompt every time even the permission is persisted. Per discussion with > partner, I think we want to avoid the prompt after permission is granted and > persisted. Moreover, I think such feature is doable in application itself. > I'd like to remove the dependency of bug 1013838 for now. I don't think that's correct. As long as a decision is remembered, we can choose to remember to share one device & decline the other, which will avoid multiple prompts.

Comment on attachment 8420814 [details] pull request redirect to github Well, I don't read the full story in this bug, but if the behavior is not confirmed please judge by yourselves.

We have to wait gecko bug 978660 landed anyway.

(In reply to Jason Smith [:jsmith] from comment #91) > (In reply to Ivan Tsay (:ITsay) from comment #83) > > (In reply to Frederik Braun [:freddyb] from comment #79) > > > I would like the UX to support the "pyjamas use-case": Imagine you want to > > > join a gUM based video session in which the application asks for audio and > > > video, but you want the video to be blank. > > > On Firefox desktop you can just select "no video" on the doorhanger and then > > > click allow. Nobody will see you in your pyjamas, but you are still able to > > > participate ;) > > > > > > Can we get this in there somehow? I know it's tricky and the dialogs are > > > already quite cluttered. But maybe we can save screen space with a dropdown > > > list (instead of radio buttons)? > > > > Thanks for bringing this up. However, if we do this, I think there will be > > prompt every time even the permission is persisted. Per discussion with > > partner, I think we want to avoid the prompt after permission is granted and > > persisted. Moreover, I think such feature is doable in application itself. > > I'd like to remove the dependency of bug 1013838 for now. > > I don't think that's correct. As long as a decision is remembered, we can > choose to remember to share one device & decline the other, which will avoid > multiple prompts. Unfortunately its more complicated that this. We would also need to make it clear that you were persisting the camera choice (in addition to just the permission), have a way to store this choice (maybe an access parameter on camera) expose the access preference to the app, so they could display the appropriate UI state. We would probably also want to provide a way for the user to choose another camera in the settings app, in case they made the wrong choice initially and the app doesn't provide a way to switch. I do get your point, and I think there is a lot of value in harmonsing with Firefox Mobile (though see comment 37 above). Can we take this to a separate bug perhaps though? I think the primary focus of this bug should be doing whatever is necessary to have a persistent camera permission experience without prompts, which is what loop needs.

Hi Fred, Since bug 978660 is landed, this bug should be ready for landing, correct?

rebased and wait travis/TBPL pass to land

seems test have some ui test fail but I believe its related to homescreen merged to master https://github.com/mozilla-b2g/gaia/commit/20d61faea024d6d09d57038425a6d7a2818bbfb8 thanks!

Turns out this caused the failed tests after all. Please restart the test if you aren't sure, and next time wait for a green travis. Thanks. Backed out: https://github.com/mozilla-b2g/gaia/commit/b8a7ee06272d054e667e08ca6097eb9dba9e4f34 Error details: 1) Edges gesture > No reflow while swiping: AssertionError: we got 4 reflows instead of 0 at Context.<anonymous> (/home/travis/build/mozilla-b2g/gaia/apps/system/test/marionette/edges_gesture_test.js:108:12) at callFn (/home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runnable.js:223:21) at Test.Runnable.run (/home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runnable.js:216:7) at Runner.runTest (/home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runner.js:374:10) at /home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runner.js:452:12 at next (/home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runner.js:299:14) at /home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runner.js:309:7 at next (/home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runner.js:247:23) at /home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runner.js:271:7 at done (/home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runnable.js:185:5) at callFn (/home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runnable.js:228:7) at Hook.Runnable.run (/home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runnable.js:216:7) at next (/home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runner.js:259:10) at /home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runner.js:271:7 at done (/home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runnable.js:185:5) at /home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runnable.js:199:9 at Object.executeHook (/home/travis/build/mozilla-b2g/gaia/node_modules/marionette-client/lib/marionette/client.js:369:18) at process._tickCallback (node.js:415:13) 2) Homescreen navigation > Going to the homescreen and back to a warm app: AssertionError: we got 4 reflows instead of 0 at Context.<anonymous> (/home/travis/build/mozilla-b2g/gaia/apps/system/test/marionette/homescreen_navigation_test.js:75:12) at callFn (/home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runnable.js:223:21) at Test.Runnable.run (/home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runnable.js:216:7) at Runner.runTest (/home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runner.js:374:10) at /home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runner.js:452:12 at next (/home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runner.js:299:14) at /home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runner.js:309:7 at next (/home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runner.js:247:23) at /home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runner.js:271:7 at done (/home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runnable.js:185:5) at callFn (/home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runnable.js:228:7) at Hook.Runnable.run (/home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runnable.js:216:7) at next (/home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runner.js:259:10) at /home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runner.js:271:7 at done (/home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runnable.js:185:5) at /home/travis/build/mozilla-b2g/gaia/node_modules/mocha/lib/runnable.js:199:9 at Object.executeHook (/home/travis/build/mozilla-b2g/gaia/node_modules/marionette-client/lib/marionette/client.js:369:18) at process._tickCallback (node.js:415:13)

Fred, Please help to figure out the test issue and re-land this after you fix the issue.

New PR testing... https://github.com/mozilla-b2g/gaia/pull/19914

all green, merged https://github.com/mozilla-b2g/gaia/commit/b63c53ae7f98a5adbcba334d606eb3325594bc83 thanks! the root cause is I set `rememberSection.style.display = 'block'` at cleanDialog, which triggered reflow when press home button

remove ni? since this bug is resolved.