https://bugs.documentfoundation.org/show_bug.cgi?id=119862
Bug ID: 119862
Summary: Navigation Pane, sidebar mode, autonomous vertical
jump to current selected heading item
Product: LibreOffice
Version: 6.1.0.3 release
Hardware: x86-64 (AMD64)
OS: Windows (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Writer
Assignee: libreoffice-bugs@lists.freedesktop.org
Reporter: rdbing...@verizon.net
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.
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
