Somehow I cannot repro on 65.0.3298.0 on Win 10 machine. 
But assign to patricialor@ anyway to take a look. 

Yeah, I took a look at this yesterday but couldn't reproduce either (win10, google.de, location allowed). I was testing on 65.0.3297.0 though.

maxwalker@, do you mind updating your Canary and trying again?

Just updated to 65.0.3300.0 and the problem is still there. I think it might be an issue with non-integral scale factors (1.5x, 1.75x, 2.25x, 2.5x etc). Please try the following steps to reproduce:

(1) In Windows Settings > Display > Scale and layout: set scale to 150% or 250%
(2) Maximize Chrome window
(3) Open Page Info

That was it! Thanks Max, I'll take a look at this when I get the chance.

 Issue 795555  has been merged into this issue.

 Issue 803483  has been merged into this issue.

patricialor: are you able to repro this? See the video in  Issue 803483  

+tapted in case he has any ideas on what this could be

Yep, I tracked this down a while ago and I suspect it might happen on all bubbles on non-integral scale factors that get SizeToContents repeatedly called on them (not from any particular View). The cause (I think) is this method ScreenToDIPRect() calling ScaleToEnclosingRect():

https://cs.chromium.org/chromium/src/ui/display/win/screen_win.cc?rcl=8ea5e66efeeaa1f3579aea1cfab40926dd345e98&l=277

According to the method description here:

https://cs.chromium.org/chromium/src/ui/display/win/screen_win.h?rcl=55acc7988fd1aeee1904b3b914cd33787d26bc68&l=71

this is intended behavior. Replacing the ScaleToEnclosingRect() call with a ScaleToEnclosedRect() seems to fix it but that's probably not the correct solution, but I'm not sure what would be :/

I currently have this on the backburner though since I don't think it's super high priority.

> Yep, I tracked this down a while ago and I suspect it might happen on all bubbles on non-integral scale factors that get SizeToContents repeatedly called on them 

Are there any cases other than PageInfo that you know of where that might happen? 

> Replacing the ScaleToEnclosingRect() call with a ScaleToEnclosedRect() seems to fix it but that's probably not the correct solution, but I'm not sure what would be :/

Should we ask someone with more views expertise? If this happens every time some users open Page Info, it seems quite bad to me.

> Are there any cases other than PageInfo that you know of where that might happen? 

Not sure - just did a quick search for 'SizeToContents()' and it looks like a few bubbles do this, e.g. TrayBubbleView and TranslateBubbleView. I haven't looked further to see if these are actually repeated calls though or if they're once-offs. PageInfoBubbleView is just really bad because on pages that use cookies, it'll repeatedly call SetCookieInfo() which calls SizeToContents(), even if there are no cookies to be updated. A workaround would be to record the number of cookies in use and do an early return in SetCookieInfo() if the new number of cookies is the same, but this wouldn't prevent the bubble from growing while new cookies load in.

> Should we ask someone with more views expertise?

Yes, that would probably be good - I don't really have any idea what to do about it at this point. I'm guessing tapted@ would be the right one but please feel free to CC more people / load balance :)

> If this happens every time some users open Page Info, it seems quite bad to me.

I dunno - this bug was probably occurring before Harmony and I don't think anyone noticed then, so that was my rationale. (Just double checked - this does occur with --disable-features=SecondaryUiMd.)

Some more specific repro instructions expanding from #c4:
(1) In Windows Settings > Display > Scale and layout: set scale to 150% or 250%
(2) Open Chrome, navigate to https://nytimes.com
(3) Open Page Info and observe.

Thanks for looking Patti!

> I dunno - this bug was probably occurring before Harmony and I don't think anyone noticed then, so that was my rationale.

I see, that would make sense. I'm a little concerned though that we've had 2 independent reports recently which makes me feel like it may still be a relatively recent regression. But it's possible that it's been around for a while and people just haven't reported it.

It would be good to get feedback from other views experts.

Just experienced this bug on the latest stable 64.0.3282.119. It can make it almost impossible to change permissions on certain websites from the bubble. I also noticed that the speed might correlate somewhat with the number of cookies for a website.

patricialor: did you have a chance to try the bisect tool on this? 

Yup! Sorry for the delay, I looked for a "good" version of Chrome the hard way :(

This is caused by https://chromium.googlesource.com/chromium/src/+/ed10b06. I don't think this helps with an actual fix but as a workaround it might just be worth reverting it.

+oshima@ for scale factor expertise and +robliao@ for ui/display/win ownership - would either of you have any idea about what we could try to fix this?

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

commit 25cd20b5e89acf9fcc830799f9424cab1e226e15
Author: Patti <patricialor@chromium.org>
Date: Thu Feb 01 00:55:46 2018

Revert "Desktop Page Info/Harmony: Never decrease the size of PageInfoBubbleView."

This reverts commit ed10b0686bf7bb251375ddd0ff11c66c7cefeb21.

Reason for revert: This causes  crbug.com/795272 , but there isn't a good fix for this at the moment. Revert this as a workaround for now.

Original change's description:
> Desktop Page Info/Harmony: Never decrease the size of PageInfoBubbleView.
> 
> The PageInfoBubbleView, when long strings are selected in its comboboxes, can
> sometimes expand its original size in Harmony mode. It will then shrink again
> if the long combobox option is changed back to a shorter one. This makes the UI
> move around a lot, so prevent it from getting smaller again.
> 
> Bug: 657250
> Change-Id: I49262900cc386ae2e57e02ba82a51cdae12e08a9
> Reviewed-on: https://chromium-review.googlesource.com/771050
> Reviewed-by: Lucas Garron <lgarron@chromium.org>
> Commit-Queue: Patti <patricialor@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#516966}

TBR=lgarron@chromium.org,patricialor@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: 657250,  795272 
Change-Id: Ibbefa40b7dd32e1f69bdb04c4895594f053985a7
Reviewed-on: https://chromium-review.googlesource.com/894927
Reviewed-by: Patti <patricialor@chromium.org>
Reviewed-by: Raymes Khoury <raymes@chromium.org>
Commit-Queue: Patti <patricialor@chromium.org>
Cr-Commit-Position: refs/heads/master@{#533497}
[modify] https://crrev.com/25cd20b5e89acf9fcc830799f9424cab1e226e15/chrome/browser/ui/views/page_info/page_info_bubble_view.cc

 Issue 805042  has been merged into this issue.

Re: #17

I haven't looked deeply into this, but my suspicion is that there is a sizing loop. I would use a remote debugger and set a breakpoint on when the bounds change. This will assist in identifying the loop and the problematic rounding call. Let me know if you need more details.

Yeah, we have a repeated SizeToContents() being called on the bubble each time the number of cookies gets updated. Originally I thought we wanted this to account for the case when the number of cookies changes and text gets slightly wider, which happens in verbose languages (e.g. the screenshot in russian below).

But I think we don't actually expand the bubble to account for the cookie text, only when permissions get wider. Maybe a compromise would be to investigate whether we can remove this call at the end of PageInfoBubbleView::SetCookieInfo()?

Deleted: Screenshot from 2018-02-02 11-55-13.png 42.3 KB

	Screenshot from 2018-02-02 11-55-13.png 42.3 KB View Download

Is the cookie store structured in such as way where it's easy to determine all of the cookies up front or is it async and gradual?

If it generally doesn't take a long time to obtain the cookie info and it's possible to get all of the data up front, I would suggest deferring adding the cookies until all the cookies arrive. This way the dialog can do one layout pass and perform one (hopefully stable) SizeToContents() for the dialog.

 Issue 816546  has been merged into this issue.

 Issue 817438  has been merged into this issue.

**UI Mass Triage**

We were unable to reproduce this bug. If this bug still reproduces for you, 
please reopen or file a new issue. 

Thanks!