LO Version: 6.1.0.3 (x64) Build ID: efb621ed25068d70781dc026f7e9c5187a4decd1 CPU threads: 8; OS: Windows 10.0; UI render: default; Locale: en-US (en_US); Calc: CL HW: HP laptop, Xeon CPU, multiple displays, Intel P630 graphics built-in + Nvidia M-series GPU, all current patches. To reproduce: (A) Navigation Pane (NP) showing, headings filter set to show headings. (B) An open Writer doc that has a sufficient number of headings *and* NP header_levels_to_display parameter is set high enough *and* enough headings are expanded such that the header navigation tree, when partially or fully expanded, requires more vertical display than available in the NP and thus a vertical scroll bar appears in the pane. For diagnostic assurance, arrange for the vertical space required to be at least twice the NP vertical display space. (C) Select any heading navigation item, which highlights by font inversion, such that the selected item can be manually scrolled vertically out of view. (D) Before vertical scroll test, observe if the selected item is flickering at anywhere from ~0.5 to ~2 second intervals. (E) Vertically scroll the selected item out of view then wait. Observed Behavior: (F) The NP display autonomously vertically scrolls the display to bring the selected item back in to view approximately within about the flicker interval observed in (E). (G) No difference in observed behavior between Intel-driven builtin display and external Nvidia-driven displays. Expected Behavior: + If the user manually scrolls the NP, there was a reason for that, perhaps to study other parts of the navigation tree, and the scroll action should stick, not jump around on its own. + If the intent is a "return to selection view" action, the user should be able to specify the behavior, such as by button or timeout option. Comments: Not clear if the observed behavior is a feature or a bug. IF a feature, then the usability bug is that a user cannot easily collapse the navigation tree within in the autonomous scroll trigger time. It can take noticeably longer than the flicker interval to: 1) Scroll the NP pane up, then 2) Visually locate a suitable "collapse sub-tree section" target, then 3) Position the mouse point over the target, then 4) Select the target and collapse the sub-tree The UI problem is that before the user can achieve #4 above the NP jumps vertically, usually putting the desired collapse target out of view. The user has to start again. Workarounds: (a) Depending on the local structure of the tree in view, a user may be able to "walk" up the tree using collapse targets also in view when the (C) selected item is in view. (b)If the local structure is such that no collapse targets are in view, the user is has to "walk" the item selection up toward the nearest parent collapse target. (c) Fiddle the NP docking to maximize available vertical display space.
(In reply to R. Bingham from comment #0) > (B) An open Writer doc that has a sufficient number of headings *and* NP > header_levels_to_display parameter is set high enough *and* enough headings > are expanded such that the header navigation tree, when partially or fully > expanded, requires more vertical display than available in the NP and thus a > vertical scroll bar appears in the pane. For diagnostic assurance, arrange > for the vertical space required to be at least twice the NP vertical display > space. Please attach an example document. Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the document.
Created attachment 145437 [details] Bug behavior demo .odt A simple pattern of headings utilizing multiple levels and a identification scheme so each heading is uniquely identified in the navigation pane. The pattern is then iterated to generate enough heading lines to exceed the vertical display space in the navigation pane when fully expanded and control heading_levels_shown is set at a high enough level (level 6 in this demo) such that heading_levels_shown_control_value * heading_count_in_doc_at_that_level > navigation_pane_vertical_display_space If the reported bug behavior is dependent on heading levels used I have not encountered that case yet. Feel free to extend the pattern by copy, paste, edit to get enough heading lines in the navigation pane.
Thanks. I could not reproduce the autonomous scrolling. Version: 6.1.2.1 (x64) Build ID: 65905a128db06ba48db947242809d14d3f9a93fe CPU threads: 4; OS: Windows 10.0; UI render: default; Locale: fi-FI (fi_FI); Calc: group threaded
Additional behavior observation note: 1) Select a navigation pane line item at either vertical extreme in the tree display in the navigation pane. This should highlight the line item. 2) Grab (left click & hold) the NP scroll bar slider. 3) Vertically move the slider until the selected line item is off the pane. 4) Hold (continue left mouse button down), do not release the slider. 5) In a moment, the slider acts as if it has lost mouse focus then re-positions to bring the selected line item back in sight. I should be able to produce a video demo as I have done for prior dynamic behavior bugs I have reported. The question is: is there a point to doing so if others cannot reproduce? Is there an method for capturing some useful log of the UI event loop? R
(In reply to R. Bingham from comment #4) > I should be able to produce a video demo as I have done for prior dynamic > behavior bugs I have reported. The question is: is there a point to doing so > if others cannot reproduce? Is there an method for capturing some useful > log of the UI event loop? Might be interesting to watch. There is a method to capture stuff, but it requires a debug build, which we are currently lacking for Windows. https://wiki.documentfoundation.org/Development/How_to_debug#Macros_Controlling_Debug_Code https://docs.libreoffice.org/sal/html/sal_log.html If one were to do SAL_LOG=1 libreoffice 2>&1 | tee log.txt it would log everything that can be logged.
Which logging can be further targeted using the SAL areas codes here https://docs.libreoffice.org/sal/html/sal_log_areas.html in the string value constructed and assigned to SAL_LOG. Please think about the most targeted logging filter spec for SAL_LOG IF we had a Windows debug build. In the mean time, it will take a few days to resurrect my screen cap video production tool chain then produce a vid & wrestle with the reducing the vid file size. http://wikisend.com/ still acceptable for the vid file share? R
(In reply to R. Bingham from comment #6) > http://wikisend.com/ still acceptable for the vid file share? Yes, but as the expiration time is short, do consider compressing the video in a way that it fits under 30 MB and can be attached to this report directly.
Updated LO release to: Version: 6.1.2.1 (x64) Build ID: 65905a128db06ba48db947242809d14d3f9a93fe CPU threads: 8; OS: Windows 10.0; UI render: default; Locale: en-US (en_US); Calc: CL and reported dynamic behavior is no longer showing. So, for any future backport work the bisect is between LO 6.1.2.1 and 6.1.0.3. Marking RESOLVED in LO 6.1.2.1.
Now LO Version: 6.1.2.1 (x64) Build ID: 65905a128db06ba48db947242809d14d3f9a93fe CPU threads: 8; OS: Windows 10.0; UI render: default; Locale: en-US (en_US); Calc: CL Closed too soon. Prior behavior re-encountered. Re-opened after extensive tests to find opaque LO Writer behaviors with much more specific steps to reproduce issues. To reproduce: 1) Open the demo document attach to bug. 1a) Expected: The doc should open on the title page with edit cursor at top left of title page and correspondingly NO active selection in the Navigation Pane (NP) if materialized. Set the edit cursor at the top of the title page if not already. 1a) You may use the vertical scroll bar in the main document window by mouse wheel or cursor grab but DO NOT select any main window text or otherwise move the editing cursor as this can cause a selection action (list item highlighted) in the NP. (The doc has some explainatory text under the first heading.) 2) Materialize the NP if not already. 3) Avoiding the selection of any NP list item, expand the NP headings tree sufficiently such that is has several more lines than can be shown in the NP, that is, the vertical scroll bar appears. Test #A - NP line item select ONLY (single-click, not double-click action!) A0) Initialize: In main document window set editing cursor at top of title page. A0a) Expected & Observed: Any NP line item selection should be cleared. A1) In the NP, vertically scroll ONLY (care not to select) to bring heading H.01 in view. A2) Expected & Observed: IF scroll ONLY was done in the NP (no line item selection action), then if in the main document window heading H.01 was not in view the main document window should not have moved to bring heading H.01 in view. A3) Select ONLY (single-click!) the NP line item H.01. A4) Expected: Heading H.01 line item should then be selected (highlighted) in the NP AND if in the main document window heading H.01 was not in view the main document window should *not* have moved to bring heading H.01 in view. A5) Avoiding any change in main window or NP selection state, scroll the NP vertically by mouse wheel or cursor grab to take heading H.01 out of view. A6) Wait momentarily. A7) Expected & Observed: No NP vertical scroll movement, leaving NP line item H.01 out of view in both the NP and main window. Test #B - Main document window cursor set or text select. B0) Initialize: In main document window set editing cursor at top of title page. B0a) Expected & Observed: Any NP line item selection should be cleared. B1) In the main document window, vertically scroll ONLY (care not to cursor select or set) to bring heading H.01 in view. B2) Expected & Observed: IF scroll ONLY was done in the main document window (no edit cursor position set), then if NP line item H.01 was not in sight previously, i.e., at the end of Test A, the NP should *not* have moved to bring heading H.01 in view. B3) By click or text select, set the editing cursor anywhere in main window heading H.01 text. B4) Expected & Observed: Heading H.01 line item should then be selected (highlighted) in the NP AND if NP line item H.01 was not in sight previously, i.e., at the end of Test A, the NP *should have* moved autonomously to bring heading H.01 in view. B5) Avoiding any change in main window or NP selection state, scroll the NP vertically by mouse wheel or cursor grab to take heading H.01 out of view. B6) Wait momentarily. B7) Expected: No NP vertical scroll movement. B8) Observed: Even if the NP scroll bar is held by cursor grab, the NP autonomously vertically scrolls to bring heading H.01 back in view. Test #C - NP line item double-click action C0) Initialize: In main document window set editing cursor at top of title page. C0a) Expected & Observed: Any NP line item selection should be cleared. C1) In the NP, vertically scroll ONLY (care not to select) to bring heading H.01 in view. C2) Expected & Observed: IF scroll ONLY was done in the NP (no line item selection action), then if in the main document window heading H.01 was not in view the main document window should *not* have moved to bring heading H.01 in view. C3) Action Select (double-click!) the NP line item H.01. C4) Expected & Observed: Heading H.01 line item should then be selected (highlighted) in the NP AND if in the main document window heading H.01 was not in view the main document window *should have* moved to bring heading H.01 in view. C5) Avoiding any change in main window or NP selection state, scroll the NP vertically by mouse wheel or cursor grab to take line item H.01 out of view. C6) Wait momentarily. C7) Expected: No NP vertical scroll movement. C8) Observed: Even if the NP scroll bar is held by cursor grab, the NP autonomously vertically scrolls to bring heading H.01 back in view. By suitable adjustment, the above tests may be adapted to show similar behaviors when the target heading item is toward the end of the document or NP line item list tree. The autonomous NP behavior becomes scroll down rather than scroll up. Observed behavior summary: I) Setting of the edit cursor (single-click or multi-character select) in the main document window at a heading displayed as an NP line item creates an NP line item selection AND sets an "always in view" autonomous behavior in the NP for the selected line item. A seeming main window to NP "view bond" is established. II) An NP item Action Select (double-click) triggers main window autonomous scrolling to bring the select NP item in view in the main window AND sets an "always in view" autonomous behavior in the NP for the selected line item. A seeming main window to NP "view bond" is established. III) Conversely, mere selection (single-click) of an NP line item does not trigger main document window autonomous scrolling if the selected NP item is out of view in the main window AND does *not* set an "always in view" autonomous behavior in the NP for the selected line item. IV) When in behavior modes I and II, performing a Select (single-click) on any other NP line item (behavior III) releases any main window bond behavior and terminates any "always in view" behavior. The UI behavior problems here are: 1) The "always in view" autonomous behavior in the NP for the selected line item means, for a long expanded tree NP, the user cannot scroll to and at leisure examine or expand/collapse out of view areas of the NP tree before the NP line item tree scrolls out from under the user. 2) There are now two tree-display behavior modes of the NP and the user's click-stream path to enter, exit or toggle these modes is opaque unless a user has done the above detailed behavior study. If there is a visual NP behavior mode indicator (other than the behavior itself) I have not discovered it, meaning static visual inspection does not indicate the current NP behavior mode. Thus for a user the NP behavior can appear random because of not associating a possibly long ago specific click stream with an NP mode change. Single click and double click act differently between the NP and the main window. https://help.libreoffice.org/Writer/Navigation does not indicate these two behavior modes. 3) Additional burden of yet more hidden mode state the user has to remember or develop a habit of defensive reset (behavior IV) to a known mode. Given https://help.libreoffice.org/Writer/Navigation does not mention these behavior modes, it is not clear if this situation is a bug or an undoc feature. If a feature, then I suggest 1) document it, and 2) some static visual indicator of behavior mode.
(In reply to R. Bingham from comment #9) > B4) Expected & Observed: Heading H.01 line item should then be selected > (highlighted) in the NP AND if NP line item H.01 was not in sight > previously, i.e., at the end of Test A, the NP *should have* moved > autonomously to bring heading H.01 in view. Not observed here. NP does not move its view. I also do not observe any of the line item selection clearings when focusing in the document view. > C5) Avoiding any change in main window or NP selection state, scroll the NP > vertically by mouse wheel or cursor grab to take line item H.01 out of view. > > C6) Wait momentarily. > > C7) Expected: No NP vertical scroll movement. > > C8) Observed: Even if the NP scroll bar is held by cursor grab, the NP > autonomously vertically scrolls to bring heading H.01 back in view. Not observed here. Version: 6.1.2.1 (x64) Build ID: 65905a128db06ba48db947242809d14d3f9a93fe CPU threads: 4; OS: Windows 10.0; UI render: default; Locale: fi-FI (fi_FI); Calc: group threaded Arch Linux 64-bit Version: 6.2.0.0.alpha0+ Build ID: 9a373521d7a328197a4bf9abeb0a981b7acba896 CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; Locale: fi-FI (fi_FI.UTF-8); Calc: threaded Built on 19 October 2018
Will work up a video in a few days. Regards.
"I also do not observe any of the line item selection clearings when focusing in the document view." Yes, IF by intent or just randomly you activate the cursor in any part of the document hierarchically "covered" by a paragraph with a style property of outline HEADER #N where #N is low enough to be an NP-displayed heading level item. The NP has a setting for the highest outline-level #N header style to be displayed. In the demo doc this is set to 6. It happens the in the the demo document I constructed, the only document page/text area NOT covered by an NP-displayed heading level item is the TITLE PAGE. To further show this, open the demo document. Should open with cursor on the title page and if the NP is showing then no NP heading line item selected. Manually insert a page break while on the title page. You now have page preceding any text covered by an outline header style paragraph. You can add any text you want as long as its style does not include an outline level property < 7 and it will not show in the NP. When the cursor is in this text the NP should NOT show any selection highlight. I learned the hard way this is why reproducing this bug/feature behavior is so dependent on replicating the exact click-stream sequence indicated. Clicking anywhere in the document edit window, even outside to the side of the doc WYSIWYG image, activates the edit cursor *somewhere* in the document. Different behaviors occur in the NP depending on *where* in the doc text structure the cursor is active.
Hello Maxim, A new major release of LibreOffice is available since this bug was reported. 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 R. Bingham, 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 R. Bingham, 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