Issue metadata
Sign in to add a comment
|
MacViews Permissions bubbles have no way to dismiss with "Ask me every time" using the mouse |
||||||||||||||||||||||
Issue description.. because they have no [x]. See attached. Chrome Version : 54.0.2824.0 OS Version: OS X 10.11.6 I think we need to do "something" here, but I'm not sure what (shrike? felt?) What steps will reproduce the problem? 1. chrome://flags/#mac-views-webui-dialogs (or get opted in to the 50/50 Finch experiment -- see http://crbug.com/633436 2. https://permission.site 3. Click, e.g., Location What is the expected result? A way to dismiss with the mouse without feeling like I'm making a scary/permanent decision. What happens instead of that? Can only dismiss with Esc, or selecting Allow/Block This happens because of the fix for Issue 589875 . Generally, "Mac prompts shouldn't have [x] buttons unless they are floating windows" e.g. Preferences Pane can have an [x]. Dialogs should have an explicit button to dismiss. So, what to do? Possibly: - Add the [x] back (just) for permissions bubbles? - Add the [x] back for all "persistent" bubbles (e.g. "Developer mode extensions" as well) - Add an "Ask me every time" button (since that's effectively what [x] is on permissions prompts - Keep as is, and force users to make a decision? Anyway, I guess we're getting some interesting UMA metrics in the Finch experiment for how people interact with these dialogs when we remove the [x].... Note the experiment is restricted to Dev channel, so this won't go out to Beta.
,
Aug 12 2016
Over to shrike@; I think we need to maybe reconsider close buttons, since it seems like we've found a few places now where Views dialogs are assuming they'll be present. What do you think about reinstating close buttons?
,
Aug 12 2016
I think it's OK to put the close button back. That said, I'm confused about how UX would think this dialog needs to behave. Ultimately the correct thing to do here will depend on the final Harmony specs.
,
Aug 13 2016
,
Aug 13 2016
Oof, yeah, we need this close button back.
,
Aug 18 2016
I've heard that close buttons on bubbles/dialogs may be removed by Harmony. Is that a decision that's yet to be made or has been made? There will be significant implications for permissions bubbles on desktop platforms if users have no obvious way to not make a decision (we know that the permanence / scariness of the decision or the sensitivity of the information gated by a dialog influences users to prefer clicking X). Also, metrics say that the dismiss X is the most or second-most interacted-with button on this dialog depending on the permission. Geolocation and notification permission bubbles are dismissed 20/30% of the time on OS X.
,
Aug 18 2016
I'm marking this regression as a release blocker for 54. We really need that button back -- for the reasons outlined by Dom -- unless the bubbles as a whole are revamped as part of Harmony to provide an analogous option.
,
Aug 18 2016
I have a fix in flight for this at https://codereview.chromium.org/2253283003/ but the last bot is taking its time. I will update this bug once it lands.
,
Aug 19 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4aad4a8d18daf041d47bc0d9bb489f05bd5f5188 commit 4aad4a8d18daf041d47bc0d9bb489f05bd5f5188 Author: ellyjones <ellyjones@chromium.org> Date: Fri Aug 19 16:07:47 2016 macviews: reinstate close button Blanket removal of close buttons turns out to have been hasty, since many of our dialogs are designed around having them, not just visually but semantically. For now, return the behavior to that of other platforms while we reconsider this UI design. BUG= 637178 Review-Url: https://codereview.chromium.org/2253283003 Cr-Commit-Position: refs/heads/master@{#413156} [modify] https://crrev.com/4aad4a8d18daf041d47bc0d9bb489f05bd5f5188/ui/views/bubble/bubble_frame_view.cc
,
Aug 23 2016
The plan of record is for the permissions bubble to have a close-x button.
,
Aug 29 2016
This seems to be working fine on the latest canary(55.0.2842.0) on Mac OS 10.11.6. Attached is the screenshot of the same. Adding the verified label therefore. ellyjones@: Please close the issue if there is no further work to be done here. Note: No merge to M-54 required here as M-54 branched @414607 and the fix landed @413156
,
Aug 29 2016
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by tkonch...@chromium.org
, Aug 12 2016