Closed Bug 1285212 Opened 7 years ago Closed 7 years ago

Add tooltips to permission icons in the url bar

Categories

(Firefox :: Site Identity, defect, P2)

Product:
Firefox
Component:
Site Identity
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 51
Iteration:
51.3 - Sep 19
Tracking Flags:
Tracking Status
firefox50 --- affected
firefox51 --- verified

People

(Reporter: johannh, Assigned: johannh)

References

Details

(Whiteboard: [fxprivacy] )

Attachments

(1 file)

Bug 1285212 - Add tooltips to permissions icons in the url bar.
58 bytes, text/x-review-board-request
johannh
: review+
Details 
The icons that are used as notification anchors should have tooltips, e.g. the name of the permission they are requesting.
Not for permissions sub-set. For legacy icons only.
Flags: needinfo?(agrigas)
Priority: -- → P2
Whiteboard: [fxprivacy] [triage] → [fxprivacy]
(In reply to Erin Lancaster [:elan] from comment #1)
> Not for permissions sub-set. For legacy icons only.

waiting on copy from the copywriter
I need to know exactly what icon states need a tooltip in order to get this request finished...
Flags: needinfo?(agrigas) → needinfo?(pdolanjski)
Summary: Add tooltips to notification anchors in the identity box. → Add tooltips to blocked permissions icons in the url bar
Assignee: nobody → jhofmann
Status: NEW → ASSIGNED
Flags: qe-verify+
We're gonna use the a11y labels (http://searchfox.org/mozilla-central/source/browser/locales/en-US/chrome/browser/browser.dtd#212) for non-blocked permissions and are waiting on copy for tooltips for blocked permissions.
Flags: needinfo?(pdolanjski)
See Also: → 1290020
Aislinn, sorry to bother you with this, but I think the copy isn't really fitting the context. It's a bit too concise. There is a high chance that this tooltip will be seen by users who are confused about the purpose of the crossed-out icons, and we should do a better job explaining them than "Camera is blocked."

- These strings don't give information about why / how this happened.
- These strings don't give anything actionable the user can do.
- "Blocked" might be easy to mistake with "broken" without context, and even more so when translated into other languages like German

I was thinking about something along the lines of "You have blocked/disallowed camera access for this website." instead.
(In reply to Johann Hofmann [:johannh] from comment #6)
> Aislinn, sorry to bother you with this, but I think the copy isn't really
> fitting the context. It's a bit too concise. There is a high chance that
> this tooltip will be seen by users who are confused about the purpose of the
> crossed-out icons, and we should do a better job explaining them than
> "Camera is blocked."
> 
> - These strings don't give information about why / how this happened.
> - These strings don't give anything actionable the user can do.
> - "Blocked" might be easy to mistake with "broken" without context, and even
> more so when translated into other languages like German
> 
> I was thinking about something along the lines of "You have
> blocked/disallowed camera access for this website." instead.

Ah I see - got it. Good point. I'll revise and post an updated screenshot today...
Great, thanks! Btw, I have access to the document where these texts are shared so I wouldn't necessarily need a screenshot.
Comment on attachment 8783992 [details]
Bug 1285212 - Add tooltips to permissions icons in the url bar.

I think you can get rid of the aria-label attribute, tooltiptext should automatically take care of this. Also, these strings' names should use the .tooltip suffix, not .label.

<!ENTITY urlbar.screenBlocked.label         "You have blocked your screen for this website.">

This sounds a bit weird to me.

<!ENTITY urlbar.pointerLockBlocked.label    "You have blocked hiding your  mouse pointer for this website.">

nit: excess space
Attachment #8783992 - Flags: review?(dao+bmo) → review-
Thanks for the review!

> This sounds a bit weird to me.

I agree, I'll ask UX about it once we get into the right timezone.
Comment on attachment 8783992 [details]
Bug 1285212 - Add tooltips to permissions icons in the url bar.

Please rebase this on top of bug 1297405
Attachment #8783992 - Flags: review?(dao+bmo)
Can you also rename urlbar.*NotificationAnchor.label to urlbar.*NotificationAnchor.tooltip? This matters because e.g. in en-US some labels are supposed to use title capitalization but tooltips don't.
Huh, ok, sure. Do you know how changing locale keys affects translators? Is the change easy to process for them?
I'm not sure how smart their tools are. I'd hope that it's easy enough for them to see that the strings were just renamed.
Summary: Add tooltips to blocked permissions icons in the url bar → Add tooltips to permission icons in the url bar
Component: General → Site Identity and Permission Panels
Comment on attachment 8783992 [details]
Bug 1285212 - Add tooltips to permissions icons in the url bar.

So this seems fine code wise, but looking at these strings I'm not sure how they were ever allowed to land in the first place. E.g. "View the app-offline storage message" seems like incredibly bad jargon. Let's please get proper strings from some UX person here.
Attachment #8783992 - Flags: review?(dao+bmo) → review-
I think I'd generally prefer "Open/Show some notification" or "Show some request" over "View some notification/request/message."

Btw, while you're already changing the names, you can go further and drop the number from urlbar.webNotsNotificationAnchor3.tooltip, i.e. rename it to urlbar.webNotsNotificationAnchor.tooltip.
Aislinn, I think Dao makes a good point. Some of the aria-labels are not suited for usage as tooltips. Can someone from UX take another look at them and figure out which ones need to be altered?

The list is here: http://searchfox.org/mozilla-central/source/browser/locales/en-US/chrome/browser/browser.dtd#213
Flags: needinfo?(agrigas)
(In reply to Johann Hofmann [:johannh] from comment #22)
> Aislinn, I think Dao makes a good point. Some of the aria-labels are not
> suited for usage as tooltips.

Honestly they weren't suited for aria-label either. If anything aria-labels should be /more/ expressive than tooltips, because screen reader users don't even have the icon as an additional hint and depend entirely on the accessible label.
Ash, can you please also add a clear tooltip for screensharing? Thanks!
Sorry I meant for screensharing _blocking_
(In reply to Johann Hofmann [:johannh] from comment #25)
> Sorry I meant for screensharing _blocking_

I need more context for how these tooltips show? If its when we prompt for a permission, why do we have an additional tooltip if the doorhanger is already open and requesting the permission?
Flags: needinfo?(agrigas)
(In reply to Johann Hofmann [:johannh] from comment #25)
> Sorry I meant for screensharing _blocking_

Screensharing should be:
You have blocked this website from sharing your screen.
You have temporarily blocked this website from sharing your screen.
"View a notification">Open dialogue
"View the location request">Open location request dialogue 
"View the add-on install message">Open add-on installation dialogue
"View the app-offline storage message">Open offline storage dialogue
"Manage your login information">No change
"Check if you want to save your password">Open save password dialogue
"Manage plugin usage on this page">Manage plug-in use
"Change whether you can receive notifications from the site">No change
"Manage sharing your camera and/or microphone with the site">No change
"Manage sharing your microphone with the site">No change
"Manage sharing your windows or screen with the site">No change
"Change whether the site can hide the pointer">Change whether this site can hide your mouse pointer
"View the service install message">Open install dialogue
"Translate this page">No change
"Manage page translation">No change
"Manage use of DRM software">No change
We chatted about it on IRC and Aislinn suggested replacing 'dialogue' with 'message panel' because that's what we use on help.mozilla.org.
Attachment #8783992 - Flags: feedback?(agrigas)
Comment on attachment 8783992 [details]
Bug 1285212 - Add tooltips to permissions icons in the url bar.

r+ code-wise. I'm still not a fan of many of the tooltips. Most notably, it's not even clear to me what "Open message panel" is supposed to mean, and "Change whether this site can hide your mouse pointer" is just wrong since sites can still hide the mouse pointer by simply using cursor:none. Pointer lock isn't just about hiding the mouse pointer.
Attachment #8783992 - Flags: review?(dao+bmo) → review+
Comment on attachment 8783992 [details]
Bug 1285212 - Add tooltips to permissions icons in the url bar.

Looks ok
Attachment #8783992 - Flags: feedback?(agrigas)
Depends on: 1300495
Rebased on top of bug 1300495.
Comment on attachment 8783992 [details]
Bug 1285212 - Add tooltips to permissions icons in the url bar.

urlbar.notificationsBlocked.tooltip should be urlbar.webNotsBlocked.tooltip for consistency (ugh) or urlbar.webNotificationsBlocked.tooltip for clarity.
Attachment #8783992 - Flags: review?(dao+bmo) → review+
(In reply to Dão Gottwald [:dao] from comment #36)
> Comment on attachment 8783992 [details]
> Bug 1285212 - Add tooltips to permissions icons in the url bar.
> 
> urlbar.notificationsBlocked.tooltip should be urlbar.webNotsBlocked.tooltip
> for consistency (ugh) or urlbar.webNotificationsBlocked.tooltip for clarity.

ugh indeed, since we're changing the name anyway let's call it urlbar.webNotificationAnchor.tooltip and urlbar.webNotificationsBlocked.tooltip
Comment on attachment 8783992 [details]
Bug 1285212 - Add tooltips to permissions icons in the url bar.

I assume I can carry over the r+
Attachment #8783992 - Flags: review?(dao+bmo) → review+
https://hg.mozilla.org/mozilla-central/rev/b294f305f8d1
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
status-firefox51: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 51
Iteration: --- → 51.3 - Sep 12
QA Contact: paul.silaghi
Verified fixed FX 51.0a1 (2016-09-14) Win 7, Ubuntu 14.04, OS X 10.11.
Status: RESOLVED → VERIFIED
status-firefox51: fixed → verified
You need to log in before you can comment on or make changes to this bug.