Manual regression range:
Good Build: 52.0.2714.0
Bad Build:  52.0.2715.0

Narrow bisect:
https://chromium.googlesource.com/chromium/src/+log/0f9d36e6579569f4c727f964fee4fd642e39b67e..b4d6bf98e54db861b8d9adc7642c47b1677b8f40?pretty=fuller&n=30

Suspecting: 388944 ?
Kindly help to re-assign, if your changes are not cause for this issue.

Deleted: Actual_Permission.mov 4.5 MB

Actual_Permission.mov 4.5 MB Download

Marking the above issue as RB-Stable as this is a recent regression.

Thank you!

> 4.Observe the 'view site info' after reloading the page.

Does "view site info" refer to opening the page info bubble?

Just checked the video, and I don't think r388944 introduced a new bug, but has revealed an existing UI bug with content settings:

- When JavaScript is disabled, twitter.com always redirects to mobile.twitter.com for whatever reason.
- JS disabling was broken before r388944: Changing settings from page info bubble and reloading the page didn't immediately block JS, it required an extra reload. This meant that when the user blocked JS on twitter.com and reloaded the page, twitter.com didn't immediately redirect to mobile.twitter.com. But if the user reloaded again, they would correctly be redirected to the mobile site.
- Turns out blocking JS adds a wildcard exception for all subdomains of a site. So blocking JS on twitter.com adds "[*.]twitter.com" pattern in content settings which blocks JS on twitter.com and all of its subdomains. (you can verify this at chrome://settings/contentExceptions#javascript)
- All is good until this point, and JS is disabled on mobile.twitter.com as well as twitter.com. However, if the user now changes JS setting from "Blocked" to "Use global default (Allow)" on mobile.twitter.com, nothing seems to happen. JavaScript settings page still shows the same "[*.]twitter.com" pattern, and nothing is added for mobile.twitter.com.
- But if the user chooses "Always Allow" instead of "Use global default (Allow)" on mobile.twitter.com, an "Allow" pattern is added for mobile.twitter.com in the content settings, and JS gets enabled on mobile.twitter.com properly.

So the bug here is that "Use global default (Allow/Block)" option is misleading for a subdomain when the parent domain already overrides the global setting.

There are a few fixes we could consider:

1. Make "Use global default (Allow)" to actually add an "Allow" setting for the subdomain if the setting is set to "Blocked" on the parent domain, instead of doing nothing.
I'm not a fan of this option, because it's going to be confusing when the user changes the global setting: They wanted to use "Global default (Allow)" on mobile.twitter.com, then changed the global default to "Block", but now mobile.twitter.com will still allow JS.

2. Change the string for "Use global default (*)" to something else that reflects the fact that the setting is overriden. Maybe something like "Use setting from parent domain (Allow/Block)" or something like that. This will mirror how content settings work, so I lean towards this fix.

2. Hide "Use global default (*)" option for subdomains when the global setting is already overridden for the parent domain. This sounds like the most straightforward option, and is consistent with the whole content settings mechanism. IMO it's not meaningful to talk about the global default when the setting is already overriden by the parent domain.

Given all these, I don't think there is a regression here, or that this bug should be a release blocker, but I'll make sure it is fixed because I heavily use this UI.

@palmer: Sorry for the wall of text, but would love to have your opinion here.
tl;dr is: What should we do with the "Use Global Default" setting on a subdomain in the OIB if the parent domain already overrides the global default?

I find this:

"""
So blocking JS on twitter.com adds "[*.]twitter.com" pattern in content settings which blocks JS on twitter.com and all of its subdomains.
"""

surprising. What is the reason for doing that?

I also found that surprising. Not sure the reason, but to be fair I think it's more usable this way. It would be a pain to have to block/allow a setting on all subdomains.

(that is, it saves a trip to content settings and manually adding patterns)

Removing RB label per comment #4. Please add back if I'm mistaken.

OK, so if we like the "blocking example.com -> also blocks *.example.com" behavior*, then I think you are right that option 1 in comment #4 is not great. I could agree to either of your option 2s ;) in comment #4. Probably the 1st 2nd option (Change the string for "Use global default (*)" to something else that reflects the fact that the setting is overriden).

* BTW: does the * go only 1 label deep...?

Now that I think about it, I like my first option (2) more than the second option (2) too :) It could say something like "Use default from twitter.com" or "Use default from parent domain".

> * BTW: does the * go only 1 label deep...?
Yes, it does. Blocking google.com also blocks foo.bar.google.com.

"""
> * BTW: does the * go only 1 label deep...?
Yes, it does. Blocking google.com also blocks foo.bar.google.com.
"""

So it goes more than 1 label deep, right?

Oh, misread your comment. Yes, it goes more than 1 level deep.

I can confirm that this bug was always there. It's a mismatch between how the page info bubble and content settings interact. "Use default" simply removes the exception corresponding to this site, which would be "https://[*.]mobile.twitter.com:443" in this case, but such an exception isn't even there. Nothing happens, and the previously added "https://[*.]twitter.com:443" stays in effect.

A similar problem was described in  issue 470790 .

We're* moving content settings to be origin-scoped by default, so the exceptions set will be "https://twitter.com:443" and "https://mobile.twitter.com:443". That should make this problem mostly go away. (But it's still going to be reproducible for custom domain-scoped exceptions.)

[*]this actually came from the Enamel team

I might have missed the discussion, but I think scoping JS and image settings to origins will be user unfriendly :) It makes sense for permissions like geolocation and getusermedia, but JS and image blocking aren't permissions in the same sense, but rather a convenience feature. I hope it's not too late to discuss this, I'll respond to the enamel thread.

This was more or less the previous state. Subdomain wildcard was used for content settings representing actual site content; no wildcard for those permission-y ones. (For the record, I was also happy with that state, but I don't know what plans Enamel has, so I didn't argue)

This document https://docs.google.com/document/d/19huEwYGuACxsl9X1KGvXtptdwpcES_xaG7k3Y-n1abw/ mentions JS and images well.

As far as I know, the migration is not yet implemented (+lshang@), so it's not too late.

Thanks, I was having trouble finding the discussion. I'll make some noise before it's too late :)

Hey meacer@!

We've discussed the issue of origin scoping vs domain scoping at some length and quite widely. We believe making everything origin-scoped will be more user friendly for several reasons:
1) It makes the behavior of these types of settings consistent with permissions like geolocation, etc. which are origin scoped. We use the same UI treatment for things like javascript, popups, etc. as we do with geolocation, midi, etc. and from a users perspective it's very hard (impossible?) to reason about why the behavior would be different between the two things.
2) It makes it possible to build much simpler, more understandable UI. The prime example of this is the "all sites" settings page on android (soon to come to desktop). It displays a list of sites and you can click on each one and see the permissions associated with it. However when different settings are scoped in different ways, this list becomes very confusing. For example, if someone has granted javascript and geolocation to twitter.com there will be 2 entries in the list - one for [.*]twitter.com and one for twitter.com. It's not simple to merge the two things because they are scoped differently. This is confusing.
3) If the settings were all origin scoped, I think it makes it simple to infer what the behavior should be in cases like this bug (and many other cases). That is, I think that changing settings in the OIB should only do so for the current origin.

Does this sound reasonable to you? Happy to meet and chat more if you still have questions or concerns :) Feel free to assign this to myself/lshang and we can dupe this with the origin-scoping work if it sounds ok to you. Thanks!

Hey Raymes,

> For example, if someone has granted javascript and geolocation to twitter.com there will be 2 entries in the list - one for [.*]twitter.com and one for twitter.com. It's not simple to merge the two things because they are scoped differently.

I agree that this is a very strong argument for scoping permissions per origin. Also given that twitter was the only site I could come up as an example (because it's one of the few sites that use a naked domain), I don't feel as strongly against scoping JS and image blocking per origin anymore. I think it would be nice to have an option to say "Allow/Block for this site and all its subdomains", but that would just be icing on the cake.

That said, I think this bug will still be valid even with origin scoping: If the user manually added a filter for [*.]twitter.com, the setting mobile.twitter.com gets will still not be the global default, so this still seems worth fixing. WDYT?

> That said, I think this bug will still be valid even with origin scoping: If the user manually added a filter for [*.]twitter.com, the setting mobile.twitter.com gets will still not be the global default, so this still seems worth fixing. WDYT?


I agree. I like your suggestion 2: Change the string for "Use global default (*)" to something else that reflects the fact that the setting is overriden. 

I'm not sure exactly what the string would be, it's a bit tricky to convey the idea. We already need an "overridden by" concept in the UI, e.g. if someone sets an enterprise policy we should disable the drop-down and mark it as overridden. Perhaps we can do the same with custom exceptions, i.e. we still have "default (*)" option but if you set it to that while having a custom exception enabled it would show something (icon, etc.) which indicates it's overridden by the custom exception? It's a hard problem!

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

raymes: Do you mind if I assign this to you to deal with as part of your origin scoping work?

Of course :)

This issue has been moved once and is lower than Pri-1. Removing the milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Since this coming up in the context of permission embargo, here's one simple way to run into this:

Set the user default for Flash to "Block".
Add an exception for "https://*", set to "Ask".

When you Open Page Info, the permission state next to Flash says "Ask".
But when you click on the dropdown, it says "Use global default (Block)".

There are some people (including me) who have similar settings for Javascript, because of Chris Palmer's suggestions for safer Chrome settings:
https://noncombatant.org/2014/03/11/privacy-and-security-settings-in-chrome/

Also, note that a domain can inherit a content setting from multiple ancestors, who aren't even strictly ordered. https://a.b.example.com is covered by all the following:

- https://a.b.example.com
- a.b.example.com
- https://[*.]b.example.com
- [*.]b.example.com
- https://[*.]example.com
- [*.]example.com
- https://*

Deleted: before-dropdown.png 17.5 KB

	before-dropdown.png 17.5 KB View Download

Deleted: after-dropdown.png 51.9 KB

	after-dropdown.png 51.9 KB View Download

Two more notes for #35:

1. Some permissions used to be granted as a wildcard.
That is, if you saw a prompt on https://example.com, it would be saved as something like https://[*.]example.com

From what I understand, many users will still have these old settings.

2. You can also specify the port in a content settings pattern. So you can optionally add ":443" to all the examples at the end of #35, e.g. https://[*.]b.example.com:443

This specific bug (with the repro steps given) no longer occurs as we've changed the way content settings are scoped by default. So, marking this as Fixed.

However the underlying problem still exists, and is covered by a new bug issue 704825.

benwells@: What about users with existing content settings like this? That case still triggers this bug, right?

I think the underlying issue is really the same as issue 704825 so I'm duping there.