In Base: Table Data View, the first select (click) in a scroll bar shaft usually scrolls one page, as expected. But, subsequent selects in the same shaft scroll many pages. As if the select was done many times. That can take a long time to complete as pages are scrolled one at a time. The page up and page down keyboard buttons work correctly. The up and down arrows on the scroll bar work correctly. Dragging the scroll box works correctly. Selecting one shaft (either up or down), then the other, works. That is, the first select on a shaft seems to scroll a single page. The subsequent selects on that same shaft seem to scroll multiple pages. This has been a problem for many versions. It seems to be less severe in 5.1.1.3 than it was in 5.1.0.3 and prior versions, scrolling fewer pages. But, that's only with a few minutes testing. Problem not observed with any other applications. Only LObase.
Hello, Thank you for filing the bug. Please send us a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO', so please do change it back to 'UNCONFIRMED' once you have attached a document. (Please note that the attachment will be public, remove any sensitive information before attaching it.) How can I eliminate confidential data from a sample document? https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F Thank you
Created attachment 124418 [details] database If document requested is a database, testDB.odb is attached. Open a table in table data view. First select on a scroll bar shaft moves one page in the desired direction. Subsequent select on the same shaft may move multiple pages. Even continuously until the pointer is moved out of the window, when scrolling stops and the view changes back to the next page that should have been shown from a one page scroll. It still does that with version 5.1.2.2 (x64).
LibreOfficeDev_5.2.0.0.alpha1_Win_x64 still has the problem
No problem for me. Arch Linux 64-bit, KDE Plasma 5 Version: 5.2.0.0.alpha1+ Build ID: 540fee2dc7553152914f7f1d8a41921e765087ef CPU Threads: 8; OS Version: Linux 4.5; UI Render: default; Locale: fi-FI (fi_FI.UTF-8) Built on April 30th 2016
I don't seem to be able to reproduce with Version: 5.1.3.2 Build ID: 644e4637d1d8544fd9f56425bd6cec110e49301b CPU Threads: 2; OS Version: Mac OS X 10.11.5; UI Render: default; Locale: fr-FR (fr.UTF-8) but not having an index in the sample tables by which to judge where the jump is made to doesn't help. For me this is WFM
@jodo : My understanding is that by design, in order to have a trade off between performance on the one hand and user experience on the other, LibreOffice Base caches a certain number of results from the result set and then "paints" the cached rows to the window. The cached results held in memory perhaps do not correspond exactly to what you consider to be one page, hence perhaps your perception (real or otherwise) that the results jump more than "one page", i.e. more than the logical display that should be painted within the window. Perhaps a Base dev can comment on what is supposed to happen ? Adding Lionel to CC. Lionel : how is the display supposed to be refreshed when subsequent presses on the up/down arrow of the resultset window are activated ?
(In reply to Alex Thurgood from comment #6) > @jodo : My understanding is that by design, in order to have a trade off > between performance on the one hand and user experience on the other, > LibreOffice Base caches a certain number of results from the result set and > then "paints" the cached rows to the window. The cached results held in > memory perhaps do not correspond exactly to what you consider to be one > page, hence perhaps your perception (real or otherwise) that the results > jump more than "one page", i.e. more than the logical display that should be > painted within the window. The cache story is true (and if I remember well, the cache window is about twice the display window, or 40, whichever is bigger), but that is unrelated to the current bug; it is just a cache and has absolutely no influence on how much the display window is moved when. So if this can be reproduced, it is a real bug.
Created attachment 126852 [details] video of problem At 3 seconds, pointer moved to scroll bar and selected. Window advanced one page, as desired. At 8s, another select. Continuous page advancement started. At 27s, pointer moved to column a and selected once. Page advancement continued to end of recording.
The problem could be windows specific. You video seems to show that repeated clicking on the down arrow causes the commands to be executed with a delay, and that maybe there is a mismatch between the mouse click event and the redraw of the screen thereby giving an impression of incorrect page jumping.
Of course the problem may be Win-specific, or specific to my Win. I am the only one who both suffers from it and reported it. However, LibreOffice is the only program that does this. There was not repeated selection of the down arrow. There was no selection of the down arrow. The mouse clicks were precisely as specified in comment 8. One select in the page down trough. Another at the same spot 5 seconds later. That event caused continuous page down in the window without any more button activity. The mouse is not broken. The button was not stuck. There was only one SB_PAGEDOWN event. The page jumping was not an impression. The video shows that it happened. Incessant page down as if LO kept performing pagedown events.
jod : of course, your video shows the problem, but QA relies on independent confirmation, firstly on the same OS, and also after comparison with other OSes (in case the problem is OS-agnostic). We need a Windows QA member to be able to test the issue on a Windows machine with the LO version you indicate to see if it is reproducible there too. In the meantime, this report will remain unconfirmed.
PageDown scrolls about 90 records at a time. I observed the scrollbar does about the same. I did not observe more with the scrollbar. I did not see it get stuck like in the vid, even though I scrolled to the last record of Table1. Win 7 Pro 64-bit Version: 5.3.0.0.alpha0+ Build ID: 7da2f3ce9f7b049c177a735a146dae84a764d3f7 CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2016-10-04_03:49:06 Locale: fi-FI (fi_FI); Calc: CL
@jodo : can you try with a latest version of LibreOffice and see if the problem is still there for you ? Also, and this is a bit of a shot in the dark, can you tell us whether OpenGL is activated in your LibreOffice preferences ? Seting to NEEDINFO
Alex, The problem is still in 5.3.2.2 (x64). Both with and without Use OpenGL for all rendering. In both cases, it said GL is currently disabled at the bottom of the Graphics Output section of LO View Options.
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping-20171030
questions answered in comment 14
Dear jodo, Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Dear jodo, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear jodo, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp