Window scroll position jumps wildly when typing into bottom of long body of text

[jywarren]

In Markdown mode, if you go to https://publiclab.github.io/PublicLab.Editor/examples/ and enter a few hundred lines of text -- just paste in a lot -- then type near the bottom, the scroll position starts to jump around, making it very hard to enter text.

I think this may have to do with the calculation of scrollTop on this line:

PublicLab.Editor/src/modules/PublicLab.RichTextModule.js

Line 168 in e74e97e

document.body.scrollTop = _module.scrollTop;

scrollTop also appears on these lines:

https://github.com/publiclab/PublicLab.Editor/search?utf8=%E2%9C%93&q=scroll&type=

Perhaps we're miscalculating, or maybe we shouldn't try to do this at all? We could test this by manually running setting document.body.scrollTop and/or by inserting console.log statements by these probable lines, to check when they're being set and by how much.

This needs some exploration to figure out exactly what's causing this!

[jywarren]

Related upstream but in Woofmark? bevacqua/woofmark#26

[kunal-mohta]

Do you have to resize the the textarea?
If we disable resize, we get this..

..which seems pretty decent.

(My apologies for the poor quality of the gif, you can also view the result in the video present in the zip folder below)
Screencast 2018-01-24 01:28:39.mp4.tar.gz

[jywarren]

I think it's just trying to emulate the behavior of the rich text mode... see how it's different there? But maybe if we're seeing bad behavior here we should just disable it for now and ensure it's "pretty tall" ... what do you think?

[kunal-mohta]

Oh I see..
I think you are right, instead of disabling resize, we could try to fix the automatic scrolling of the page on entering text, right?

[jywarren]

That'd be super. Can you think of a good way forward? Thanks!

[shapironick]

+1ing this issue :) as it makes writing intricate notes frustrating.

[ebarry]

Hi! I'm also experiencing this. Whenever i do a key command like ⌘b to bold some text, or click the B button, the page positions moves to the bottom of the page -- past the text window all the way to the bottom of the footer. @SidharthBansal do you have any ideas on this?

[SidharthBansal]

@ebarry on clicking on the bold button B I did not notice any movement of the page to the bottom of the page. I also tried with the ⌘b that also works well. I am using Ubuntu with Mozilla Firefox. Maybe the problem is with the browser.

[ebarry]

Wow that is great to hear. Can i ask if you tested with several hundred lines of text that caused the entry box to be greatly expanded, like as much as https://publiclab.org/notes/liz/04-24-2018/evaluation-listen4good-round-two-results ?

[SidharthBansal]

I tried with the link provided by you but the behaviour is normal in case of bold button and ⌘b

[ebarry]

wow ok! Time to switch to Ubuntu!!! I will try to better document this for other browsers

[jywarren]

If you can offer a sample text and step-by-step workflow, we can call in other people to try it out and report back!

…

On Tue, Apr 24, 2018 at 5:13 PM, Liz Barry ***@***.***> wrote: wow ok! Time to switch to Ubuntu!!! I will try to better document this for other browsers — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#114 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABfJ2cjuX5_lXoJqL5zPCfSB3h6nvhKks5tr5VvgaJpZM4Qn459> .

[ebarry]

Aha! new information to report:

in Chrome, when editing a large amount of text, and with a cursor position "below the fold" (somewhere lower than what is shown upon first load of the Editor interface) ---> pressing EITHER the shift key OR the command key (⌘ on mac) causes the page to "move" all the way down to the bottom of the footer, past even the lower boundary of the text box.

Use this text file for testing (it's the entire content in markdown for https://publiclab.org/notes/liz/04-24-2018/evaluation-listen4good-round-two-results):
example text.txt

[jywarren]

I think we could try to reproduce this by:

1. console.log()ing this line to see what the scrollTop values are:

   PublicLab.Editor/src/modules/PublicLab.RichTextModule.js

   Line 168 in e74e97e

   document.body.scrollTop = _module.scrollTop;

2. instead of pressing shift or command as Liz says, trying to trigger this by manually entering the same values for scrollTop that are being input by the above command, in the JS console
3. observing if this does indeed incorrectly scroll the editor to a bad place as Liz has documented
4. trying to understand why this bad scrollTop position is given and in what conditions
5. trying to either stop it from triggering a new scrollTop in that moment, or try to get a better value for scrollTop when it does.

[jywarren]

We can also try to just disable changing scrollTop but not disabling the resizing altogether to see if that helps?

[jywarren]

@publiclab/soc if anyone likes JavaScript and is looking for a small side project, this one is pretty frustrating if you've ever written a long post on PublicLab.org! Any help appreciated. 😅

[jywarren]

We also use the npm module grow-textarea to do this, and maybe that's buggy:

PublicLab.Editor/src/modules/PublicLab.RichTextModule.js

Lines 131 to 138 in e74e97e

	var growTextarea = require('grow-textarea');
	// Make textarea match content height
	_module.resize = function() {
	growTextarea(_module.options.textarea, { extra: 10 });
	}

Here are some others we might try:

• https://github.com/ultimatedelman/autogrow
• https://github.com/jevin/Autogrow-Textarea

[jywarren]

I think we have to figure out if the scrollTop line is causing this or the grow-textarea library. We can try commenting out one or the other and testing this now that Liz has provided a long example text to use.

[ebarry]

This is such a funny bug! While editing a long research note, even pressing Shift in order to capitalize a letter causes the rapid window scroll to the bottom. As soon as the second letter is typed, however, the window scrolls up rapidly to the correct cursor insert point in the text box (so rapidly, it is not immediately obvious what caused the flicker). Thanks for reading!

[jywarren]

I disabled grow-textarea on line 136 of src/modules/PublicLab.RichTextModule.js and this behavior stopped. So I think it's worth trying a different textarea growing library.

[jywarren]

Trying https://www.npmjs.com/package/autogrow now

[jywarren]

I've attempted a fix by removing the autogrow feature completely, as suggested by @kunal-mohta. I've commented it out with a note as to why. Tests running...

[jywarren]

Merging and publishing

[ebarry]

oh wow - SO EXCITED!

…

-- +1 336-269-1539 / @lizbarry <http://twitter.com/lizbarry> / lizbarry.net

On Tue, Aug 7, 2018 at 6:42 PM, Jeffrey Warren ***@***.***> wrote: Merging and publishing — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#114 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJ2n64-9GLtFhejfkxK_Hlln6vPZaoMks5uOhfSgaJpZM4Qn459> .