Created attachment 193451 [details] Demo document to trigger "jumping viewport" Version: 7.6.5.2 (X86_64) / LibreOffice Community Build ID: 38d5f62f85355c192ef5f1dd47c5c0c0c6d6598b CPU threads: 16; OS: Linux 5.10; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded Hi there, this is a funny one: Cursor movement to a different paragraph or character style seems to trigger a viewport alignment to the closest page break iff the zoom level is set to "entire page". To reproduce: * Load attached document * Set View->Zoom->Entire page * Put the cursor on the line that reads "put cursor here" * Scroll down half a page using the mouse wheel. The gap between first and second document page should be in the middle of the screen. * Move the cursor up and down a few lines, using the arrow keys. Do it slowly, say one keystroke per sec. DON'T leave the visible region with the cursor Observation: When you reach the first "preformatted text" paragraph, the viewport scrolls up so that page 1 is visible in full. This happens with a few tenths of a second delay. Expectation: The viewport should stay where it is. As long as the cursor stays within the visible region, there's no reason for unsolicited viewport movement. According to my observations, the exact styles involved don't matter. It also doesn't seem to matter, how the cursor movement is accomplished: I can trigger this with arrow keys, by mouse clicking, or as a side effect of advancing by pages -- I discovered this bug while experimenting with the different next page/previous page UNO functions. Needless to say that this bug will drive you crazy if you're editing in the vicinity of a page break and happen to touch different para/char styles with the cursor. Cheers, Tyler
Oh, just forgot to add: The workaround is to set the zoom factor a few percent points off "entire page". -Tyler
Confirmed, but expected in "Single-page view" mode (next to the zoom-slider on the Status bar). Movement is not responding to the edit cursor positioning, rather to the page view as being moved by the scroll bar. Shift in view port does not happen if you set view mode to "Multi-page view" or to "Book view".
Also, seems a bit less noticeable if "Smooth scroll" is checked enabled from Tools -> Options -> LO Writer -> View which IIRC builds a cache of the per-line scroll of the view ports. @Stragu, a second opinion please?
Hm I understand a jump is expected to have a full view of the page, but the delay is jarring. Try this: - place cursor at bottom of page - press arrow down to go to the next page Results: viewport jumps to next page to show half the page, then updates after the delay to show the whole page. In my opinion, if the Zoom settings means "single entire page that has the cursor is shown", it should do it straight away and not have that delay that makes it a two-step jump. For some reason, I reproduce very inconsistently, I am missing something in the steps to always get the same result. At least, I have see the jump in: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: f2482fd96eff00b806fae385096531f63f5f2bf5 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded But now I can't reproduce in any version. Tyler, any chance you can provide more precise steps? The document doesn't have the line "put cursor here".
Created attachment 193505 [details] Jumping viewport demo
OK, I've built a new test document and checked again with a fresh profile and my real user profile. A) With a fresh profile, I see the effect only when moving between non-table text and tables. When the cursor moves into (or out of) a table, the context-sensitive table toolbar pops up (or vanishes), this causes a size change of the document canvas, which in turn triggers the (delayed) jump of the viewport. If I turn off any context-sensitive toolbars, this doesn't happen. B) With my real profile, I have all toolbars off anyway and see this jump nevertheless. Turns out that the open sidebar (even with all panes closed) is the culprit! So, to summarize: A is explainable and probably expected behavior, given the (IMHO debatable) way the full-page view mode works. But B is a bug I would say: UI elements should trigger canvas resize events only if the size actually changes. Re comments #2, #3: I don't see any dependence on the single/multi/book view. Smooth scroll seems to slow down rendering a bit (noticeable only at unreasonably small zoom, i.e. many pages to render), but otherwise no change. The updated repro instructions are then: * Load attached document * Set View->Zoom->Entire page * Enable the sidebar (View->Sidebar) * Put the cursor on a normal, plain text paragraph in the middle of a page. * Scroll down half a page using the mouse wheel. The gap between pages should be in the middle of the screen. * Move the cursor up (with arrow keys) until you touch the table or down until you touch the paragraph with reddish background.
[Automated Action] NeedInfo-To-Unconfirmed