If you can't share or create the test case, I'm afraid it's not possible to handle this bug report, but maybe you can find the revision range that contains the breaking change yourself: https://www.chromium.org/developers/bisect-builds-py

The bug is to do with the % value in the padding and margin for the element .mi.

Basically, we have a single-page application where the pages are rendered dynamically. So when navigating it looks like Chrome is calculating the % from an incorrect container width - i.e. it is calculating the container width before the child elements have been rendered.

Frankly, there is enough information in the ticket for someone to reproduce this issue. All you have to do is to create the markup and styling as shown in the last image.

Here it is:

<menu class="mt"><li class="mi" data-bind="css:css, attr: { title:tooltip}">
    <a class="mi-link" data-bind="html: text, attr:{tabindex: tabIndex}" draggable="false" tabindex="127">exhibition</a>
</li><li class="mi" data-bind="css:css, attr: { title:tooltip}">
    <a class="mi-link" data-bind="html: text, attr:{tabindex: tabIndex}" draggable="false" tabindex="128">fair</a>
</li><li class="mi" data-bind="css:css, attr: { title:tooltip}">
    <a class="mi-link" data-bind="html: text, attr:{tabindex: tabIndex}" draggable="false" tabindex="129">festival</a>
</li><li class="mi" data-bind="css:css, attr: { title:tooltip}">
    <a class="mi-link" data-bind="html: text, attr:{tabindex: tabIndex}" draggable="false" tabindex="130">screening</a>
</li><li class="mi" data-bind="css:css, attr: { title:tooltip}">
    <a class="mi-link" data-bind="html: text, attr:{tabindex: tabIndex}" draggable="false" tabindex="131">show</a>
</li><li class="mi" data-bind="css:css, attr: { title:tooltip}">
    <a class="mi-link" data-bind="html: text, attr:{tabindex: tabIndex}" draggable="false" tabindex="132">sport</a>
</li><li class="mi" data-bind="css:css, attr: { title:tooltip}">
    <a class="mi-link" data-bind="html: text, attr:{tabindex: tabIndex}" draggable="false" tabindex="133">stage</a>
</li></menu>



.mt {
  height: 100%;
  width: 100%;
  display: flex;
  align-items: flex-start;
  flex-wrap: wrap; }

/* Default menu item */
.mt .mi {
  cursor: pointer;
  background: #d9d9d9;
  margin: 5px 1%;
  outline: 0.1em solid #ccc;
  padding: 5px 2%;
  /* Adding the padding to the label cause line breaks in the menu text */ }

/* Default menu item label */
.mt .mi-link {
  text-align: center;
  color: #444;
  padding: 0; }

/* Selected menu item */
.mt .mi.selected {
  background: initial;
  color: #40A629;
  outline: 1px solid #40A629; }

.mt .mi:hover .mi-link {
  outline: 0; }

.mt .mi:hover {
  background: initial;
  color: #40A629;
  outline: 1px solid #40A629; }

/* Selected item label */
.mt .mi.selected .mi-link,
.mt .mi:hover .mi-link {
  color: #000;
  outline: none;
  /* The container div is the same colour and larger than the label; hence outline should not exist */ }

/* Tablets and above */
@media screen and (min-device-width: 768px) {
  .mt .mi {
    margin: 10px 1%;
    padding: 15px 2%; } }

Can you reproduce the bug with the posted html and CSS? It works correctly here. The file is attached.

Deleted: test.html 2.3 KB

test.html 2.3 KB View Download

Yes, in a normal rendering scenario it would work correctly (which is why it works correctly on refresh). In order to reproduce this it will be necessary to delay adding the <li> elements. 

In our application these <li> elements are created dynamically. So basically as I stated above, Chrome is calculating the container's (<menu> element's) width early and not updating after the <li> elements are added. This is why the % padding and margin are wrong.

It can be fixed by converting the % padding and margin to px. But IMO this is a bug in Chrome. It was a regression introduced by the latest version.

Just delaying with setInterval or setTimeout doesn't cause the bug to appear here. Might be related to the custom font you use. This is why it's important to have a reproducible test case, otherwise the triaging the bug may take a *very* long time.

Well don't fix it then, mate. I'm not the one making money from Chrome. I don't quite understand the attitude: I report a bug => You guys investigate and fix it. Not: I report a bug => I spend my time fixing your product.

(We are not using a custom font)

I'm not a chromium developer so your condescension is misplaced. I'm just stating the obvious as a fellow software developer with a lot of experience: it's usually impossible to find the cause of a bug in a huge project when there is no easily reproducible test case.

My apologies. Please pass this issue on to people who are paid to do the work. I personally do not have any time to spend on supporting Google.

As it is difficult to triage the bug without the testcase/file. Adding related components, so that someone from respective team would help in further investigation.

Thanks!

Thanks for the report.

Do you have a link to a page demonstrating the problem? Sadly the screenshots are not quite enough for us to track down the issue.

Okay here are the instructions:

1. Go to https://thecultural.me
2. Log in with email "user@example.com" password "pass123"
3. Click on the "+" icon in the header.
4. Click on "artist" or any of the other types.

This should display the page with the faulty rendering.

Please try to complete your investigations within 24 hours. We are deploying a fix for the bug tomorrow. And also the temporary login will be removed.

Thank you for providing more feedback. Adding requester "eae@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Just noticed there is a simpler way to show you the faulty rendering:

1. Go to http://thecultural.me/
2. Click on the "language" tab.

This should render the page as shown in the attached file.

Deleted: Untitled.png 7.0 KB

	Untitled.png 7.0 KB View Download

Thanks.

Morten, any idea what's going on here?

Please can you complete your investigations ASAP. We are deploying a fix tomorrow, which will mean the faulty rendering will no longer repro.

I can reproduce this in Chrome 60, but not in Chrome 61 or Chrome 62, all Linux. So I guess it's fixed already.