search

brackets-archive / bracketsIssues

Archive of issues in brackets.
0 stars 0 forks source link

Quick Docs content jumps to top when resizing document window #12361

Open core-ai-bot opened 3 years ago

core-ai-bot commented 3 years ago

Issue by dalcala Tuesday Aug 20, 2013 at 00:07 GMT Originally opened as https://github.com/adobe/brackets/issues/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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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