Page down does not work on consecutive very long lines

[webzwo0i]

Create a very long line (it does not need to contain 2000 characters, I used 1854)
Copy that line into a second line and a third line
Go to the beginning of the pad (ctrl+home)

Pressing PageDown does not have any effect.

A pad that has the problem is at https://video.etherpad.com/p/t-E5ftI15ZD7FOc35rGR

The "long" lines are wrapped and it seems that the bug is only present, when the line that follows the line that contains the caret is also very long. https://video.etherpad.com/p/AFNCmX3DxH1SAe-G6dSq shows an example of two long wrapped lines. On my screen the last line I can see is the one that contains a lot of "I see I see I see". I cannot see the line that contains "invisible invisible" etc. Pressing PageDown works. As soon as I add a letter at the end of the second line, it wraps again. Now, when I set the caret to the beginning, PageDown has no effect.

[JohnMcLear]

My query here then is if we still need our page up/down catch logic or if the bug has been caught upstream in contenteditable. Afaik it's a historic bug. Will take a look.

Pageup/down in Etherpad is not a nice experience due to latency.

[JohnMcLear]

Oh boy, no. the pageup/pagedown experience in contentEditable is terrible in both Chrome and Firefox. Clearly something that needs addressing but probably has little drivers.

[JohnMcLear]

longPadIssue4562.zip

Attaching compressed .etherpad which has the issue, exported from video.etherpad.com just so we have in case..

Either way the bug is confirmed and something I can fix. I'm familiar w/ this code. I want to lint fix/refactor ace2_inner first tho so this wont be done in 2020

[JohnMcLear]

this is my next job btw

[JohnMcLear]

Okay so I played around a bit and I have a new concept on expected User behavior.

1. Disregard original rep.
2. Get last line in viewport.
3. Scroll view to one line below that line.

It's important we always disregard rep. This is the flaw Etherpad makes, we use the rep instead of the visible lines.

[webzwo0i]

Nice! rep handling really deserves a "best practice" tutorial with tricks that can be learned by studying plugins. :-) (Or explained in a tutorial as in "Interesting concepts inside ACE")

[JohnMcLear]

The tricky thing is that if the rep of the line is longer than the visible viewport we can't go to that position..

Interestingly getVisibleCharRange never actually worked for anything where the line was longer than the viewport.....

Scroll.prototype.getVisibleCharRange = function (rep) {
  const lineRange = this.getVisibleLineRange(rep); // [0,0] which is correct
  return [rep.lines.offsetOfIndex(lineRange[0]), rep.lines.offsetOfIndex(lineRange[1])]; // is always [0,0] until you can see the last character then it's [0,line.length];
};

what should happen is that only the characters visible to the viewport (irrespective of rep) should be returned. rep in general was just a bad approach to solving the problem by the looks of things, I hope I didn't do it....

I seem to remember Google Docs does this with a shadow Dom the same way that I do ep_cursortrace but that is not the route I want to take here..

[JohnMcLear]

https://www.w3.org/TR/DOM-Level-2-Traversal-Range/ranges.html#Level-2-Range-Comparing
&
https://jsfiddle.net/abrady0/ggr5mu7o/

appear to be useful here. Will investigate further.

[JohnMcLear]

Just an update on this, @webzwo0i is doing the long line X offset logic and I did the rest of the page up/down stuff.