as per subject. This unlike the behavior in Writer. Align this ??
Hi @Cor, no repro, column field gets the focus for me, with: Version: 5.4.2.2 (x64) Build ID: 22b09f6418e8c2d508a9eaf86b2399209b0990f4 CPU threads: 4; OS: Windows 6.19; UI render: default; Locale: es-ES (es_ES); Calc: group
The column field is enabled in fresh and master. Writer puts the focus at the objects list/tree (which is btw not part of the tab sequence in Calc). Do you mean to harmonize this behavior?
Thanks Mario! My summary was not clear. Does it make sense now? I mean the old Navigator, not the one in the Side Bar, but docked. Indeed, if floating, I have what you describe.
(In reply to Heiko Tietze from comment #2) > The column field is enabled in fresh and master. Writer puts the focus at > the objects list/tree (which is btw not part of the tab sequence in Calc). > Do you mean to harmonize this behavior? Yes, harmonizing makes sense and indeed including the list in the tab order! thanks.
Confirming the issue for the docked Navigator (shift+ctrl+F10 is your friend). Please include the list with Sheets, Range, Database... in the tab sequence (ally issue) and focus this control having the active sheet selected when the Navigator is enabled per F5. That allows the user to just press Enter to jump back to the sheet.
@Cor, how are you getting the F5 second instance of Navigator deck to dock? With 5.4.2.2 and recent master Windows builds, I can not.
A service for Stuart who never reads my comments: (In reply to Heiko Tietze from comment #5) > ... (shift+ctrl+F10 is your friend).
(In reply to Heiko Tietze from comment #7) > A service for Stuart who never reads my comments: > > (In reply to Heiko Tietze from comment #5) > > ... (shift+ctrl+F10 is your friend). :D, Actually, I had another installed application (Alertus Desktop) holding the <shift><ctrl>+F10 shortcut assignment for OS. But, drag-to-dock does not work for this dialog--no attachment target gets shown. (In reply to Cor Nouws from comment #3) > I mean the old Navigator, not the one in the Side Bar, but docked. There is no "old Navigator", just a second instance of the source as wrapped for use the Sidebar's deck (bug 73151#c14). That it does not receive focus when it is docked seems odd because when held in the Sidebar deck it _does_ receive the focus. I think this is not an easy hack and seems related to the fact that to the two instances are not kept in sync (i.e. movement and actions are independent). It is annoying and maybe some simple connection needs to be made--but I still think the best way to "fix" this is to complete work on bug 85905 and have only one instance of the Navigator and a UI that behaves.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
@Jim, in Calc the "secondary" <F5> Navigator when undocked takes focus on launch, but it does not when in docked state as in summary. Otherwise the full sidebar Navigator deck in Calc does not take focus on launch, docked or floating. Wouldn't expectation be for focus to be in Navigator on launch for both instances, in either state (docked or undocked)? Sidebar -- in Calc the Sidebar instance of Navigator is well synced with the secondary <F5> instance. But in Writer they are not so well joined. Is there something missing from the Writer instance of the Sidebar deck?
(In reply to V Stuart Foote from comment #10) Hi Stuart, I was going to jump in on this one after seeing the untouched bug notification. Thanks for the invite! We can make the Calc version of Navigator focus on any content in Navigator on initial showing for both the floating and docked mode. The Writer version content tree grabs focus on initial showing. There is a side effect to this that occurs in the sidebar which causes focus to be placed in the tree list the first time the Navigator deck is selected. Subsequent Navigator deck selection with mouse click does not place focus in the content tree but back to the document in the current master at the time of this post. When the F5 Navigator is undocked focus is in the undocked window but since the window itself is non active it causes a focus lock. To test this, place focus in the Column or Row spin box when the Navigator is docked, then undocking with Ctrl+Shift+F10. The floating/child window is not active which can be seen by the shaded title bar. Focus is locked in the spin box. A mouse click on the Navigator window title bar will show the cursor in the spin box or whatever content was focused when the window was undocked. > Sidebar -- in Calc the Sidebar instance of Navigator is well synced... I like the Sidebar pun! but I am unsynced on the well synced thing? :-)
(In reply to Jim Raykowski from comment #11) > (In reply to V Stuart Foote from comment #10) > > Sidebar -- in Calc the Sidebar instance of Navigator is well synced... > I like the Sidebar pun! but I am unsynced on the well synced thing? :-) Sorry, this is really a different issue--observing differences in the synchronization of control focus between the two Navigator panels (<F5> and in Sidebar proper) between the Calc implementation and the Writer implementation. In Calc the two will each refresh to follow the same focus. In Writer they are independent--no linkage between them so out of sync as far as the element with focus.
Hi Jim, Stuart, (In reply to Jim Raykowski from comment #11) > (In reply to V Stuart Foote from comment #10) > We can make the Calc version of Navigator focus on any content in Navigator > on initial showing for both the floating and docked mode. The Writer version > content tree grabs focus on initial showing. Fine for me, if it doesn't cause the same effect as in Writer: bug 49684. (In reply to V Stuart Foote from comment #12) > ... In Calc the two will each refresh to follow the same focus. > In Writer they are independent--no linkage between them so out of sync as > far as the element with focus. With content view for headings, Navigator in Writer should follow the selected part of text. For the rest, I don't see a need/advantage of the both versions to be in sync. Especially since I don't expect people to use the two at the same time, and if, it might even be an advantage that they are not synced?
Don't think we need more input from UX (and keyword was not set anyway), removing the ML.
Dear Cor Nouws, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear Cor Nouws, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Problem still the same in Version: 7.4.1.2 / LibreOffice Community Build ID: 3c58a8f3a960df8bc8fd77b461821e42c061c5f0 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: nl-NL (en_US.UTF-8); UI: nl-NL Calc: threaded