Quick Docs content jumps to top when resizing document window

[core-ai-bot]

Issue by dalcala
Tuesday Aug 20, 2013 at 00:07 GMT
Originally opened as adobe/brackets#4830

---

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.

[core-ai-bot]

Comment by iwehrman
Thursday Aug 22, 2013 at 23:25 GMT

---

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.

[core-ai-bot]

Comment by peterflynn
Friday Aug 23, 2013 at 01:10 GMT

---

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...

[core-ai-bot]

Comment by peterflynn
Friday Aug 23, 2013 at 01:16 GMT

---

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...

[core-ai-bot]

Comment by iwehrman
Friday Aug 23, 2013 at 17:14 GMT

---

(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!

[core-ai-bot]

Comment by pthiess
Monday Aug 26, 2013 at 18:35 GMT

---

@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?

[core-ai-bot]

Comment by njx
Monday Aug 26, 2013 at 20:31 GMT

---

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.

[core-ai-bot]

Comment by njx
Monday Aug 26, 2013 at 20:32 GMT

---

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.

[core-ai-bot]

Comment by iwehrman
Wednesday Aug 28, 2013 at 00:11 GMT

---

@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.

[core-ai-bot]

Comment by peterflynn
Wednesday Aug 28, 2013 at 00:21 GMT

---

@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...

[core-ai-bot]

Comment by njx
Saturday Jul 12, 2014 at 03:26 GMT

---

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