Working on bisect. will provide the info soon

Using the per-revision bisect providing the bisect results,
Good build:54.0.2832.0 (Revision: 412743)
Bad build:54.0.2833.0  (Revision: 413134)

You are probably looking for a change made after 413025 (known good), but no later than 413026 (first known bad).

CHANGE-LOG URL:
---------------------------------------

https://chromium.googlesource.com/chromium/src/+log/4bb66d2c936984bd48c541305d122a02a46ecc9a..feeb114ee91d6bb97f162f2c05f66f6d3ef84c15


From the CL above, assigning the issue to the concern owner

@ stevenjb : 
------------------

Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.

Review-Url:  https://codereview.chromium.org/2256753003

Able to repro on chrome latest M55-55.0.2883.28.
 
stevenjb@ - Can we get any latest update on this issue? if it's related to your change.

-> dpapad@ who is investigating scrolling issues.

Briefly investigated this bug. At https://cs.chromium.org/chromium/src/chrome/browser/resources/settings/on_startup_page/startup_urls_page.html?l=16, we set an explicit size to allow the iron-list to display exactly 6 elements. This calculation is very fragile because
1) It is place on #outer, instead of #container. #outer also contains two buttons at the bottom, not part of the iron-list.
2) When zooming in/out, borders lengths are slightly adjusted by Chrome, so the declared value of 1px is not true anymore, breaking the calculation and causing the scrollbar to appear.

@dbeam: Do you have any ideas on how to make this robust, such that the iron-list displays always exactly 6 elements, regardless of zoom-level?

i don't think the 395px value matters.

it's that the browser is bumping up against that max-height while zoom is changing that is weird to me.

I'd also be interested in why we'd like to show exactly 6 items.

Searching through code history, showing 6 items landed at https://chromium.googlesource.com/chromium/src/+/72679618a08ccd653fcca4efab460a5b2ebf0eac. Perhaps @dschuyler knows why it was chosen.

It was an aesthetic call by Alan. (That's why the CL description says "This
was requested by Alan"). 

I'm confident that it can be changed without too much concern from Alan - as long
as it looks good. Before that change, iirc, the list was unlimited. Alan nor I liked 
it being unlimited and Alan said six was a good place to limit the list.

Six rows was not a magic, special number. If there's another limit (or way 
to limit the list) that looks good and works better - I say go for it (and 
I'm 99% confident Alan will say so as well).

+cc/bettes@ in case I'm off on predicting Alan's opinion.

Thanks for the context.

The issue AFAIU is not the exact X number of items to show by default, but the fact that correctly calculating the height of the list such that there are exactly X items shown at different zoom levels, without causing a scrollbar to flash while transitioning through zoom-levels, seems fragile.

The 395px value came our of that context. While there were no obvious issues
with setting that value at the time, I understand that an issue was found.

I'd like to learn how to make this work better too. I'm keen on hearing more
from this question in #6
> @dbeam: Do you have any ideas on how to make this robust, such that the iron-list displays always exactly 6 elements, regardless of zoom-level?

In case it helps: 
We had another issue show up in a different list (sorry I don't have a bug link) where showing an exact N rows made it hard to see that there were more items in the list (on Mac specifically, where the scroll bar will not be visible sometimes). In that case, the workaround was to show five and a half rows. 

Where that information could help this bug is: 
We may not want to show a carefully calculated exact number of rows. We may do well to err on the side of showing a smaller box if it proves difficult to calculate an exact value.

Just to to update the latest behavior of the bug, Issue is still observed on chrome latest Canary M57-57.0.2926.0

dpapad@ Could you please let us know is there any recent update available on this issue?

Thanks!

Marking bugs (mostly lower priority ones) that I am unlikely to get to soon as Available.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

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