Last scrollbar position is not restored when opening a page

[lorenrosen]

(This is slightly different from bug 1622.) When I open a previously viewed page in the same notebook (using, say, the buttons towards the top listing bookmarks and recently viewed pages), the cursor is as it was, but the viewport and scrollbar are at or near the beginning of the page (at least if the page is long enough so it won't all fit in the window, and the cursor isn't near the top of the window).

A simple workaround: move the cursor back-and-forth using the arrow keys (that is, ← then →) when first viewing a page. This has the side effect of moving the viewport so the cursor is visible.

This is on Ubuntu 20.04 -- though I could well believe it's timing-related and sensitive to the details of the whole hardware/software stack.

[charles-esterbrook]

I have this identical issue with the viewport being incorrect when switching pages on Zim 0.74.1 installed on Windows 10. The problem happens whether I select the pages through the Index pane or switch pages with Alt-Left and Alt-Right.

Steps:

1. Select a long page through Index.
2. Scroll down half way through the page content.
3. Place cursor with mouse click.
4. Select a different page through Index.
5. Select the first page again through Index.

The cursor will be restored to its correct location, but the scroll position / viewport will not be correct. In fact, the cursor will be out of sight.

Workaround: Moving it with any of the 4 arrow keys will initiate the scrolling.

[sojusnik]

Related to #92 and #1276

[lorenrosen]

Similarly, when traversing a link to a section of a page, zim places the cursor at the beginning (right before the heading), but places the viewport at the beginning of the page. This may be the origin of bugs reporting section linking doesn't work, e.g. #1617

[jaap-karssenberg]

I believe it is related to loading inline objects which change the scroll position - see _hack_on_inserted_tree() in pageview/__init__.py Can you confirm this happens only on pages with objects (equations / code blocks /...) ? Need investigation how to solve issues with rendering objects :(

…

On Tue, Sep 28, 2021 at 7:52 PM Loren Rosen ***@***.***> wrote: Similarly, when traversing a link to a section of a page, zim places the cursor at the beginning (right before the heading), but places the viewport at the beginning of the page. This may be the origin of bugs reporting section linking doesn't work, e.g. #1617 <#1617> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1624 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJQYHWMXHJE5LJIO34B7ILUEH6E5ANCNFSM5EYKQKEQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[lorenrosen]

I don't paste in code blocks or equations much. But I do paste other kinds of text often. It's in fact not so simple to create a lengthy test page without pasting. I suppose I could type in lots of characters, or hold down a character and let it autorepeat. It does seem to incorrectly position the viewport when the page is pasted text -- though the amount seems to be proportional to how far down the page the viewport should be.One thought for a test case might be to copy a page file using the underlying o/s mechanism (e.g. on Linux use 'cp'). Then maybe reindex? Open the new page, scroll, visit another page, then go back to the new page. Thus one could easily create a lengthy page without using zim pasting. On Wednesday, September 29, 2021, 12:24:10 AM PDT, Jaap Karssenberg ***@***.***> wrote: I believe it is related to loading inline objects which change the scroll position - see _hack_on_inserted_tree() in pageview/__init__.py Can you confirm this happens only on pages with objects (equations / code blocks /...) ? Need investigation how to solve issues with rendering objects :(

On Tue, Sep 28, 2021 at 7:52 PM Loren Rosen ***@***.***> wrote: Similarly, when traversing a link to a section of a page, zim places the cursor at the beginning (right before the heading), but places the viewport at the beginning of the page. This may be the origin of bugs reporting section linking doesn't work, e.g. #1617 <#1617> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1624 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJQYHWMXHJE5LJIO34B7ILUEH6E5ANCNFSM5EYKQKEQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[bruvellu]

This happens for me in a long page containing only a numbered list with links to other pages (~300 items). Source of the first few lines look like this:

Content-Type: text/x-zim-wiki
Wiki-Format: zim 0.6
Creation-Date: 2017-11-14T09:47:08+01:00

====== Notebook ======
Created Tuesday 14 November 2017

1. [[+Order FlyFos btd construct|Order FlyFos btd construct]]
2. [[+Order first Bloomington flies|Order first Bloomington flies]]
3. [[+Imaging knrl and bnb|Imaging knrl and bnb]]
4. [[+First imaging of Gap43|First imaging of Gap43]]
5. [[+SD3 imaging second try with Gap43|Second try with Gap43]]

[introt]

This sounds like a duplicate of #1276. #1871 contains steps to reproduce, seems to happen with long pages w/ lots of images (edit: images aren't required to reproduce)

[vossenjp]

It happens with just long pages, you don't need images, see code to create a page at the top of #1276. I think this might also be related to the garbled text in #727.