UserAgent: Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36

Steps to reproduce the problem:
In Chrome 57 or before:-
1. If we hide a content editable div that had a text range selected, 
2. and then access window’s selection object, it returns the range in the hidden contenteditable div (get via window.getSelection().getRangeAt(0))
3. Hence, the selection object is same before and after hiding the contenteditable div

However, in Chrome 58:- 
1. If we hide a contenteditable div that had a text range selected, 
2. and then access window’s selection object, it returns a different range which falls to that content editable div's parent. (get via window.getSelection().getRangeAt(0))
3. Hence, the selection object is different before and after hiding the content editable div

But in Chrome 58, there is an unexpected fix/bug:-
If we access window's selection range (via- var xyz 
 = window.getSelection().getRangeAt(0)) before hiding the content editable div then selection object is same before and after hiding the contenteditable div, which is same as Chrome 57. This is unexpected as a get call is behaving like a set call and changing its behavior.
---------------
jsfiddle to validate
https://jsfiddle.net/zLoLfkpy/41/

What is the expected behavior?
The selection range (get via window.getSelection().getRangeAt(0)) should be same before and after hiding the content editable div, else it may create regression in our existing code.

What went wrong?
If we hide content editable div (in which some text is selected) then window's selection range does not remain in the content editable div in Chrome 58.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 58.0.3029.110  Channel: stable
OS Version: 10.0
Flash Version: