+rolfe the content settings UI person.

raymes: I'm working on a CL to just forbid editing of exceptions for certain content types (Location, etc.) in MD Settings to match how Old Options works. Does that work with you?

+rolfe / bettes

 - I'm okay with Raymes' suggested string changes. I'm calling you guys since you guys probably have exact strings in mind.

 - Regarding Raymes' suggested Flash changes, I know we had a huge discussion about the topic last year here: https://bugs.chromium.org/p/chromium/issues/detail?id=622922. I'm not super keen on redoing that -- but I am happy to do so if you guys are all aligned on making some changes. 

   Just remember we have to support all the HTML by Default Flash states. (3 states)

I'm ok if we don't make any Flash changes for now until we can remove the "Always allow" behavior. 

Thanks!

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/62d32b16f0926c4c34c97deff4c0e6acb74a1bba

commit 62d32b16f0926c4c34c97deff4c0e6acb74a1bba
Author: tommycli <tommycli@chromium.org>
Date: Wed Mar 15 18:51:52 2017

MD Settings: For some content types, make per-site exceptions read-only.

This CL makes MD Settings match old Options in terms of which content
types have exceptions that are read-only (from within Settings).

BUG= 700118 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2744583004
Cr-Commit-Position: refs/heads/master@{#457151}

[modify] https://crrev.com/62d32b16f0926c4c34c97deff4c0e6acb74a1bba/chrome/browser/resources/settings/privacy_page/privacy_page.html
[modify] https://crrev.com/62d32b16f0926c4c34c97deff4c0e6acb74a1bba/chrome/browser/resources/settings/site_settings/category_setting_exceptions.html
[modify] https://crrev.com/62d32b16f0926c4c34c97deff4c0e6acb74a1bba/chrome/browser/resources/settings/site_settings/category_setting_exceptions.js
[modify] https://crrev.com/62d32b16f0926c4c34c97deff4c0e6acb74a1bba/chrome/browser/resources/settings/site_settings/site_list.html
[modify] https://crrev.com/62d32b16f0926c4c34c97deff4c0e6acb74a1bba/chrome/browser/resources/settings/site_settings/site_list.js

rolfe/tbuckley/bettes: ping on raymes' suggested string changes for MD Content settings.

Is +rschoen in the know about this (or still the current PM)? I have trouble keeping all the Flash state in my head and find discussing changes in a 1:1 super helpful.

Assigments shifted a bit in January so +maxwalker@ would be the one to weigh in as the Security contact. Don't mean to Make This A Huge Change but we also have a UX writer (srahim@) now to help with strings and who should be consulted here.

rschoen@ - would you be able to get maxwalker@ caught up?
tommycli@ - do you have any visuals to help describe the changes? (Or do you need that from UX?)

Hey,

Re Flash change: Raymes and I have agreed to hold off. We also fixed the read-only exceptions issue.

The only open questions are about the 'String nits' described in the first message. If you open Canary and go to chrome://md-settings/content (and their subpages), that shows where the strings are that Raymes thinks could use some improvement.

Thank you for clarifying tommycli@!

1) For the first request (make Allow/Block language consistent) there is an outstanding bug to Security to fix that:
https://bugs.chromium.org/p/chromium/issues/detail?id=642015
So raymes@ feel free to jump in on that in all your free time. : ) The allow/block states will be equally verbose, per request from pkasting@ (links in the bug to the original conversation.)

2) +srahim can answer whether "Open PDFs using a different application" can be made less confusing. (The concern is it's not clear which application will be used. Can you take a look when you have a moment?)

3) bettes@ is best-equipped to answer the icon issue. ("Unsandboxed plugin access" and "Flash" icons are the same, but the former can be scarier, security-wise.)
 

2) The current behavior in 57.0.2987.98 is that the string says "Open PDF files in the default PDF viewer application". If I check it and try to open a PDF file, Chrome downloads the file (and doesn't open it).

Is that WAI? If so, the string might need to be changed to be accurate. Some initial ideas: 
"[ ] View PDF files in Chrome"
"[ ] Download PDF files to view with another app"

2) It seems that the second option, "Download PDF files to view with another app" seems to best reflect the current behavior.

Yes, I think it's intended that it's just auto downloaded, and not auto-opened. Users can right-click the item in the download bar and choose "Always open with system viewer" if they also want to auto-open it.

3) +bettes for an answer

+raymes, what do you think of "Download PDF files to view with another app"?

+stevenjb for chromeos stuff

Something like that sounds good. I actually like srahim's idea of having a radio button instead of a checkbox so the 2 options can be spelled out more clearly, e.g.

By default PDF links should be:
[x] Automatically opened and displayed in Chrome
[ ] Downloaded to view later

Hey Raymes,

Re-reading srahim's message, I'm not sure if that's what srahim intended.

In any case, I'm attaching a screenshot of what it looks like in MD Settings today. I don't think two radio boxes is really an option.

We could make the text next to the toggle change depending on if it's on or off, but I personally think that's a really confusing pattern, and prefer static text.

Thoughts?

Deleted: Screenshot from 2017-04-18 15:53:13.png 6.4 KB

	Screenshot from 2017-04-18 15:53:13.png 6.4 KB View Download

Sorry if I misunderstood. Are radio buttons not possible with the new md settings?

Could we have something like:
"Download PDFs instead of automatically opening them in Chrome"

I guess my fear is that if we just present the user with one of "Download PDFs" or "Open PDFs in Chrome" users won't understand what the alternative is.

+bettes,

I will defer to bettes@, however, I believe all boolean options within Content Settings must now be toggles.

I agree that for PDF this may be confusing because it doesn't exactly follow the ALLOW/BLOCK model.

I would be okay with your proposed text of 
"Download PDFs instead of automatically opening them in Chrome" as well.

True, everything in content settings is a toggle so we should probably stick to just changing the string, which is fine with me. String suggested in c#18 works:

"Download PDF files instead of automatically opening them in Chrome"

srahim: Great, thanks!

https://codereview.chromium.org/2828413002

Deleted: Screenshot from 2017-04-20 12:08:51.png 8.7 KB

	Screenshot from 2017-04-20 12:08:51.png 8.7 KB View Download

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4158d8311733c2901331f74b1c73dd026f740672

commit 4158d8311733c2901331f74b1c73dd026f740672
Author: tommycli <tommycli@chromium.org>
Date: Thu Apr 20 21:24:38 2017

MD Settings: Polish string for disabling internal PDF plugin

Updates string to one provided by srahim@ which better reflects the
actual behavior.

BUG= 700118 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2828413002
Cr-Commit-Position: refs/heads/master@{#466138}

[modify] https://crrev.com/4158d8311733c2901331f74b1c73dd026f740672/chrome/app/settings_strings.grdp
[modify] https://crrev.com/4158d8311733c2901331f74b1c73dd026f740672/chrome/browser/resources/settings/site_settings/pdf_documents.html
[modify] https://crrev.com/4158d8311733c2901331f74b1c73dd026f740672/chrome/browser/ui/webui/settings/md_settings_localized_strings_provider.cc

Looks like the only outstanding issue now is: 

"The icon being used for "Unsandboxed plugin access" is the same as for "Flash". I think it would be good to make it a different icon as it is a setting which is much scarier than enabling/disabling Flash." (raymes)

Bouncing the bug over to bettes@ for feedback

Clearing my ownership of P2 UI>Settings bugs. Feel free to re-assign once triaging is complete. 

Hello!
This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time
- If you are currently working on this bug, please provide an update.
- If you are currently affected by this bug, please update with your current symptoms and relevant logs.

If there has been no updates provided by EOD Wednesday, 12/19/18 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary.

Thank you!

@sylcat: This bug as it stands currently is a bit hard to follow. It is unclear what action items are there, which changes are agreed upon etc.

Can you and other stakeholders who are interested about these improvements, collaborate with UX (maybe Namrata?) and a PM and go through the process of scoping, proposing, UX reviewing, prioritizing this changes?

Suggesting this, since it seems more likely to make progress this way, than just relying on this (seemingly inactive) bug.

That sound fair. For any further action for those still affected, can you please confirm that you are still affected by this and would need further progress to be made? This will allow us to update ownership.

Otherwise as stated before this bug will be Archived and can be re-opened when there are further actionable items that can be defined.

Archiving. I think this is low priority and I doubt anyone is likely to look at it.