https://jsfiddle.net/bg2u7aey/2/
Would be better(simple) to test and right click work too.
(sorry  for my english i'm not a native English speaker)

====================================

Good Build:

39.0.2140.0   Base Position: 292587


Bad Build:

39.0.2168.0   Base Position: 296386

=====================================

Able to repro this issue on Windows 7, MAC (10.11.3) & Ubuntu Trusty (14.04) for the Google Chrome Stable Version - 49.0.2623.110

This is a regression issue broken in M39, below mentioned is the bisect info:

CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/71723cbdf0f1d15ec88f59d1ceb423673ebdef6a..6ef3c55508e568e191db4fbbd848b83fd445d7ab

https://chromium.googlesource.com/chromium/src/+/aa53c902adbfac7ec6b812958f84bd34cd373827

Suspecting Commit: e306342ba6b7f74c1be3745e789d75ffe0e809b0			

Review URL: https://codereview.chromium.org/455223002

@rob: Could you please look into the issue, and if it has nothing to do with your changes and if possible please do assign it to the concerned owner.

Thank you.

The root cause is not my change. Here is the reduced original test case, with two extra tests: https://jsfiddle.net/bg2u7aey/4/ (the first two boxes have a default outline on focus, the last box has an outline on hover).

This issue seems to be caused by calculations related to:
- RELATIVE margins (%, using absolute values like px works fine)
- changing the outline width (e.g. by focusing an anchor, which has an outline style by default).

Here is a minimal reduction (open the following URL in Chrome, and hover over the "hoverme" box).

data:text/html,<style>div{float:right}span:hover{outline:1px solid red}span{margin-left:50%}</style><div><span>hoverme</span></div>

What I see is that initially there are scrollbars (and the box is partially outside the viewport), but when I hover over the box, it moves to the left (the relative margin tends to disappear).

In Firefox, the box is also outside the viewport (with scrollbars), but at least it does not move.

So the real issue is that changing the outline width incorrectly changes the calculation of relative margins.

I don't know who should own this bug, please re-triage.

Thanks for investigating Rob. Based on your analysis, I'm requesting another bisect using your testcase.

Can't find the relevant revision numbers to trigger a bisect, assigning to  rnimmagadda who seems to know the magic way to find revisions for old releses.

@eae You can map version numbers to revisions at https://omahaproxy.appspot.com.

I also have a personal archive of old releases, and found that the regression started in 35.0.1916.153. Unfortunately omahaproxy isn't able to find the revision, so I used the tag-to-commit map on your site (git log should also work) to find the commit relevant revisions for bisecting:
1. Visit https://blink.lc/chromium/commit/?h=35.0.1916.0 and https://blink.lc/chromium/commit/?h=35.0.1916.137
2. Click on "parent" link -> https://blink.lc/chromium/commit/?h=35.0.1916.0&id=425fbf76a6833967b4f54e50a73bc5752f4b68d5 and https://blink.lc/chromium/commit/?h=35.0.1916.137&id=b28c2570e95ea91b834db72ffd3cba6223058276
3. The revision number can be read from the git-svn-id, 260298 and 272404

bisect-builds.py -a linux64 -g 260298 -b 272404 /tmp/bug.htm -- --disable-setuid-sandbox
...
You are probably looking for a change made after 263002 (known good), but no later than 263006 (first known bad).
NOTE: There is a Blink roll in the range, you might also want to do a Blink bisect.
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/b62a4e06409967be310bd5edd09f3c966500c8aa..7db812d67dd82122470a8104948e3d6df92b2430

The link to the Blink roll (171141:171269) is dead, so I tried to find an alternative range via https://blink.lc/chromium/log/third_party/WebKit?qt=grep&q=171269 (this gave me a commit ID, used in the next link) ->
https://blink.lc/chromium/log/third_party/WebKit?id=06419b4d84f33b164c449ffc0498f71f486c9bb7 (the range starts at https://blink.lc/chromium/commit/third_party/WebKit?id=c807e26f28e56f4f4929377b06ef33189a843f06).


I suspect https://blink.lc/chromium/commit/third_party/WebKit?id=8bbcf72c2a27bd0e991797de5594c9abd7751f2b ( issue 355983 ).

Thanks rob!

jchaffraix doesn't work on the project anymore.

====================================

Good Build:

39.0.2140.0   Base Position: 292587


Bad Build:

39.0.2141.0   Base Position: 292777

=====================================

Able to repro this issue on Windows 7, MAC (10.11.3) & Ubuntu Trusty (14.04) for the Google Chrome Stable Version - 49.0.2623.110

This is a regression issue broken in M39, below mentioned is the bisect info:

CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/39.0.2140.0..39.0.2141.0?pretty=fuller&n=10000

Suspecting Commit: acdf1c157fce2d1330a6eae61fb71f153355efbe			

Review URL: https://codereview.chromium.org/504073002

@yoshiki: Could you please look into the issue, and if it has nothing to do with your changes and if possible please do assign it to the concerned owner.

Thank you.

Deleted: Good - 39.0.2140.0.mp4 426 KB

Good - 39.0.2140.0.mp4 426 KB Download

Deleted: Bad - 39.0.2141.0.mp4 433 KB

Bad - 39.0.2141.0.mp4 433 KB Download

Used the new test case as per the comment #3

https://jsfiddle.net/bg2u7aey/4/

That suspect looks extremely unlikely, since it does not affect the rendering of web pages.

Could you repeat the repro in step 3, using the following content for /tmp/bug.htm
<style>div{float:right}span:hover{outline:1px solid red}span{margin-left:50%}</style><div><span>hoverme</span></div>

When I ran a bisect, I got the results as written in #7 (around 36.0.1935.0).

If you're able to, consider performing a blink bisect in the range 171141:171269.

@rob: Re-checked it again and I was getting the same range as mentioned in the comment #9

Here I was clicking on the "Link" in the provided jsfiddle.

I shall try the "hover me" and would update the results accordingly.

Thank you.

@rob: As per you mentioned in the comment #3 regarding the "Hover Me" -> "the box is also outside the viewport (with scrollbars), but at least it does not move.", performed the bisect again and got the below output.

Good & Bad builds video is attached.

====================================

Good Build:

36.0.1934.0   Base Position: 262938


Bad Build:

36.0.1935.0   Base Position: 263101

=====================================

Able to repro this issue on Windows 7, MAC (10.11.3) & Ubuntu Trusty (14.04) for the Google Chrome Stable Version - 49.0.2623.110

This is a regression issue broken in M39, below mentioned is the bisect info:

CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/f8c6c344f13d64c5e20a7b2a6ccbdd3eeaf7b8d3..6f451a479d2a50960c9250d58d6884254004c999

https://chromium.googlesource.com/chromium/src/+/7db812d67dd82122470a8104948e3d6df92b2430

https://chromium.googlesource.com/chromium/blink/+log/683222539dc2bd281a2ed2bff0f788840bf97006..a4151eff69882fbd8bafdf5802e03bfa3d871569

Suspecting Commit: a96941d2ecdc5d4bc16566ec52368741060b8f1b			

Review URL: https://codereview.chromium.org/232173005

@yurys: Could you please look into the issue, and if it has nothing to do with your changes and if possible please do assign it to the concerned owner.

Thank you.

Deleted: Good - 36.0.1934.0.mp4 364 KB

Good - 36.0.1934.0.mp4 364 KB Download

Deleted: Bad - 36.0.1935.0.mp4 754 KB

Bad - 36.0.1935.0.mp4 754 KB Download

Nothing in that range looks even remotely related.

@eae
The Blink URL in #13 contains a range that is too narrow. I also bisected in #7 and found the same range (171141:171269). All commits are here (with some likely candidates):

https://chromium.googlesource.com/chromium/blink/+log/e4ddd1521097daa26da8dac5d57caf48c00e6d3f..a4151eff69882fbd8bafdf5802e03bfa3d871569?n=126

(thanks to #13 I found the correct hash, why is this different from the ones on blink.lc (links in #7)?)

Thanks Rob!

https://chromium.googlesource.com/chromium/blink/+/7a6854b02dede455a7f15d5bdc2d96edd46cc0ae looks like it could have caused this. Sadly Julien isn't on the team anymore.

@rnimmagadda: I'm not on Chrome team anymore, please reassign.

Unable to find the exact culprit from the bisect range mentioned in the comment #13. Hence, requesting someone to look into this.

Thank you.

@rob: As mentioned in the comment #13, from the JSFiddle - https://jsfiddle.net/bg2u7aey/4/

1. Clicking on the word "Link" moves that word from to left side. Bisect details for that is mentioned in the comment #9
2. Hovering on "Hover Me" moves and shows the entire text. Bisect details for that is mentioned in the comment #13

Thank you.

This issue has been available for more than 365 days, and should be re-evaluated. Please re-triage this issue.
The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue.

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

robhogan, would you mind looking into this one when you get a chance? 

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

commit 037075a489638e0c6d8adf4a25184949efd36c1d
Author: robhogan <robhogan@gmail.com>
Date: Mon Apr 10 20:11:38 2017

Don't let current width affect preferred width on shrink-to-fit containers

When shrinking-to-fit a container don't let the current width affect its
preferred widths. This will happen if we let percent margins on child inlines
calculate themselves against the block's current calculated width. To avoid
this reset the container's width to zero so that percent margins are ignored
in the preferred width calculation.

BUG= 598711 

Review-Url: https://codereview.chromium.org/2802413002
Cr-Commit-Position: refs/heads/master@{#463378}

[add] https://crrev.com/037075a489638e0c6d8adf4a25184949efd36c1d/third_party/WebKit/LayoutTests/fast/inline/percentage-margins-shrink-to-fit-expected.html
[add] https://crrev.com/037075a489638e0c6d8adf4a25184949efd36c1d/third_party/WebKit/LayoutTests/fast/inline/percentage-margins-shrink-to-fit.html
[modify] https://crrev.com/037075a489638e0c6d8adf4a25184949efd36c1d/third_party/WebKit/Source/core/layout/LayoutBox.cpp