Dominick, can your team look into this?

Thanks for the report. I agree that it is strange that accessing a site page like this only shows one of the two permissions.

Long term, I want to revamp this entire UI. Short term, making the "drilled in" display identical to going to Site Settings via the lock icon seems ideal, though perhaps there would be a new confusion where you clicked into a site via a permission type, and that permission type you clicked wasn't at the top of the permission list.

@rolfe: What do you think about this?

@tedchoc: It looks to me like there are two different classes for displaying site settings on Android - one for when all permissions are to be displayed, and one for when just one permission should be displayed. Do you know what the history is behind having the split? (Was it due to an explicit choice to have the per-permission view only display the permission that you chose?)

+finnur who may know more on why it works this way today

I agree any time you access a site's settings (whether via a permission list or through it's page info) it should show all the permissions explicitly allowed/blocked. Would be great to amend this flow to show both permissions no matter the access path.

Sorry for the late reply, I was out sick all last week.

I'm not sure why there's a difference there, I suspect there might be some slight differences in how the permission is stored, which causes the code to treat this as more than one origin and therefore not show all the permissions. I seem to recall code someone wrote to attempt a merge (see mergePermissionInfoForTopLevelOrigin) -- maybe that's not working or is being called only one one codepath.

> It looks to me like there are two different classes for displaying site settings on Android - 
> one for when all permissions are to be displayed, and one for when just one permission should 
> be displayed. Do you know what the history is behind having the split?

There's two ways to read this question. But let me make clear: There should be no UI intended to show only one permission for a given site (when it has more). As for the other possible reading: that we have one UI that shows all permissions (such as the OOI bubble) and one UI that shows only explicit overrides (Site Settings). That is the case. 

I may be wrong, but I seem to recall that the main use-case for showing all permissions (even ones with default values) was configurability -- but that became less important as UI controls under Site Settings were fleshed out. The OOI bubble still has it, though. Don't know if that's intentional.

But I think the intent, when you drill down to a particular site under Site Settings, is always to list all permissions that a site has. We should treat the fact that it doesn't as a bug.

Yes- specifically it should list all the permissions a user explicitly granted it or that are atypical (e.g. not default ones like granted images or something.)

I'm not sure who should own this but removing myself as this I don't think is something UX can resolve. Needs eng help when available!

+emilyschechter to help with triage potentially (pretty sure dominickn@ is booked)

This isn't surprising and is probably due to weird scoping stuff.

If you need UX support on this going forward, reach out to maxwalker

+cc timloh

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

commit 2fda8441c81bbe5cb9af9cdf4cde28eae6bfba4b
Author: Timothy Loh <timloh@chromium.org>
Date: Thu Nov 16 04:48:46 2017

Fetch all permissions when drilling down into site settings from a particular permission

The following UI flow currently only shows the selected permission type,
even if other permissions have non-default values for the selected site:

- Settings -> Site settings -> (e.g.) Location -> (e.g.) permission.site

Upon tapping Location, we fetch content settings data for only Location,
and currently don't re-fetch when drilling down. This CL changes this to
fetch all permissions when drilling down (excluding All Sites, which has
already fetched everything) so the list will be properly populated.

Bug:  673620 
Change-Id: Ic1ecaaba00595c7c3ccd59119b787dab12498ee2
Reviewed-on: https://chromium-review.googlesource.com/770932
Commit-Queue: Timothy Loh <timloh@chromium.org>
Reviewed-by: Ted Choc <tedchoc@chromium.org>
Cr-Commit-Position: refs/heads/master@{#516991}
[modify] https://crrev.com/2fda8441c81bbe5cb9af9cdf4cde28eae6bfba4b/chrome/android/java/src/org/chromium/chrome/browser/page_info/PageInfoPopup.java
[modify] https://crrev.com/2fda8441c81bbe5cb9af9cdf4cde28eae6bfba4b/chrome/android/java/src/org/chromium/chrome/browser/preferences/website/SingleCategoryPreferences.java
[modify] https://crrev.com/2fda8441c81bbe5cb9af9cdf4cde28eae6bfba4b/chrome/android/java/src/org/chromium/chrome/browser/preferences/website/SingleWebsitePreferences.java
[modify] https://crrev.com/2fda8441c81bbe5cb9af9cdf4cde28eae6bfba4b/chrome/android/java/src/org/chromium/chrome/browser/preferences/website/WebsitePreference.java

This issue is now not reproducible in latest M64-64.0.3273.0 build, but still reproducible on latest M63-63.0.3239.58, fix needs to be merged.