I am seeing the same behavior consistently in Windows too.

Chrome version: 57.0.2987.133  Channel: stable

I've encountered this too a couple of times in 57.0.2987.133

This is HUGE. This breaks virtually every website using javascript, and there's no possible workaround whatsoever.

Tried to reproduce on ubuntu 14.04 using M57 #57.0.2987.133 with the url provided in  comment #0 and couldn't reproduce the issue.

Could you please provide us a sample test case , where issue is reproduced consistently.

Thanks!

As I already said, I can't.

This happens randomly, there's no way I know of to trigger it consistently. The page where I observe it all the time where I'm able to reproduce it almost at will (with high probability, but never consistently) is a private one.

Thank you for providing more feedback. Adding requester "hdodda@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

@hdodda@chromium.org
We are able to reproduce this issue in a private app very easily. We are willing to do a screen-share with you to demo the problem.

Please email me if you would like to set something up.

#7, the point of having a reproducible test is to find where the regression occurred which is otherwise pretty impossible. You can try bisecting yourself though: https://www.chromium.org/developers/bisect-builds-py

*** FOR THOSE INTERESTED IN A WORKAROUND ***

this seems to work, at least in the most simple scenarios:

replace
  // set:
  somenode.foo='bar';
  // get:
  var foo=somenode.foo;

with
  // set:
  somenode.setAttribute('data-foo', 'var'); 
  // get:
  var foo=somenode.getAttribute('data-foo');


I have verified that even when the expando properties are cleared, custom attributes set this way are not.

Of course this is a shitty workaround that is impossible to apply to one's entire code base in most cases, but if you are lucky enough that uses of expando properties are limited and easy to spot in your code, this might be a way to prevent your business from burning down while you wait for Google to fix this.

I have been experiencing this issue as well on Windows, Chrome 57.0.2987.133. It appears randomly and it's almost as if the DOM is being reset after I've set my expando properties. I just updated to 58.0.3029.81 - I'll report back if I still have the problem.

For folks that can repro this regularly, can you try this on Beta or Canary channels to see if it still reproduces there?

Tested this issue on Ubuntu 14.04 using chrome reported version stable # 57.0.2987.133 & Chrome latest stable # 58.0.3029.81 and couldn't reproduce the issue. Followed the below steps:

1.Opened chrome and navigated to http://output.jsbin.com/cobedak
2.Clicked on checkbox and observed the alert "foo" 

teo8976@ Could you please try to upgrade to latest stable 58.0.3029.81 and update the thread if issue still exists.

We are not able to reproduce the problem in our private app with the latest stable version 58.0.3029.81. 

teo8976@, can you test with the latest version?

This is almost certainly Issue 701601,  Issue 702490 , etc.

The reason the workaround in Comment 9 works is because attributes are stored in a separate heap to JavaScript objects, so when the original JavaScript object is collected the expandos disappear but the attributes survive.

You might also be able to keep the JavaScript wrapper alive by storing a reference to it in a global array. This will cause you to leak memory, though, so it is not a great solution either.

This should be fixed in Chrome 58. If you see it reproduce there please let us know ASAP.

This very much looks like the issues in #15. These are 'Fixed' and 'WontFix' at the same time, sorry.

The bugfix for this issue is long merged into the M57 branch, but M57 won't roll anymore as M58 is soon stable.

If you see this happen starting from M58, please reopen or open a new issue.

As issue is in fixed state , removing needs-feedback label for now. 

Thanks!