Material-ui: [Popover] Unexpected scroll jumping on close

[jagthebeetle]

• [x] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

When a popover is closed, a document that is longer than the viewport's height should remain at its current position

Current Behavior

Under certain scenarios, the page will jump to a previously clicked position.

Steps to Reproduce (for bugs)

This can be reproduced on the Popover demo page. I have reproduced this on Windows as well. I have not been able to reproduce it on Firefox / Safari.
On the demo page, in Chrome:

1. Click 'Open Popover' under the section 'Anchor Playground'.
2. Click outside of popover to close it.
3. Scroll down to section 'Mouse over interaction'
4. Hover over 'Hover with Popover.'
5. Mouse out of 'Hover with Popover.'
6. Page will snap up to top of page.

Context

In my app, this error seems to be triggered only if I click on certain elements, scroll the page to a different part of the document and then trigger/close a new popover. I can't determine whether this is related to #8040, but due to the browser-specific nature of this issue, I suspect it isn't.

Your Environment

| Tech | Version |
|--------------|---------|
| Material-UI | 1.0.0-beta.30 |
| React | 16.2.0 |
| browser | Chrome 63.0.3239.132 (extensions disabled) |
| OS | macOS 10.13.2 + Windows 10 (Fall Creators, v1709) |

[oliviertassinari]

I can't determine whether this is related to #8040

@jagthebeetle This issue only affects v0.x. It's not related. The behavior you are describing is expected given how the "Mouse over interaction" demo is configured. We should disable this behavior with the disableRestoreFocus property on the last demo. There is no focus to restore that the popover open was triggered by a mouse over. Do you want to fix our demo? :)

[jagthebeetle]

@oliviertassinari Ah, I was about to announce that Modal.restoreLastFocus seems to be the culprit, but I see this is essentially intended behavior.

Glad to fix the docs :) Is it perhaps worth calling out Modal's disableRestoreFocus property in the Demo or API page? Although it makes sense that in standard use you'd want to restore focus, in my particular case (using it as a pseudo-tooltip within SVG), it didn't occur to me immediately.