Bug 81829 - Viewport calculations for .uno:PageUp .uno:PageDown scroll movements are not accurate (comment 28)
Summary: Viewport calculations for .uno:PageUp .uno:PageDown scroll movements are not ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 141249 141666 (view as bug list)
Depends on:
Blocks: Scrolling-PageUpDown
  Show dependency treegraph
 
Reported: 2014-07-28 06:07 UTC by Warren Mars
Modified: 2021-04-25 19:37 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Bad alignment in "Entire Page" mode (224.21 KB, image/png)
2014-07-30 00:33 UTC, Warren Mars
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Warren Mars 2014-07-28 06:07:40 UTC
Problem description: It is not possible to use Writer to read a long document properly because it does not align pages properly when page down pressed.

Steps to reproduce:
1. Open a large document in Writer under Windows 7.
2. Select "Entire Page" from View/Zoom
3. Press page down.

Current behavior: Page down will align the document so that the interpage break is roughly in the middle of the viewing area. The top of the area will show the end of the previous page and the bottom of the area will show the start of the current page. Continued pressing of page down will continue to align the page break in the approximate centre of the viewing area.

Expected behavior: Page down should align the document so that the top of the page is at the top of the viewing area and only that page should be visible. Continued pressing of page down should display each successive page taking up the entire viewing area.

Further information: This is the same bug that was listed earlier as FDO#65885 and wrongly closed by James a year ago with WORKSFORME when he used LO 4.1.0.1 on OS X 10.8.4.

This is a Windows Bug and should not be closed by an Apple user.

              
Operating System: Windows 7
Version: 4.2.5.2 release
Comment 1 tommy27 2014-07-28 10:32:16 UTC
hi Warren,

James said:

> Setting to WORKSFORME.
> 
> If this problem persists with the latest release, please re-open this bug.


so my suggestion is to close this bug as a duplicate of Bug 65885 and reopen that one as well.

was it you that opened the original report or another user?
Comment 2 Warren Mars 2014-07-28 22:29:33 UTC
I think it best to use this thread and leave the other closed for now.
The other was opened by mangled_us@yahoo.com, not by me.

Now if someone is interested in fixing this bug that would be great!
Comment 3 tommy27 2014-07-29 05:37:34 UTC
@Warren
ok. post a screenshot showing exactly the page down issue.

@mangled_us@yahoo.com
I put you on CC list. are you still reproducing this issue?
Comment 4 Warren Mars 2014-07-30 00:33:46 UTC
Created attachment 103661 [details]
Bad alignment in "Entire Page" mode

Here is the symptom. If you want any more screen shots just ask.
Comment 5 tommy27 2014-07-30 05:00:34 UTC
I confirm issue under Win7x64 using 4.2.5.2, 4.0.6.2 and 4.4.0.0.alpha0+
Build ID: 9f803ee4b64e11e481ae9bf92ffac7cbf568675a
TinderBox: Win-x86@42, Branch:master, Time: 2014-07-28_06:27:11

same issue in AOO 4.1. hence bug is inherited from OOo
Comment 6 Owen Genat (retired) 2014-08-01 00:45:00 UTC
Also confirmed under GNU/Linux for v3.5.7.2 through v4.3.0.3. Platform set to All/All. Summary edited to remove Windows reference.
Comment 7 QA Administrators 2015-09-04 02:48:16 UTC Comment hidden (obsolete)
Comment 8 Warren Mars 2015-09-10 04:13:20 UTC
Bug remains. This doesn't surprise me as it is clear that no one much is doing any work on this project. I'm giving up on LibreOffice and looking for something that works properly.

Libre Office v5.0.1.2
Windows 7
Comment 9 tommy27 2015-09-10 07:41:31 UTC Comment hidden (off-topic)
Comment 10 QA Administrators 2016-09-20 10:29:24 UTC Comment hidden (obsolete)
Comment 11 Warren Mars 2016-09-20 23:57:54 UTC Comment hidden (off-topic)
Comment 12 Heiko Tietze 2016-10-11 14:06:14 UTC
You are looking for a different function. Page up/down was never meant to scroll to a particular position. 

You may either use the Navigator (F5) with its 'previous/next page' buttons, or you assign shortcuts to the function "to beginning of next/previous page" (tools > customize: category Navigate), where you may also choose Page up/down. (See also bug 101211.)

WORKSFORME, but feel free to reopen again.
Comment 13 Warren Mars 2016-10-11 22:42:32 UTC
I think we can do without pests like you Heiko, coming along and removing bugs with a simple "works for me". It doesn't work, it IS a bug, and kindly mind your own business next time.
Comment 14 tommy27 2016-10-12 04:01:17 UTC
@Warren
Heiko was polite. He expressed his opinion about the bug. right or wrong? I don't care... he even told that you were free to reopen if you did not agree.

so your reaction seems completely out of place and offensive.
this attitude is 10% wrong and not tolerated here.

think about it.
Comment 15 jani 2016-10-12 08:04:29 UTC
May I please ask to keep the tone polite. Heiko has the right (like everybody else) to have an opinion, which he expressed rather politely.

Furthermore (which you Warren) might not be aware of, Heiko has UI as his prime responsibility in his work for TDF. 

We both close/change bugs everyday as part of our job, if you disagree with Heiko and sees this a bug, then contact the UI team, who have the final say about how the UI works (Heiko is part of that team).
Comment 16 tommy27 2016-10-12 08:16:38 UTC
(In reply to tommy27 from comment #14)
> @Warren
> ...
>
> this attitude is 10% wrong and not tolerated here.
> 
> ...

I meant 100% wrong and also comment 11 was unrespectful and offensive towards the LibO project.
Comment 17 Warren Mars 2016-10-12 10:34:03 UTC Comment hidden (abusive)
Comment 18 tommy27 2016-10-12 11:11:18 UTC Comment hidden (off-topic)
Comment 19 V Stuart Foote 2021-03-25 16:39:27 UTC
*** Bug 141249 has been marked as a duplicate of this bug. ***
Comment 20 P Cunningham 2021-03-25 23:33:48 UTC
V Suart Foote marked my report 141249 as a duplicate of this, which, although it is related, it is not.

He said "Specific scope of the movement is os/DE dependent, and current zoom level of document canvas.

And as with dupe, this remains => WF and would waste dev effort for "taming" the variability by os."

First, the exact same behaviour occurs on a Macbook Pro running Mojave 10.14.6 (18G8022), so this is NOT OS dependent, it is inherent in LO Writer. It is a LO bug which should at least be investigated. If it is not reasonably possible to put it right that is a different matter, but this issue can be found referred to many times across the internet (though often poorly described). This is behaviour which a reasonable user should not expect to experience, and is not found in other comparable pieces of software, which behave as expected.

Second, making the software behave in the way which experienced IT users reasonably expect is not, and cannot be, a waste of 'dev effort'.

But I appreciate the huge amount of resources which have been invested over many years by many IT professionals in developing LO and its predecessors and constituent parts - thank you to all of you.
Comment 21 V Stuart Foote 2021-03-26 00:35:35 UTC
There is a distinction to be made between "scrolling" actions of PgDn/PgUp and the full page cursor focus movements implemented for bug 105776

PgDn/PgUp will reposition the document canvas view port based on os/DE configuration, similar to the single line scroll movments of the Down/Up cursors.

There is no need to touch that as for bug 105776 (and dupes) we've provided functional full page focus movements without disrupting the PgDn/PgUp scroll controls which vary widely depending on os/DE, and which correcting by LO is of questionable utility.
Comment 22 P Cunningham 2021-03-26 09:31:20 UTC
Forgive me, Mr Foote, but you seem to have closed your mind to the possibility of this being a bug and are therefore refusing to engage properly with the problem.

The solutions you have offered are mere workarounds. A workaround is a temporary measure for achieving a necessary or desired function which is not available in the software, which can be used, though not fully satisfactory, until the useability issue is addressed in the programming. It is not a solution to the problem in itself.

And in this case, the workaround you suggest does not even address my issue.

The resolution I am working at does not display a whole page of text; I can see about half a page on the screen. Therefore, moving to the top of the next document page does nothing to help - I need to go to the next section of the page, which begins on the next line below the one currently displayed on the screen.

In other word processing programmes I can do this easily. I press pg-dn and my view of the page moves so that the line which is currently the last line on the screen becomes the first or second line, enabling me to read on, uninterrupted by the need find my place.

You have again repeated a clearly inaccurate statement; you say "the PgDn/PgUp scroll controls which vary widely depending on os/DE,"

I explained that I can reproduce the issue on both Windows 10 and Mac Mojave; another post on this thread states that the issue on which this thread is based - which is different but obviously has its roots in the same bug - can be reproduced in Linux too! Your thesis that this is an OS issue is therefore unfounded.

You state "correcting by LO is of questionable utility". I disagree. For me and for many others this is a fundamental useability issue which should be addressed.

While I am pretty computer literate (my first job in computing was in 1967, programming an IBM 1130 in Fortran using punched cards - look it up!) I have not followed a career in IT. I am therefore not familiar with modern coding, but identifying why this renegade behaviour occurs should be fairly straightforward, requiring just a few step-by-step executions of the relevant piece of code. I would be grateful if you would either acknowledge that this needs to be addressed, or direct me to some contact point where I can take it further.

Please understand that I do appreciate what you do!
Comment 23 mangled_us 2021-03-26 20:14:20 UTC
(In reply to tommy27 from comment #3)
> @Warren
> ok. post a screenshot showing exactly the page down issue.
> 
> @mangled_us@yahoo.com
> I put you on CC list. are you still reproducing this issue?

Hi Warren,

Thanks for troubling to CC me with this.  Yes, I still see the issue on LO Writer V7.1.0.3.

It is particularly irritating that when a document is opened in single page mode the first page is initially paginated to occupy one screen space but then paging down moves the page upwards by about 1/3rd of a page and then further presses of <page down> *do* succeed in moving the pages down by 1 whole page worth so after the first miss-location Writer seems to remain perfectly in sync but 1/3 of a page out :-)

It's definitely a bug.

I am coming to the conclusion wrt open source programs like this and eg FireFox that when a program develops to the point that it is a threat to commercial interests it seems to be the case that specifically the bug-reporting and user-facing elements of the project become increasingly hostile to the description of bugs *as* bugs and very trigger happy about closing them with seemingly *any* behaviour accepted as "intended".  Anyone else see this ?

Certainly anyone using the hand-wringing association that FF laughingly calls "support" pages  these days must feel that John Cale's live act from 1979 plays a part ;-)

Boo
Comment 24 mangled_us 2021-03-26 20:27:51 UTC
Apologies, I see it was tommy27 who CC'd me, not Warren.

Boo
Comment 25 mangled_us 2021-03-26 21:01:10 UTC
(In reply to mangled_us from comment #23)
> Thanks for troubling to CC me with this.  Yes, I still see the issue on LO
> Writer V7.1.0.3.
...

Just checked on V7.1.1.2 and the issue still occurs there too, but I guess we all knew that in advance...

Boo
Comment 26 V Stuart Foote 2021-03-26 23:01:18 UTC
(In reply to mangled_us from comment #25)
> (In reply to mangled_us from comment #23)
> > Thanks for troubling to CC me with this.  Yes, I still see the issue on LO
> > Writer V7.1.0.3.
> ...
> 
> Just checked on V7.1.1.2 and the issue still occurs there too, but I guess
> we all knew that in advance...
> 
> Boo

And again, the pgDn/pgUp controls will *never* page at full screen increments--they adapt at the current canvas zoom to move the view port an os/DE managed amount. There may be dev effort to adjust those movements for more consistency cross platform--but probably not and it will remains => WF.

Otherwise, full page movements were implemented for bug 105776 with full page movements via <Alt>+<pgDn> or <Alt>+<pgUp>, while adding <Shift> will do it with selection.
Comment 27 P Cunningham 2021-03-27 09:58:58 UTC
And again, Mr Foote, there IS consistency cross-platform - the programme behaves consistently in exactly the same unacceptable way, on Windows, on OS X and on Linux. This is not a bug that can be shuffled off to the OS, it is within LibreOffice.

It behaves in an unacceptable, illogical manner which is not what a reasonable user should expect and is in line with neither reasonable user expectations nor programming best practice.

pg-dn and pg-up keys, as you put it, *always* page at full screen increments (with a 2 or 3 line overlap) on *all other* word processors. Therefore I deduce that it is *possible* for the same behaviour to be achieved in LibreOffice.

Good software is developed to maximise user satisfaction, not to pander to the preconceptions of coders (or programmers, as I prefer). The programmer's job is to find ways to fulfil legitimate user expectations. This is an entirely reasonable and legitimate user expectation which deserves to be explored. If other software development teams can achieve the proper functioning of these keys, then so can the LibreOffice team. But if they are blocked by a random decision not to proceed with a sensible and desirable improvement in the user experience, that will result in a further loss of credibility and users for LibreOffice.

Please do not stand in the way of progress.
Comment 28 V Stuart Foote 2021-03-27 21:38:02 UTC
@UX-advise, question of reopening to normalize the editshell calculation of  "view port" Y-height for consistent canvas movements down or up in document with the PgDn and PgUP (.uno:PageDown / .uno:PageUp) controls.

I think they're here [1] if I'm reading the editshell right.

=-ref-=
[1] https://opengrok.libreoffice.org/xref/core/editeng/source/editeng/impedit2.cxx?r=dc37866f&mo=53745&fi=1411#1398
Comment 29 Jim Raykowski 2021-03-27 23:55:17 UTC
(In reply to V Stuart Foote from comment #28)
> @UX-advise, question of reopening to normalize the editshell calculation of 
> "view port" Y-height for consistent canvas movements down or up in document
> with the PgDn and PgUP (.uno:PageDown / .uno:PageUp) controls.
> 
> I think they're here [1] if I'm reading the editshell right.
> 
> =-ref-=
> [1]
> https://opengrok.libreoffice.org/xref/core/editeng/source/editeng/impedit2.
> cxx?r=dc37866f&mo=53745&fi=1411#1398

I would say here is a good place to start looking how the .uno:PageDown and .uno:PageUp commands do what they do in the edit view:
https://opengrok.libreoffice.org/xref/core/sw/source/uibase/uiview/view2.cxx?r=5262a9e8#569
Comment 30 Heiko Tietze 2021-04-06 08:47:31 UTC Comment hidden (off-topic)
Comment 31 P Cunningham 2021-04-06 15:20:37 UTC Comment hidden (off-topic)
Comment 32 V Stuart Foote 2021-04-13 13:26:57 UTC
*** Bug 141666 has been marked as a duplicate of this bug. ***
Comment 33 Telesto 2021-04-13 19:46:31 UTC Comment hidden (obsolete)
Comment 34 Telesto 2021-04-13 19:48:28 UTC Comment hidden (obsolete)
Comment 35 Heiko Tietze 2021-04-15 07:18:31 UTC
We shouldn't mess with OS/DE settings but no objection from UX POV to make pg dn/up scroll exactly the whole page when zoom is at entire page level.
Comment 36 P Cunningham 2021-04-15 15:26:12 UTC
(In reply to Heiko Tietze from comment #35)
> We shouldn't mess with OS/DE settings but no objection from UX POV to make
> pg dn/up scroll exactly the whole page when zoom is at entire page level.

This would only help a very few of the people suffering from this issue.

Again you talk about 'messing with the OS/DE settings', but the bug (and it *is* a bug) is OS independent.

It should be possible - actually, it needs to be easy - to move the user's view down through a document at any zoom level, so that the user experience is that (s)he is able to read the whole document without having to think about the process of moving to the next area of text. The pg-dn key is the simplest and most obvious way to do this, and in other word processors it works exactly as expected. Why can this not be reproduced in LO? It is *fundamental* to the user experience.
Comment 37 V Stuart Foote 2021-04-15 16:49:15 UTC
No the reason for reopening this is only to review the calculation of the viewport(s) and why repositioning of the view port is not consistent--either when positioned at the top of the document canvas and first use of .uno:pageDown, or with subsequent scrolling movements up or down with the UNO controls.

The viewport height and width is static as set by the current zoom scale of the VCL canvas. And movements of the viewport with UNO controls linked to pgUp or pgDn buttons should be in consistent amounts relative to the zoom scale.

Ideally the movement range would consistently reposition the viewport some fixed percentage of the VCL canvas and the zoom scale--and I thought that was being calculated at 9/10's in the edit shell at:
 https://opengrok.libreoffice.org/xref/core/editeng/source/editeng/impedit2.cxx?r=dc37866f&mo=53745&fi=1411#1398

and that the viewport not moving in that increment needs attention.

The new (for bug 105776) <Alt>+<pgDn>/<pgUp> UNO controls ( .uno:GoToStartOfNextPage / .uno:GoToStartOfPrevPage ) do not work against the viewport, they are movements against the document structure.  They inherently work in full page increments at any zoom scale. And they were long overdue.

But here we need to figure out why the viewport scrolling  movements are not well constrained--there could be differences by os/DE, but seems like it should be consistent.  Viewport scrolling should depend just on the VCL zoom scale, the current view port Y-height and X-width, and what ever advance percentage is used to calculate the top left and bottom right of the current viewport--and then the values for the following. Consistent either scrolling up or down.

IIUC the Smooth scroll function in Writer comes into play about here as well.