With device sharing and tracking protection some new and improved behaviors have been added to our doorhanger dialogs. We now should apply these behaviors to other doorhangers for a unified experience.
Assignee: nobody → shorlander
Status: NEW → ASSIGNED
Iteration: --- → 35.2
Points: --- → 13
Panel Unification analysis and recommendations.
Attachment #8504505 - Flags: review?(philipp)
Comment on attachment 8504505 [details] Panel Unification — i02 Excellent! Could you please also file the follow-up UX and engineering bugs in order to make that happen? Thanks!
Attachment #8504505 - Flags: review?(philipp) → review+
5 years ago
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Cleaned up an image, typos.
Stephen, could you please file engineering follow-up bugs for this and make them depend on this bug? Thanks!
5 years ago
Just saw this bug -- nice work, glad we're finally looking at this. A couple questions / extra thoughts: * This seems to remove the ability for the user to say "always for this site" (eg, for geolocation on maps.google.com). Is the intent to do this some other way, or remove it completely? * Somewhat related, AIUI the original intent was for icons to show up again for permanently-granted permissions, but I think we never really implemented this. (e.g., again, if you granted "always" for geolocation on Maps, future visits should display the icon so you (1) know it's active and (2) can get there to revoke it. * I've been thinking we should automatically suppress (icon only) further prompts from a site, even across navigations, unless you've explicitly accepted an earlier prompt. t-mobile.com and wendys.com are bad offenders here -- every page on the site triggers a geolocation request, and it's really annoying. * Small nit: I suppose having the site name/icon in the panel makes sense, but it seems nonideal to have it at the very top, since now you have to skip over it to get to the actual prompt text. I wonder if it could be moved elsewhere or styled differently to make it feel less awkwardly dropped in. (e.g. a darker background as a header bar at the top of the prompt?) * One of the major panel issues that doesn't seem to have been addressed here is the concern that users lose panels when they're dismissed to the icon-only state. That is, they clicked outside the panel without selecting an action. The concern raised (mainly by webdevs) is that the site can't trigger the panel again, but their users are confused because they don't know how to reopen a prompt. We've got a fine line to tread here as the UA, though, in that we also want to guard against malicious/annoying sites abusing prompts. I don't have a good proposal here, other than to do some user research to understand the problem, and strengthen our position for whatever UX we settle on. * No large icon for the camera/mic/screen sharing permission prompt? These seem noticeably inconsistent without it, although I suppose the argument is that the complexity of the rest of the panel makes it too noisy? * Is it deliberate that the plugin activation panel isn't updated with the new style? (Other than adding the site icon.)
I worry about removing the 'x' from doorhangers. Do all of our user's really know that they can click anywhere to dismiss the option, or will the lack of an 'x' make them feel like they need to make a decision now in order to proceed with their task? Perhaps a usertesting.com study can provide us with some data around this - when presented with an informational doorhanger, do users click outside the doorhanger to escape it or do they click the 'x'? In particular, I am worried about removing the 'x' on the Mixed Content Shield Doorhanger. In that doorhanger, the only option is to "Disable Protection". Without an 'x' or a 'Not Now" user's may be pushed to choose this option (even if the page functions just fine without the Mixed Content) to proceed with their task. See bug https://bugzilla.mozilla.org/show_bug.cgi?id=1057643.
Please see 675533. In summary, the W3C permissions API for geo/camera/mic has no provision for "user dismissed dialog with no choice", and web devs are not happy (to put it mildly) that they cannot handle this state. No other browser has this state. I think it is worth looking closely at how Chrome Beta is handling this: https://bug675533.bugzilla.mozilla.org/attachment.cgi?id=8600427 Marcos makes some good points about the modality of the popup, and how Chrome Beta has tied the notification popup to the tab it applies to, in his video on bug 675533: https://www.youtube.com/watch?v=CNF0js2hDG0
See Also: → 675533
A lot of this thinking has gone into the work around control center which will eventually deal with permissions: bug 1154742
(In reply to Philipp Sackl [:phlsa] please use needinfo from comment #9) > A lot of this thinking has gone into the work around control center which > will eventually deal with permissions: bug 1154742 As there is a close relationship between permissions and the standardized APIs that rely on them, please make sure to involve the DOM team (e.g., me) in discussions. In particular, please let us know if you are introducing any new states, etc. The W3C is are working on a new Permissions API and it would be great if it was compatible with whatever you guys are cooking up: https://w3c.github.io/permissions/
Depends on: 1193073
2 years ago
You need to log in before you can comment on or make changes to this bug.