I looked into this a bit.  There's a table whose <td> switches between 2 and 4 pixels to the right of it's parent <tr>:

Initially:
document.querySelector("td.print-options-container").getBoundingClientRect().left
> 317
document.querySelector("td.print-options-container").parentNode.getBoundingClientRect().left
> 315

After clicking:
document.querySelector("td.print-options-container").getBoundingClientRect().left
> 319
document.querySelector("td.print-options-container").parentNode.getBoundingClientRect().left
> 315

I don't see any style change or anything that would result in this.  I guess it's plausible that rune@'s CL changed something.  The only other CL in the list that seems at all plausible is the V8 roll.

Rune, WDYT, do you think it's possible this is your CL?  If not we can add Needs-Bisect to get a per-CL bisect from the test team.

In theory, it should not have an effect as the handling of the invalid selectors was moved to the parser in a separate CL before this change, but it looks like reverting this locally helped. Will look into it tomorrow.

Thanks for checking Rune!

This CL re-introduces parts of code removed in the culprit (which makes sense to re-add) which removes the effect seen in this issue:

https://codereview.chromium.org/2850743003/

I think the underlying issue is most likely a table layout bug, but I haven't reduced it yet.

Looks like the border-spacing is subtracted twice on re-layout.

If I add this rule to the inspector sheet:

  table {
    border-spacing:  0 !important;
  }

the table cell content does not move when clicking the radio button. If I add 

  table {
    border-spacing: 20px !important;
  }

It moved 20px on the re-layout.

A table split in two by two 50% width cells which are initially 292px (table width is 590px). The cell width is reduced by the border-spacing value on re-layout here:

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/layout/LayoutTableSection.cpp?type=cs&q=setcelllogicalwidth+package:%5Echromium$&l=987-990

I've been able to reduce the Google docs spreadsheet down to the attached case.

Deleted: xls.html 494 bytes

xls.html 494 bytes View Download

I got rid of custom scrollbar pseudos and generated content. The new test is included in https://codereview.chromium.org/2855853002/

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

commit d3c625b0b03346472e45dc1fda33d35b1d40efd3
Author: rune <rune@opera.com>
Date: Wed May 03 08:53:57 2017

Don't update column position in StyleDidChange.

StyleDidChange set the first column position to the horizontal border
spacing value regardless of whether this value changed or not.

I am not familiar with how table layout works in Blink and haven't
debugged this extensively, but when we re-layout a table cell because
it has out-of-flow content which needs layout, the first effective
column position is set wrongly. It gets its initial value from the line
removed in this CL by a style recalc on the table element prior to the
re-layout, which is the h_spacing_, but the spacing is subtracted once
more in http://bit.ly/2pBB7x1

R=eae@chromium.org,mstensho@opera.com
BUG= 716006 

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

[add] https://crrev.com/d3c625b0b03346472e45dc1fda33d35b1d40efd3/third_party/WebKit/LayoutTests/fast/table/relayout-out-of-flow-with-border-spacing.html
[modify] https://crrev.com/d3c625b0b03346472e45dc1fda33d35b1d40efd3/third_party/WebKit/Source/core/layout/LayoutTable.cpp

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

commit 40bdd179053a9b7c6c7eb3a82462a860f981e5d8
Author: rune <rune@opera.com>
Date: Thu May 04 11:34:27 2017

Stop matching scrollbar pseudo element without a scrollbar.

While matching rules for elements, we mark elements as affected-by-* for
user action pseudo classes like hover. It means that when the element is
later hovered, we need to recalculate style to apply hover styles to
that element.

In general, we currently don't support pseudo classes after pseudo
elements, but for scrollbar pseudo elements we do:

  ::-webkit-scrollbar:hover {}

However, we do not want such rules to mark the element as affected-by-
hover. The hover style on scrollbar parts get their hover style updated
when hovered regardless of any flags, and making scrollbar pseudo
element rules affect hover updates on the actual elements causes
unnecessary style recalcs.

BUG= 716006 

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

[modify] https://crrev.com/40bdd179053a9b7c6c7eb3a82462a860f981e5d8/third_party/WebKit/Source/core/BUILD.gn
[rename] https://crrev.com/40bdd179053a9b7c6c7eb3a82462a860f981e5d8/third_party/WebKit/Source/core/css/AffectedByPseudoTest.cpp
[modify] https://crrev.com/40bdd179053a9b7c6c7eb3a82462a860f981e5d8/third_party/WebKit/Source/core/css/SelectorChecker.cpp

Your change meets the bar and is auto-approved for M59. Please go ahead and merge the CL to branch 3071 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop)

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

The merge request is for the commit in https://bugs.chromium.org/p/chromium/issues/detail?id=716006#c11 (d3c625b0b03346472e45dc1fda33d35b1d40efd3).

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

commit cd42d9d7807a142fad25e3697fb711dc4f792e7d
Author: Rune Lillesveen <rune@opera.com>
Date: Mon May 08 21:33:24 2017

Don't update column position in StyleDidChange.

StyleDidChange set the first column position to the horizontal border
spacing value regardless of whether this value changed or not.

I am not familiar with how table layout works in Blink and haven't
debugged this extensively, but when we re-layout a table cell because
it has out-of-flow content which needs layout, the first effective
column position is set wrongly. It gets its initial value from the line
removed in this CL by a style recalc on the table element prior to the
re-layout, which is the h_spacing_, but the spacing is subtracted once
more in http://bit.ly/2pBB7x1

R=eae@chromium.org,mstensho@opera.com
BUG= 716006 

Review-Url: https://codereview.chromium.org/2855853002
Cr-Commit-Position: refs/heads/master@{#468920}
(cherry picked from commit d3c625b0b03346472e45dc1fda33d35b1d40efd3)

Review-Url: https://codereview.chromium.org/2867903002 .
Cr-Commit-Position: refs/branch-heads/3071@{#464}
Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}

[add] https://crrev.com/cd42d9d7807a142fad25e3697fb711dc4f792e7d/third_party/WebKit/LayoutTests/fast/table/relayout-out-of-flow-with-border-spacing.html
[modify] https://crrev.com/cd42d9d7807a142fad25e3697fb711dc4f792e7d/third_party/WebKit/Source/core/layout/LayoutTable.cpp

Verified this issue on Win 10, Mac 10.12.4, Ubuntu 14.04 using chrome latest beta M59 #59.0.3071.47 by following steps mentioned in the original comment. 

No flicking is observed on clicking radio buttons. Hence adding the TE- Verified label

Please refer the screen cast

Thanks,

Deleted: May 10 2017 11-56 AM.webm 3.2 MB

	May 10 2017 11-56 AM.webm 3.2 MB View Download