New Sync-Scroll out-of-sync case.

[antoniopaolini]

Hello,
I have a note that go crazy with the new Sync-Scroll.

It is a table, a very long table (but I made also a textbench file for debug), with some empty row at the end (I use to add empty lines at the end and populate it when necessary).

It happens with Joplin 2.6.2 (prod, win32).
With the old 2.5.12 the behavior was "normal", but with 2.6.2 this note is TOTALLY out of sync; I should scroll all the viewer pane before the editor moves.

Environment

Joplin version: Joplin 2.6.2 (prod, win32) Revisione: 5a82f5d - Portable package
Platform: Windows
OS specifics: Windows 10 Pro 1903

Steps to reproduce

1. Import and open the note "file_per_bug_sync-scroll.md" attached
   

2. Add some lines like in the pictrure (I copy and paste the selected lines)
   

3. Scroll the editor pane and the viewer pane

The effect is much more evident with the second file, "Diario - 2021 (working copy).md"; if you scroll a little in the editor pane
the preview pane scroll to the end, and the table is very long!

Diario - 2021 (working copy).md
file_per_bug_sync-scroll.md

[CalebJohn]

Looks like the issue stems from the use of MultiMarkdown Tables if you turn off that feature then the sync scrolling works fine.

edit: Correction, this is due to the way list mappings are handled, typically lists are not allowed inside tables, so having multimarkdown tables makes list handling more complicated.

edit2: There is also a secondary issue with the sync scrolling. Html blocks don't get the source lines attached properly because markdown-it doesn't wrap them with anything. I'm going to create a separate ticket to track that.

We'll probably need to update the source_map script to be aware of MultiMarkdown Tables to fix this bug.

[antoniopaolini]

Great!
I hope this issue could be fixed easily.

[ken1kob]

In addition, there is another cause. Markdown-it-multimd-table has a problem that incorrect line numbers (map[]) are assigned for nested blocks if multiline option is enabled. See <li> elements in the below. Their source-lines should start from more than 2, but they start from 0.

"<div id="rendered-md"><p class="maps-to-line" source-line="0">Scendi giu [^Promemo]</p>
<table class="maps-to-line" source-line="2">
<tbody>
<tr>
<td colspan="2"><span class="week jop-noMdConv">   ### WEEK 42 ### </span></td>
</tr>
<tr>
<td>
<p class="maps-to-line" source-line="0"><strong>18/10/2021</strong>
<code class="inline-code">out:19:30</code></p>
</td>
<td>
<ul>
<li class="maps-to-line" source-line="0">Riorganizzazione mail e vecchie attivita <code class="inline-code">1.5h</code></li>
<li class="maps-to-line" source-line="1">Gestione NC <code class="inline-code">1h</code></li>
<li class="maps-to-line" source-line="2">Supporto produzione <code class="inline-code">2.5h</code></li>
<li class="maps-to-line" source-line="3">Analisi problema produzione, etc <code class="inline-code">1h</code></li>
<li class="maps-to-line" source-line="4">Scheda CANOPEN (Librerie) <code class="inline-code">3h</code></li>
<li class="maps-to-line" source-line="5">Riunione allineamento DT <code class="inline-code">1h</code></li>
</ul>
</td>
</tr>
<tr>
<td>

[CalebJohn]

@ken1kob

I've made a PR to the upstream to fix that portion of the bug.
There's also this bug that I can't figure out how to fix.

[ken1kob]

I've made a PR to the upstream to fix that portion of the bug.

Good job, @CalebJohn.

BTW, since we cannot tell when the upstream is fixed, we have to take a workaround. But, currently, I cannot think of an easy fix...

[CalebJohn]

BTW, since we cannot tell when the upstream is fixed, we have to take a workaround. But, currently, I cannot think of an easy fix...

I think we can apply a patch to that library for now. I know Laurent used to do that for some other packages, but it seems like that's not the case anymore.

[ken1kob]

I think we can apply a patch to that library for now.

It sounds nice to me. It could keep our code clean.

[github-actions]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.

[CalebJohn]

Not stale (almost fixed).

[antoniopaolini]

Hello,
I am not happy to bring bad news, but this bug is still not fixed.
The two files in the initial message still show the same "jumping" problem.

I tried today with:

Joplin 2.7.8 (prod, win32)

ID del Client: 6c64c797f00b410c98d19c8697f4355e
Sinc. versione: 3
Profilo versione: 41
Portachiavi supportato: No

Revisione: 2238ef5

[CalebJohn]

Thanks for letting us know @antoniopaolini, this bug was with the multi-md table package that Joplin uses. I applied a "patch", but it looks like it was lost during the release process. Fortunately the upstream developer has released a new version based on my changes, so we can remove the "patch" and just update it.

[antoniopaolini]

I just downloaded the new 2.7.12.
It works like a charm! Yeah! 👍

I tried with all my "problematics" notes and everthing is ok.

Thanks!

[antoniopaolini]

Also strange notes, with an heavy use of CSS grid works fine, the sync is perfect!
GREAT WORK!!!