Bug 130004 - Navigator mode can no longer be set from its attached Navigation toolbox dialog--OK with tear-away of the floating toolbox
Summary: Navigator mode can no longer be set from its attached Navigation toolbox dial...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.4.0.2 rc
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectNotNeeded, regression
: 134162 (view as bug list)
Depends on:
Blocks: Navigator
  Show dependency treegraph
 
Reported: 2020-01-14 20:14 UTC by V Stuart Foote
Modified: 2022-11-13 17:39 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Attachments
Navigation popup window (5.43 KB, image/png)
2020-01-15 21:38 UTC, Jim Raykowski
Details
screenshot of Navigation popup and Navigator deck (52.64 KB, image/png)
2020-01-16 00:58 UTC, sdc.blanco
Details

Note You need to log in before you can comment on or make changes to this bug.
Description V Stuart Foote 2020-01-14 20:14:23 UTC
While looking at work on bug 129468, noticed a regression in the SideBar Navigator deck where selecting the 'Reminder' mode (the Paperclip icon) will no take, and the mode reverts to default 'Page' mode.

Behavior was OK through the 2019-11-14 branch off for 6.4.0, but has gone bad by 2019-11-25

From builds on hand, rough range to get a bibisect going.

https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=4d7e5b0c40ed843384704eca3ce21981d4e98920..738a11f20ef5b9bcfcc71cca6b0fbea9d06c438b
Comment 1 V Stuart Foote 2020-01-14 20:26:58 UTC
Kind of interesting, regression slipped in with a backport to 6.4.0.2

Setting the Navigator into 'Reminder' mode works in 6.4.0.1 rc1, but is bad in 6.4.0.2 rc2

Somewhere in here; if it is possible to bibisect against the 6.4.0 branch:

https://cgit.freedesktop.org/libreoffice/core/log/?h=libreoffice-6-4-0&qt=range&q=1b6477b31f0334bd8620a96f0aeeb449b587be9f..08d19fecdc7a2298d051e19cfdb7c35544855fc3
Comment 2 Xisco Faulí 2020-01-14 20:49:18 UTC
Could you please explain how to reproduce this issue?
I'm having problem to reproduce it
Comment 3 V Stuart Foote 2020-01-14 21:24:55 UTC Comment hidden (obsolete)
Comment 4 Jim Raykowski 2020-01-15 06:58:24 UTC
I noticed buggy behavior of the Navigation toolbox popup for all vcl backends a short time ago. Using Windows version the popup box disappears when I click on any of the toolbox entries. 

Repro'd with:

Version: 6.5.0.0.alpha0+ (x64)
Build ID: 148ed6c2739ab8af88c0ac363f30f99f10bf7c1a
CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded
Comment 5 sdc.blanco 2020-01-15 14:58:40 UTC
(In reply to Jim Raykowski from comment #4)
> I noticed buggy behavior of the Navigation toolbox popup for all vcl
> backends a short time ago. 
You mean "Navigator" (F5)?

> Using Windows version the popup box disappears
> when I click on any of the toolbox entries. 
(for example) a bookmark, heading, section, shape, etc.?

Cannot reproduce.  (Able to Navigate to everything, and Navigator window remains open.)

Version: 6.5.0.0.alpha0+ (x64)
Build ID: 035c7717c135c66c0ec025500b73ae9c13b7c586
CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: GL; VCL: win; 
Locale: da-DK (en_DK); UI-Language: en-US
Calc: threaded
Comment 6 V Stuart Foote 2020-01-15 16:19:22 UTC
(In reply to sdc.blanco from comment #5)
> (In reply to Jim Raykowski from comment #4)
> > I noticed buggy behavior of the Navigation toolbox popup for all vcl
> > backends a short time ago. 
> You mean "Navigator" (F5)?

No. The primary Navigator deck instance on the Sidebar. 

> 
> > Using Windows version the popup box disappears
> > when I click on any of the toolbox entries. 
> (for example) a bookmark, heading, section, shape, etc.?
> 
> Cannot reproduce.  (Able to Navigate to everything, and Navigator window
> remains open.)
> 

Seems like the 'Navigate by' setting is now exclusively being picked up from the Find toolbar, and for Navigator its mode can no longer be set from the Navigation dialog of Navigator! Affects both instances of the Navigator (<F5> detached, or the Sidebar deck).
Comment 7 sdc.blanco 2020-01-15 16:35:56 UTC
Cannot reproduce STR in comment 3.  (i.e., able to use Navigation window, detached from Sidebar to navigate successfully to set reminders)

Also able to use Navigator deck in Sidebar to navigate to headers,etc. and can undock from Sidebar and still navigate.  (no disappearing toolboxes contra comment 4) (using Windows 10, vcl)

Version: 6.5.0.0.alpha0+ (x64)
Build ID: 035c7717c135c66c0ec025500b73ae9c13b7c586
CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: GL; VCL: win; 

(7. jan 2020 build)
Comment 8 V Stuart Foote 2020-01-15 17:07:24 UTC
(In reply to sdc.blanco from comment #7)
> Cannot reproduce STR in comment 3.  (i.e., able to use Navigation window,

New STR:

1. Open Findbar (<Ctrl>+F), set the 'Navigate by' droplist to page.

2. Close Findbar (the X, or View -> Toolbars -> Find)

3. Open Sidebar -> Navigator deck

4. Split button (Compass) to launch 'Navigation' dialog

5. In dialog, select/click a mode other than Page, dialog should close

Back on Navigator:  what label shows on the back/previous, foward/next arrow buttons?  Is it the selection you just made from the Navigation dialog?

6. Open Findbar

7. use 'Navigate by' droplist to select a mode

8. close Findbar

Back on Navigator: what label now shows on the back/previosu, forward/next arrow buttons? Is it the selectin just made from the Findbar?


Can you repeat 3-5 and get any other mode selected?

On master/6.5.0 builds it goes bad by the 2019-11-25 build (738a11f20ef5b9bcfcc71cca6b0fbea9d06c438b). Also 6.4.0 rc1 build was good, but something got backported so 6.4.0 rc2 build has this issue.
Comment 9 V Stuart Foote 2020-01-15 19:52:51 UTC
Hmm, this is weird!

If the Navigator's pop-up dialog 'Navigation' is positioned over the docked Navigator's deck (Sidebar or the <F5> instance) the mode changes will not take--though they can be set from the Findbar 'Navigate by' droplist.

But if the 'Navigation' dialog pop-up toolbox is dragged off of the docked Sidebar, its controls and ability to select Navigator's mode will enable.

Also occurs if either of the Navigator decks are undocked. The default location where the 'Navigation' toolbox opens is non-functional. Dragging it to a new position restores function of the dialog.

I don't think this is desirable. But I guess there is some sense to the Findbar and the Natigator modes being bound.

This has been a recent regression in the UI, unfortunately with backport to 6.4.0, as set out in the cgit ranges above.
Comment 10 Jim Raykowski 2020-01-15 21:38:44 UTC
Created attachment 157168 [details]
Navigation popup window

(In reply to sdc.blanco from comment #5)
> (In reply to Jim Raykowski from comment #4)
> > I noticed buggy behavior of the Navigation toolbox popup for all vcl
> > backends a short time ago. 
> You mean "Navigator" (F5)?
> 

I've attached a picture of the Navigation popup window that contains a toolbox control .

code for this is here:
https://opengrok.libreoffice.org/xref/core/sw/source/uibase/inc/workctrl.hxx?r=d5d99478#88

HTH
Comment 11 sdc.blanco 2020-01-16 00:58:29 UTC
Created attachment 157174 [details]
screenshot of Navigation popup and Navigator deck

(In reply to Jim Raykowski from comment #10)
> Navigation popup window
Thanks Jim.  I can open the popup Navigation toolbox, and can click on any/all of the icons, without Navigation popup closing.

(In reply to V Stuart Foote from comment #8)
> New STR:
Cannot reproduce.
 
> 5. In dialog, select/click a mode other than Page, dialog should close
Does not close.
 
> Back on Navigator:  what label shows on the back/previous, 
> foward/next arrow buttons? 
See attachment.  The example is for "reminder". The navigation arrows on the Navigation popup shows "Previous Reminder" / "Next Reminder" and the attachment shows the results of the tooltips for the arrows in the Navigator deck.

> Is it the selection you just made from the Navigation dialog?
Yes

With Findbar open, can click on different modes in the popup Navigation toolbox, with the clicked mode name appearing at the bottom of the Navigation popup and in the "Navigate by" window in the Find toolbar.

(Repeated several times, tried all the modes in the Navigation toolbox)
Comment 12 V Stuart Foote 2020-01-16 05:26:39 UTC
(In reply to sdc.blanco from comment #11)
> Created attachment 157174 [details]
> screenshot of Navigation popup and Navigator deck

@Seth,

Note in this clip that the Navigation toolbox dialog has been moved off of the Navigator deck.

Issue seems to occur when the dialog overlays the sidebar Navigator deck (either instance) and has not be dragged to new position. For sure when in its default profile launch location--not clear how far it has to move before it regains function. But when repositioned actions do seem correct.

Stuart
Comment 13 sdc.blanco 2020-01-16 10:00:06 UTC
(In reply to V Stuart Foote from comment #12)
> Issue seems to occur when the dialog overlays the sidebar Navigator deck
> (either instance) and has not be dragged to new position. 
Can now confirm.  (adding step 4.5 to STR in comment 8: make sure not to move the popup Navigation window).  Any click on a mode will close the window, but will not change the mode of "Navigate by". 

> For sure when in
> its default profile launch location--not clear how far it has to move before
> it regains function. But when repositioned actions do seem correct.
From a few attempts:  only minimal movement needed to regain function.
Comment 14 sdc.blanco 2020-01-16 10:59:39 UTC
(In reply to Jim Raykowski from comment #4)
> I noticed buggy behavior of the Navigation toolbox popup for all vcl
> backends a short time ago. Using Windows version the popup box disappears
> when I click on any of the toolbox entries. 
Repro with:

Version: 6.3.4.2 (x64)
Build ID: 60da17e045e08f1793c57c00ba83cdfce946d0aa
CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: da-DK (en_DK); UI-Language: en-US
Calc: threaded

As per previous comment.  If the toolbox popup is NOT moved (also in 6.3.4.2), then one click on a mode will close the toolbox (and also change the mode of "Navigate by").  But if the popup toolbox is moved slightly, then it remains open.

Naive speculation:  Design idea is to allow "popup" of Navigation toolbox for "one-click" change of mode (without extra click to close popup) -- but because the Navigation popup also has previous/next buttons -- any movement will allow popup to remain.  (provides a much easier way to change mode than the listbox in the Find toolbar)   (IMHO: elegant, impressive design)

One more observation:  In the Navigator (F5) or in the Sidebar deck:  there is a a black triangle next to the Compass icon (I assume to indicate a dropdown box).  Two other icons  also have a black triangle: ("Drag mode") and "Heading Levels Shown").  Click on these two others, a drop down box appears. Click on the Navigator compass and the "Navigation" popup toolbox appears.   (if it was supposed to be (or function like) a listbox, then it is not so surprising that it disappears after one click -- which movement "preserves" the toolbox)

A final observation. With "Navigation" popup open, press F1 (help)
Should get: https://help.libreoffice.org/6.5/en-US/text/swriter/01/02110100.html
Notice at bottom under "Repeat Search"  and the statement "With the Repeat search icon on the Navigation toolbar"

Notice that tooltip for that icon in Navigator is "Navigation" and notice "Navigation" in the help page:  See: https://help.libreoffice.org/6.5/en-US/text/swriter/01/02110000.html   And finally notice that this help page (under Navigation) describes this function as "Repeat Search" (and refers to "Repeat Search" icon with a link to the previous page.)

This all seems to confirm my speculation that this is an intended design. 

In sum: 
- only "regression" may simply be the loss of mode change when the popup toolbox is not moved (i.e., serving as a listbox) (and leave everything else alone) 
- suggest that the tooltip for the icon in top left corner of  Navigator window/deck should be "Repeat Search"
- maybe there is a "Repeat Search" icon that already exists and should be on the  top left corner of the Navigator window/deck -- and if not -- then would strongly suggest to find/develop a different icon (because it is too similar to Navigator icon)
- Documentation can be improved (but seems best to make UI design changes (tooltip and icon) and then document them on the two help pages mentioned here).

(all this because Jim added a uno command for "Set Reminder" bug #129468 (-: )
Comment 15 Xisco Faulí 2020-01-16 12:13:54 UTC
I don't see why it's a highest severity bug. Putting it back to Normal
Comment 16 sdc.blanco 2020-01-16 13:52:24 UTC
(In reply to Jim Raykowski from comment #4)
> I noticed buggy behavior of the Navigation toolbox popup for all vcl
It seems that others also see this as a bug.  

https://gerrit.libreoffice.org/c/core/+/86874

Have I understood correctly that this merged patch will remove the possibility for a floating Navigation window?

If so, then this change would "break" the "Repeat Search" function described in:  https://help.libreoffice.org/6.5/en-US/text/swriter/01/02110100.html  
from which the following quote is taken.

Working With the Navigation Toolbar

Open the Navigation toolbar by clicking on its icon located in the vertical scrollbar. You can break the toolbar away from its place by dragging and arrange it on the screen.
Comment 17 V Stuart Foote 2020-01-16 15:34:34 UTC
In reply to sdc.blanco from comment #14)
> ... 
> As per previous comment.  If the toolbox popup is NOT moved (also in
> 6.3.4.2), then one click on a mode will close the toolbox (and also change
> the mode of "Navigate by").  But if the popup toolbox is moved slightly,
> then it remains open.
> ...

True, but that is not the regression we need to be concerned about! The regression in master builds after 2019-11-25 (and now pushed into 6.4.0.2 rc2) is that the Navigation toolbox popup dialog no longer changes the mode of the "Navigate by"--either the Find bar droplist or selecting the active mode of the Navigator from its Navigation toolbox.

(In reply to Xisco Faulí from comment #15)
> I don't see why it's a highest severity bug. Putting it back to Normal

My spin on setting to 'highest' was that the misbehavior of the Navigator's Navigation dialog/toolbox had been introduced between 6.4.0 rc1 and rc2--it needed attention.

Although Caolán looks to have now clobbered the toolbox morph to floating dialog, that work would only correct it now in master against 6.5.0, but it does nothing yet for a 6.4.0 release.

Still need a bibisect from fellow QA folks to pin down the errant commit (that has been back ported into 6.4.0) to better assess seriousness of the regression of not being able to set the mode from Navigator's Navigation toolbox.
Comment 18 V Stuart Foote 2020-01-17 15:12:28 UTC
Testing on Windows with todays TB77 build of master
Version: 6.5.0.0.alpha0+ (x64)
Build ID: 6095612850973388ba5b121b34d02292a2548e7d
CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: GL; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded

With https://gerrit.libreoffice.org/c/core/+/86874 included

The Navigation dialog is more stable now. We do lose ability to tear away the Navigation toolbox, so have to reopen it each time to change the Navigator's mode--alternatively use the list box on the Findbar.

Loosing back/previous, forward/next controls of the floating toolbox is probably a non issue as they are functionally duplicated on the Navigator, on the Findbar, and in the Navigation toolbar.

I'd be happy with this solution for 7.0, but it still leaves breakage at 6.4.0.2--consensus for a back port?

(In reply to sdc.blanco from comment #16)
> If so, then this change would "break" the "Repeat Search" function described
> in:  https://help.libreoffice.org/6.5/en-US/text/swriter/01/02110100.html  
> from which the following quote is taken.
> 
> Working With the Navigation Toolbar
> 
> Open the Navigation toolbar by clicking on its icon located in the vertical
> scrollbar. You can break the toolbar away from its place by dragging and
> arrange it on the screen.

The Help would need to change. But it needs correction now anyway as the Repeat Search passage is in the wrong place, it is not a feature of the Navigation toolbar, but of the Navigation toolbox.
Comment 19 sdc.blanco 2020-01-17 15:47:56 UTC
(In reply to V Stuart Foote from comment #17)
> True, but that is not the regression we need to be concerned about!
To avoid misunderstanding - one point of comment #14 is that this is not a regression.

While the point of comment #16 is that this intended feature (as the help pages indicate) has been lost with the recent change.

I would like to respectfully submit the hypothesis that the "double" function of the popup toolbox (as drop-down list and "tear-away") was not appreciated/recognized -- which has led to its unfortunate demise.
Comment 20 V Stuart Foote 2020-01-17 17:13:52 UTC
(In reply to sdc.blanco from comment #19)
> (In reply to V Stuart Foote from comment #17)
> > True, but that is not the regression we need to be concerned about!
> To avoid misunderstanding - one point of comment #14 is that this is not a
> regression.

Sure it is/was: as you note
<quote>
- only "regression" may simply be the loss of mode change when the popup toolbox is not moved (i.e., serving as a listbox
<\quote>

Severity,

> 
> While the point of comment #16 is that this intended feature (as the help
> pages indicate) has been lost with the recent change.
> 

Has it? Navigator can still be placed into its 'Repeat Search' mode and the previous/next button actions are available.

> I would like to respectfully submit the hypothesis that the "double"
> function of the popup toolbox (as drop-down list and "tear-away") was not
> appreciated/recognized -- which has led to its unfortunate demise.

Pretty sure it was understood for its tear-away role; lots of other droplist/widget toolboxes that do the same.  But, as the old <F5> Navigator was partially refactored to shoehorn it into the Sidebar as a deck--some of its widgets were not fully reworked to make them function as Sidebar content panels. Of course the current <F5> detached Navigator is just another instance of the Sidebar fraemwork (see bug 85905).

So, Caolán's tweak in master just brings a Navigator widget into better UI conformity.
Comment 21 Jim Raykowski 2020-01-18 06:48:21 UTC
I did an enhancement patch a couple years ago for bug 89566. It was ready for use but went abandoned due to lack of interest at the time. 

Here is a screen shot:
https://bug-attachments.documentfoundation.org/attachment.cgi?id=138606 

It replaces the then floating, now popdown, navigation toolbox with the navigate by control used in the findbar.

I have submitted an updated version that only includes the navigation toolbox replacement and some code improvements:
https://gerrit.libreoffice.org/#/c/core/+/87005/
Comment 22 V Stuart Foote 2020-01-18 14:51:08 UTC
(In reply to Jim Raykowski from comment #21)

Shame that fell through the cracks. 

UX decision of Navgator mode selection by listbox vs the popdown toolbox for master/7.0 can be discussed, and personally I do like consistency of mode selection for the Navigator matching UI now on the Findbar.

But what about the regression here at 6.4.0.2?  

Is misbehavior of the docked toolbox a simple fix, or more fundamental in some recent work.  The bibisect/bisect would help.

Or should we just push Caolán's, or even Jim's [1], rework as late feature for a 6.4.0.3/release build? 

=-ref-=

[1] https://gerrit.libreoffice.org/#/c/core/+/87005/
Comment 23 Heiko Tietze 2020-01-20 08:14:13 UTC
Don't think we need UX input on this issue. The whole Navigator is conceptually broken and needs a complete revamp. But here we face an ordinary bug, or not.
Comment 24 Maxim Monastirsky 2020-01-20 09:57:38 UTC
(In reply to V Stuart Foote from comment #20)
> > I would like to respectfully submit the hypothesis that the "double"
> > function of the popup toolbox (as drop-down list and "tear-away") was not
> > appreciated/recognized -- which has led to its unfortunate demise.
> 
> Pretty sure it was understood for its tear-away role; lots of other
> droplist/widget toolboxes that do the same.
Actually many of those "other droplist/widget" also lost the tear-away function recently, e.g. check with the font color or table border toolbar buttons in recent master builds.
Comment 25 V Stuart Foote 2020-01-20 15:27:42 UTC
(In reply to Heiko Tietze from comment #23)
> Don't think we need UX input on this issue. The whole Navigator is
> conceptually broken and needs a complete revamp. But here we face an
> ordinary bug, or not.

Yes what gets done for 6.4.0?

Otherwise, we have Caolán's committed patches for the change to popdown, and Jim's still queued commit to change to listbbox that is held up with merge conflicts.  

Need UX decision, which UI going forward at master/7.0? Should Jim proceed with the 'Navigate by' list box on the Navigator deck?

(In reply to Maxim Monastirsky from comment #24
> Actually many of those "other droplist/widget" also lost the tear-away
> function recently, e.g. check with the font color or table border toolbar
> buttons in recent master builds.

Ouch, was that intentional? I see it now in recent masters, but not affecting 6.4.0.2 (yet?). So time to restore/rework the tearoff where still needed. Interesting recent master in that the Table 'Borders' dialog closes (like the Navigator toolbox was doing), but that the Table 'Border Style' dialog can still tearoff.
Comment 26 Buovjaga 2020-06-08 17:07:49 UTC
Skimming the discussion, it seems there is no need to bibisect anything anymore. Anyway, was unable to locate clear steps among the comments, so I didn't even test.
Comment 27 V Stuart Foote 2020-06-20 14:21:05 UTC
*** Bug 134162 has been marked as a duplicate of this bug. ***
Comment 28 QA Administrators 2022-06-21 03:29:47 UTC Comment hidden (obsolete)
Comment 29 V Stuart Foote 2022-11-13 17:39:32 UTC
Resolveing WFM,  6.4 long EOL and rework of the Navigator at 7.0 in place and functional.  New status quo...