Description: UI: Cursor disappears when expanding/collapsing the sidebar Steps to Reproduce: 1. Open Writer 2. Enable the sidebar (if not enabled) 3. Click the properties deck button (expanding; or collapsing) -> Notice that the cursor gone missing Actual Results: Focus removed from the document Expected Results: Clicking on the sidebar shouldn't affect the cursor Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 6.2.0.0.alpha0+ Build ID: 1aa37aa6bee19099b57555a6d839992b054aa405 CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-09-23_10:17:54 Locale: nl-NL (nl_NL); Calc: CL but not in Versie: 4.4.7.2 Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600 Locale: nl_NL
It doesn't. The Edit cursor remains at position and when focus is directly returned to the document canvas with <Ctrl>+F6, or with other focus movement it Widget controls in Sidebar had incorrect linkages back to document canvas, they were isolated at 6.1 (see bug 115434, or related bug 120122 when SideBar is floating). IHMO => NAB but I'll let Jim chime in.
The sidebar button grabs focus on mouse click was done in bug 115451 fix to prevent focus from being hid in a deck panel. If it is decided that Telesto's opinion that focus should remain in the document is better UX then focus being set to the button I will try to find a way to not have the sidebar button grab the focus if focus is in the document.
I prefer a cursor inside the document. * Switch between canvas and sidebar its cumbersome * Switch between canvas and sidebar using a 'obscure' key combo (CMD+F6) isn't obvious * There is no visual indication that on the focus of the sidebar when docked * It doesn't happen with a docked/floating formatting toolbar either. * Some similar issue got fixed: bug 114935 * The cursor gives relevant information: Insert at table; open the sidebar -> switch to styles -> table button. Cursor inside a table -> while apply the formatting. Outside no effect. Side note: initially this about the sidebar in docked mode (but floating one has the same issue).
The keyboard navigation on the sidebar is a finely crafted piece of usability/accessibility art, presented at [1] and carved in stone at [2]. We have to distinguish between edit controls like font name where <enter> applies the current value and moves the focus back to the document and sidebar UI controls needed for navigation that keep the focus. In any case you have a proper feedback where the focus is, depending on OS/DE. And actually the use case sounds a bit far-fetched. While working in a table (or something else) the user gets confused by a sidebar section and closes it, and don't remember where he or she was a second before. Unlikely :-) It's rather a modification of a property and as said above you press enter to go back. Setting to NAB, feel free to reopen for more input. [1] https://design.blog.documentfoundation.org/2017/02/16/guidelines-for-keyboard-navigation-in-the-sidebar/ [2] https://wiki.documentfoundation.org/Design/SideBar
Convincing the UX-team is quite hard, I noticed. Lets give it a second try, with some - artificial? - examples (before I throw the towel). Widening the scope to LibreOffice (not only Writer) Some arguments additional 1. The current solution breaks with the LibreOffice behavior prior to LibO 6.1 (for non-keyboard users) 2. The change was made on a technical reason (not a design decision) & it's fixable without concessions to the keyboard navigation (if I understand Jim correctly) 3. It's rather inconsistent (floating formatting toolbar behaves differently 4. Changing the font size or font type focuses the document again (keyboard/mouse) 5. The cursor keeps inside the document when using the properties deck (it only loses focus after switching between decks & back) Few examples: 1. Open Impress; 2. Ignore the Template manager; 3. Switch to Master slides, 4. Choose a template 5. Click into a textbox 6. Switch to properties deck 7. Apply Bold 8. Start typing -> Not working 9. Press CTRL+F6 -> Working but no cursor 1. Open Calc 2. Go to Styles 3. Select (for example a status style) for A1 4. Select A2 5. Switch to properties deck 6. Start typing > No go 1. Open Writer 2. Go to styles 3. Select Heading 1 4. Type something 5. Press Enter 6. Switch to the properties deck 7. Press Center Horizontally 1. Open Writer 2. Insert Gallery item.. 3. Press Enter a few times, and start typing 4. Switch to the properties deck & select bold 5. Go on with typing (no go) 6. Do the same with (floating) formatting toolbar (working)
Here is a patch to try that sets focus to the document when a deck tab in the sidebar is clicked: https://gerrit.libreoffice.org/#/c/61457/
(In reply to Telesto from comment #5) > Convincing the UX-team is quite hard... Thanks for this compliment (meaning we are open for good arguments, which is the fact). > Few examples: > 1. Open Impress; > 2. Ignore the Template manager; > 3. Switch to Master slides, > 4. Choose a template > 5. Click into a textbox > 6. Switch to properties deck > 7. Apply Bold > 8. Start typing -> Not working > 9. Press CTRL+F6 -> Working but no cursor Don't get the point with master on/off but when I make the selection bold via sidebar I can type ahead. > 1. Open Calc > 2. Go to Styles > 3. Select (for example a status style) for A1 > 4. Select A2 > 5. Switch to properties deck > 6. Start typing > No go Yes; if the focus is on the tab bar you go through the items per cursor and select with enter (as defined in sidebar HIG: Keyboard Access). If you switch to another tab the focus is on the section, enter moves into the first control, and enter applies (as defined). We could add here escape to exit. > 1. Open Writer > 2. Go to styles > 3. Select Heading 1 > 4. Type something > 5. Press Enter > 6. Switch to the properties deck > 7. Press Center Horizontally Works for me, and I don't why the steps before 7 are needed. > 1. Open Writer > 2. Insert Gallery item.. > 3. Press Enter a few times, and start typing > 4. Switch to the properties deck & select bold > 5. Go on with typing (no go) > 6. Do the same with (floating) formatting toolbar (working) Same here. And it would be nice to add whether you use mouse with single/double-click or keyboard. We can also talk about the generic definition at https://wiki.documentfoundation.org/File:LO-HIG_SideeBar-KeyboardAccess.png
(In reply to Heiko Tietze from comment #7) > (In reply to Telesto from comment #5) > > Convincing the UX-team is quite hard... > > Thanks for this compliment (meaning we are open for good arguments, which is > the fact). > > > Few examples: > > 1. Open Impress; > > 2. Ignore the Template manager; > > 3. Switch to Master slides, > > 4. Choose a template > > 5. Click into a textbox > > 6. Switch to properties deck > > 7. Apply Bold > > 8. Start typing -> Not working > > 9. Press CTRL+F6 -> Working but no cursor > > Don't get the point with master on/off but when I make the selection bold > via sidebar I can type ahead. > > > 1. Open Calc > > 2. Go to Styles > > 3. Select (for example a status style) for A1 > > 4. Select A2 > > 5. Switch to properties deck > > 6. Start typing > No go > > Yes; if the focus is on the tab bar you go through the items per cursor and > select with enter (as defined in sidebar HIG: Keyboard Access). If you > switch to another tab the focus is on the section, enter moves into the > first control, and enter applies (as defined). We could add here escape to > exit. > > > 1. Open Writer > > 2. Go to styles > > 3. Select Heading 1 > > 4. Type something > > 5. Press Enter > > 6. Switch to the properties deck > > 7. Press Center Horizontally > > Works for me, and I don't why the steps before 7 are needed. > > > 1. Open Writer > > 2. Insert Gallery item.. > > 3. Press Enter a few times, and start typing > > 4. Switch to the properties deck & select bold > > 5. Go on with typing (no go) > > 6. Do the same with (floating) formatting toolbar (working) > > Same here. And it would be nice to add whether you use mouse with > single/double-click or keyboard. We can also talk about the generic > definition at > https://wiki.documentfoundation.org/File:LO-HIG_SideeBar-KeyboardAccess.png To be sure, that we are on the same page. All examples are about mouse actions (so "Choose template' means (left)click the template button of the sidebar; switch to properties deck means, (left) click the properties deck button. I'm not talking about (partly) using keyboard navigation (or shortcuts) in any form. I'm Fred the type of persons who uses the mouse for every action except typing :-)
(In reply to Telesto from comment #8) > To be sure, that we are on the same page. All examples are about mouse > actions... Okay, but we have to take a11y into account. If the focus is somewhere in the sidebar we need means to jump to the next control. Does that change your mind?
(In reply to Heiko Tietze from comment #9) > (In reply to Telesto from comment #8) > > To be sure, that we are on the same page. All examples are about mouse > > actions... > > Okay, but we have to take a11y into account. If the focus is somewhere in > the sidebar we need means to jump to the next control. Does that change your > mind? Two questions 1. UX perspective: Can the report be seen as an user experience problem -> Surely (in my opinion of course). Improving one area, losing functionality in a different area isn't a great approach IMHO. 2. Technical/Developer perspective: possible approaches/downsides. Jim has made a patch. Not sure what it means for keyboard navigation or a11y. He might have tested it in advance... I prefer a implementation where everybody can be happy :-).
Keyboard access to the sidebar is unchanged by the patch offered in comment 6. Still use F6 to eventually enter sidebar or F11 for a shortcut. The patch places focus in the document as opposed to on the tab button itself on mouse click or space key press. This also avoids the hidden cursor issue which was the reason for the change to the tab button grabbing focus on click. Enter key press on a deck tab still keeps focus in the sidebar. Either way I like not having focus hidden :-)
(In reply to Jim Raykowski from comment #11) > The patch places focus in the document as opposed to on the tab button > itself on mouse click or space key press. This also avoids the hidden cursor > issue which was the reason for the change to the tab button grabbing focus > on click. > What I see is that the patch keeps the focus in the document when you click on the sidebar tabs. It doesn't on the deck title or content panel title neither when going to the tabs bar via keyboard. In all these situations the focus is not in the document anymore. Not being an a11y expert, Stuart, what do you think?
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6626281b4a123cfb5e2c8f449b55f4acd46ee198 tdf#120231 Focus to document on sidebar tabbar deck tab click It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.