Marking the above issue as RB-Stable, feel free to remove if not required.

Thank you!

palmer@, could you please take a look as this is M51 Stable Blocker and we're  cutting M51 Stable RC on Tuesday, May 31st. The fix has to be landed and merged to M51 by Tuesday 1:00 PM PST. Thank you.

My change, https://codereview.chromium.org/1766493002, only changed what items are shown in the Origin Info Bubble (permissions with non-default settings -> all permissions unconditionally), not *how* they are shown. So I am pretty sure my change is not the cause of this regression. You may want to look at changes in Views that control how widgets behave.

After some spelunking, pretty sure this change broke the hover effect for these buttons: https://codereview.chromium.org/1270343004

The problem is the --top-chrome-md flag was supposed to only apply to things in the top chrome, and instead it applied to all text-style buttons, including the ones in this bubble. We removed the old hover effect without adding a new one (i.e. ripple).

Although to be fair, these views really need to not be buttons and to be comboboxes instead.

Even though this is a regression it doesn't seem like a p1 to me because the UI is still completely usable. You could easily fail to notice anything was wrong.

estade@, is it possible to do safe revert of suspected CL or fix this bug before Tuesday? The fix has to be landed/baked/verified in canary and merge to M51 by 1:00 PM PST on Tuesday.

Just to update:

The issue is still seen on win8.1 latest canary 53.0.2751.2 

The issue is still seen on win8.1 latest canary 53.0.2757.0

'Material design in the browser's top' chrome flag is not enabled by default on M-51, hence not a blocker for M-51. Adjusting the milestone to get this fixed before M-52 goes to stable.

@tdanderson:

A side effect of one of my MD CLs. The dialog mentioned in this bug has incorrect hover state.

Not sure if the dialog has had an MD overhaul yet, or if as mentioned in #5 if the dialog should start using the correct controls

Assuming you are using the default value of --top-chrome-md, this would be broken in:

* CrOS M-50 stable
* Linux M-51 stable
* Windows M-53 canary/dev

This bug reports cites that it is broken in M-51/M-52 on Windows, but that's only because the reporter has manually enabled --top-chrome-md, which was not flipped on by default for Windows until M-53.

I would not consider this to be a release-blocker, and I think an MD overhaul of this bubble is in progress, so it may not be worthwhile fixing this. Handing off to pkasting@ for his thoughts/triage.

Yeah, this is P3.

Moving this nonessential bug to the next milestone.

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

This bug is tagged as regression.Which means that the bisects are incorrect or do not have an owner who is actively investigating.
Requesting the reporter to triage and update the behavior in all the latest chrome channels and bisect if needed.Close as WontFix if not reproducible.

+tdanderson@: hover in the permission bubble is broken. Could this be triaged to someone on MD? Still just a P3

I'm not up to date on who has been working on the OIB, handing to rpop@ to triage and cc pkasting@.

spqchan owns this, I believe it's a potential dupe of  Issue 588377 

Sarah, could you let us know if this is a dupe?

No, this is a different issue.  Issue 588377 's scope is the omnibox icon decorations while this bug's scope is the page action icons in the dialog.

This should fix it:
https://chromium.googlesource.com/chromium/src/+/bf7e0532e34476062226eab6ef1affe78abc8a8d