Manual regression range:
Good Build: 51.0.2673.0
Bad Build:  51.0.2674.0

Narrow bisect:
https://chromium.googlesource.com/chromium/src/+log/740c4109f954a11c544c02132a89fabab767e7ab..9ca99ec409a1d6f7baf6dd3cd6929e81c967cac1?pretty=fuller&n=30

Suspecting: 380354 ?
Kindly help to re-assign, if your changes are not cause for this issue.

Deleted: ActualImage.png 81.8 KB

	ActualImage.png 81.8 KB View Download

Deleted: ExpectedImage.png 181 KB

	ExpectedImage.png 181 KB View Download

Deleted: Actual_Result.mp4 837 KB

Actual_Result.mp4 837 KB Download

None of the changes in that range look particularly suspicious, but my change didn't even change code, so that's certainly not it.

How confident are you in the bisect?

in reply to c#2, re-tried the bisect and got the same info..

Good Build: 51.0.2673.0
Bad Build:  51.0.2674.0
CL: 
https://chromium.googlesource.com/chromium/src/+log/740c4109f954a11c544c02132a89fabab767e7ab..9ca99ec409a1d6f7baf6dd3cd6929e81c967cac1?pretty=fuller&n=30

Note : this is working fine in FF 45.0.1 and IE 11

Could you please check the issue and let us know if you need any more information.

adding RB-label as this is recent regression, please change if required.

Just to update, verified the issue on Latest Canary# 51.0.2704.2 on Windows, Mac and Linux and is still able to reproduce the issue.
Thank You.

Just to update still seeing this issue on canary 52.0.2708.0 on Win 7 and MAC 10.11.4. Could some one please take a look into it.

Still seeing this issue on windows using latest canary 52.0.2711.0.
Could any one from dev team please look into this issue.

Thanks,

Okay, I can confirm that I see the issue and that it looks like it worked fine in M49.

Okay, I re-ran the bisect myself, and, sure enough, it looks like https://codereview.chromium.org/1783693002 is what breaks this.

I have no idea why. 

@yuzus, can you take a look?

I can also confirm that we can still revert that change at tip-of-tree if we wanted to (i.e., there are no merge conflicts).

@yuzus: Request you to please take a look into it. Issue is marked with a blocker label. Also issue still persists on current canary 52.0.2713.0 on Win 7, MAC 10.11.4, Ubuntu 14.04.

@yuzus : Gentle Ping.Issue still observed on canary 52.0.2715.0.

cc'ing reviewers from the suspected CL from Comment#9, To get this bug fixed as I am still seeing the issue on latest Chrome Beta i.e., 51.0.2704.29 on Windows, Mac and Linux.

hayato@ Looks like adding .rootNode to Element seems to have broken some pages? We might need to pick a different name.

The Element.rootNode spec is already upstreamed to the DOM spec:
https://dom.spec.whatwg.org/#dom-node-rootnode

This is the result of agreement among vendors, so it is hard to rename or
revert the change.  Adding a new interface to Element inevitably cause
breaks on some forward-incompatible sites.
https://github.com/w3c/webcomponents/issues/80
(Note that this could also happen who uses their own Node.isConnected)

Probably it's too late to rename the API and all we can do is to notice the
site owner/author to pick a different name.

Here's intent to ship:
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/LpXX7Svx8IY/Hu54zinaAwAJ

> Interoperability and Compatibility Risk
> This is a brand new feature so there is no risk of compatibility.
> As for interoperability, Webkit already implemented it. 
> http://trac.webkit.org/changeset/195682

Probably we should be careful to add a new interface to existing
namespace in the future.

BTW, the code that uses 'rootNode' seems this one:
http://www.thebay.com/wcsstore/TheBay/dist/js/product-display.js

The usage seems to me that 'rootNode' is used for a key of
JS object, so basically it should not conflict with Node.rootNode.

Maybe some code like checking if e.rootNode is undefined or not
to determine that |e| is the user-defined object or not, but
when a Node is passed as |e| on newer Chrome, e.rootNode is
not undefined and the code exposes unexpected behavior.

Would adding [Unscopable] fix this? 

FYI.
The discussion in on-going on whatwg/dom: https://github.com/whatwg/dom/issues/241

See also  bug 608006 .