[UX] Unify and improve behavior of doorhanger dialogs

RESOLVED FIXED

Status

()

Firefox
Theme
RESOLVED FIXED
3 years ago
6 months ago

People

(Reporter: phlsa, Assigned: shorlander)

Tracking

(Depends on: 2 bugs, Blocks: 1 bug)

33 Branch
x86
All
Points:
13
Dependency tree / graph
Bug Flags:
firefox-backlog +
qe-verify -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ux])

Attachments

(2 attachments, 1 obsolete attachment)

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.
Flags: firefox-backlog+

Updated

3 years ago
Flags: qe-verify-

Updated

3 years ago
Assignee: nobody → shorlander
Status: NEW → ASSIGNED
Iteration: --- → 35.2
Points: --- → 13

Updated

3 years ago
Iteration: 35.2 → 35.3
(Assignee)

Comment 1

3 years ago
Created attachment 8504505 [details]
Panel Unification — i02

Panel Unification analysis and recommendations.
Attachment #8504505 - Flags: review?(philipp)
(Assignee)

Comment 2

3 years ago
Created attachment 8504507 [details]
Panel Audit - 01
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+
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
(Assignee)

Comment 4

3 years ago
Created attachment 8504734 [details]
Panel Unification — i03

Cleaned up an image, typos.
Attachment #8504505 - Attachment is obsolete: true
Attachment #8504734 - Flags: review+

Updated

3 years ago
Depends on: 1082730
Stephen, could you please file engineering follow-up bugs for this and make them depend on this bug?
Thanks!
Flags: needinfo?(shorlander)
Blocks: 1097629
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.)
Flags: needinfo?(philipp)

Updated

3 years ago
See Also: → bug 1115126

Comment 7

3 years ago
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.
See Also: → bug 1124232

Comment 8

3 years ago
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: → bug 675533
A lot of this thinking has gone into the work around control center which will eventually deal with permissions: bug 1154742
Flags: needinfo?(philipp)
(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
(Assignee)

Updated

6 months ago
Flags: needinfo?(shorlander)
You need to log in before you can comment on or make changes to this bug.