Bad bug in /post editor (needs help tracing/reproducing)

[ebarry]

The problem

While entering text into publiclab.org/post, two issues happen:

1. when clicking into EITHER the title box OR the tag box, the cursor "jumps" /relocates itself to the the top left of the body text box
2. the Publish button is not operable

posting.bug.mov

What did you expect to see that you didn't?

1. I expected to be able to type a title, and type tags, without having the cursor move to another part of the editor.
2. I expected to be able to click "Publish"

Please show us where to look

https://publiclab.org/post

What's your PublicLab.org username?

• purl
• amocorro

Browser, version, and operating system

Chrome (yes i see in the video that Purl's browser needs updating, it is now updated).

[sahilsaha7773]

Hello! I tried to reproduce this bug on Chromium 89.0.4389.82, but couldn't do so, for me the publish button is operable and the cursor didn't jump when I clicked on the title or tag box. Could you please confirm if I am checking it wrong?

plcheck.mp4

[cesswairimu]

Thanks so much @sahilsaha7773 , I am not able to replicate it either
@ebarry did the issue persists after the browser was updated.. if not, is it possible to get the chrome version Purl was using before? thanks

[jywarren]

Hi, this seems to be a variant of a bug we couldn't reproduce a few weeks ago, reported by @steviepubliclab and seconded by @RuthNjeri - however none of us were able to reproduce it even on a real-time walkthrough. That makes this pretty tough, but I have a hunch that there's some text in the body text area that is related.

So my guess is (and let's try to refine this so we can reproduce it) --

1. some specific segment of text in the main body is triggering this behavior
2. it likely happens only in rich text mode?

@ebarry if you can send us an exact copy of the text you were using there in https://gist.github.com, and/or a link to the published page that resulted on PublicLab.org (so we can use the text from there as a test string) we can try to reproduce that again. Thanks for working with us on trying to reproduce this bug and fix it!

[jywarren]

(i relayed this to more PL staff as well!)

[jywarren]

Noting @RuthNjeri's notes on this were:

(can’t enter tags in rich text editor, get scrolled back up) – i was just able to replicate the bug - i think the difference was, I used mark down, then also used the button to add a link, then tried to add tags

[jywarren]

OK excellent! Purl was able to share a text that caused this: https://gist.github.com/jywarren/6e62b472b94a1bd83cc5a7653b9b70ed

Let's test this out and see.

Hmm, that didn't trigger it for me.

Aha, though! I see that @ebarry's video shows some links. So i followed what @RuthNjeri said and tried making a link, then clicking the title. This reproduced the bug:

Note that it seemed to happen only when the cursor in the rich text area was placed /after/ the link, and not when it was placed before.

Gosh, now what is causing this??? We'll have to watch the javascript console, but... is some new code in the editor causing the textarea to be focused???

[jywarren]

I think it's plausible it's linked to this new code:

PublicLab.Editor/src/modules/PublicLab.CustomInsert.js

Lines 43 to 65 in cf1fc4a

	$.fn.extend({
	insertAtCaret: function(myValue) {
	return this.each(function(i) {
	if (document.selection) {
	// For browsers like Internet Explorer
	this.focus();
	var sel = document.selection.createRange();
	sel.text = myValue;
	this.focus();
	} else if (this.selectionStart || this.selectionStart == '0') {
	// For browsers like Firefox and Webkit based
	var startPos = this.selectionStart;
	var endPos = this.selectionEnd;
	var scrollTop = this.scrollTop;
	this.value = this.value.substring(0, startPos)+myValue+this.value.substring(endPos, this.value.length);
	this.focus();
	this.selectionStart = startPos + myValue.length;
	this.selectionEnd = startPos + myValue.length;
	this.scrollTop = scrollTop;
	} else {
	this.value += myValue;
	this.focus();
	}

in the Custom Insert code. That has several .focus() calls.

[jywarren]

Moving this to the Editor repo and testing there in GitPod.

[jywarren]

Noting that i can reproduce it in the example demo here. But adding console.log statements after the focus() calls i found above don't trigger, so it may not be those...

[jywarren]

Gosh, i can't find any thing super obvious that would have been causing this. the .focus() lines seem not right, because running .focus() on the rich text area manually doesn't insert the cursor there. I wonder if it was a change to upstream woofmark link parsing that causes this.

Fundamentally it looks like an event was handled too broadly -- i.e. clicking on /anything/ on the page after making a link causes the cursor to be moved to the rich text area. Let's see if Woofmark changes could have caused this:

https://github.com/jywarren/woofmark

YES - was able to reproduce this by booting that up in GitPod. Chasing it further down now....

[jywarren]

OK, i believe it was this section:

https://github.com/jywarren/woofmark/blame/plots2/src/prompts/prompt.js#L70-L76

Trying to disable it.

[jywarren]

Traced it to jywarren/woofmark#3 -- let's revert, and debug another way!

[jywarren]

It was orig a fix for #407

[jywarren]

Also noting that wasn't a major issue - the table insertion popover wasn't closing except when you manually close it. So i think we are OK to just revert!

[jywarren]

Publishing as v3.0.2, i hope!

[jywarren]

Published, this will resolve once the new code is pulled into plots2

[jywarren]

https://www.npmjs.com/package/publiclab-editor

[jywarren]

Solved in publiclab/plots2#9323