Quick Docs content jumps to top when resizing document window

[dalcala]

Description:
Quick Docs jumps to the top when resizing document window. This also happens with the inline color editor when using the new Kuler feature. See Edge Code bug https://git.corp.adobe.com/edge/edge-code/issues/266

Repro using Brackets Sprint 29 on Win 7 & Mac 10.8.

Repro steps:

1. Open a css file and invoke Quick Docs (Cmd+K) on some code that has a lot of text in Quick Docs. Here is a good example from main.css from Getting Started files:
   body {
   -webkit-box-shadow: 0 0 12px rgba(0, 0, 0, 0.4);
   }
2. Scroll down to the bottom of the content in the Quick Docs box.
3. Make the Brackets window wider or narrower.

Actual results:
Quick Docs content jumps to top when resizing document window.

Expected results:
Quick Docs content stays on the content section you were on when resizing document window.

Workaround:
Scroll back to the content section you were looking at.

[iwehrman]

As noted at the EC issue, I looked into this and failed. No scroll events are being fired, and no JavaScript is explicitly setting the scrollTop property of scroller div's DOM element.

[peterflynn]

It looks like the inline widget's DOM subtree may be getting removed & readded when the CM widget is refreshed. This might be causing Chrome to forget the scroll position. A similar thing happens when you scroll the inline widget too far out of view and then scroll back...

[peterflynn]

Here's a JSFiddle that demonstrates that effect: http://jsfiddle.net/RXdab/

Even an instantaneous, temporary removal from the DOM (click "No op") loses the scroll pos, at least in Chrome...

[iwehrman]

(CC @njx for kicks)

Thanks for helping track this down! Sadly, I am still not smart enough to solve this. My only guess was to watch for DOMNodeInserted events fired on the inline widget (or something similar with Mutation Observers) and use that opportunity to manually set the scrollTop of the scroller div. But these events seem to happen just before the node is actually inserted, and it is apparently not possible to set scrollTop on detatched nodes. If I set the property on the next tick of the event loop then it works but flickers badly while resizing because the widget is removed and inserted tens of times per second during resize. Debouncing didn't seem to help much either. This works fine though in the simple case of switching between documents, which also causes the scroll position to be lost. So, giving up again for now!

[pthiess]

@njx -It would be great if we could have this for the preview 6 release, but we would need this for this Brackets sprint 30 - unrealistic timeframe it seems, right?

[njx]

It doesn't seem likely we could fix this within the next day or two, since (from my cursory read of the issue) I think we'd probably need something in CodeMirror. It's probably hard to avoid having CM remove/add the widget on a refresh, but perhaps we could get Marijn to add an event that's dispatched when the widget node is readded.

[njx]

Hmmm...that wouldn't really help with the flickering issue @iwehrman mentioned though. It's really a bummer that the scroll position is lost when the node is detached. Is it possible that that's a bug in Chrome? Worth seeing what other browsers do.

[iwehrman]

@peterflynn's fiddle exhibits the same behavior in Chrome, Safari and Firefox. I suspect that this is somehow intentional given that you can't set scrollTop on an element that isn't attached to the DOM.

[peterflynn]

@njx I think we'd need events both when the node is removed and when re-added -- to save & restore scroll state, respectively.

Does the widget lose focus too if it had it? That'd be another thing we might want to save/restore using those same events down the road...

[njx]

Marking "F Quick Edit" even though this isn't strictly the same feature, since it's related to the same underlying infrastructure (inline widgets).