Description: Dear all, Tested environment : - LibreOfficeDev 5.4 on Debian GNU/Linux 8.7 - LibreOffice 5.3.2 on Windows 8.1 I'm a low-vision person so I'm a keyboard-only user. At this time it is not possible to use the envelope dialog only with the keyboard because it's not possible to leave the texts fields with tab. Steps to Reproduce: Steps to reproduce : 1) Open the envelope dialog (insert => envelope) 2) Press tab or ctrl+tab Actual Results: LibreOffice writes the tab character or switches to the next tab Expected Results: LibreOffice should leave the text field when I press tab Reproducible: Always User Profile Reset: No Additional Info: Best regards. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0
(In reply to Alex ARNAUD from comment #0) > it's not possible to leave the texts fields with tab. As its is a multiline textbox and not a single line textbox, tabs are treated as tabs, but shift+tab works as it should. Ctrl+tab is for switching tabs of the dialog. @Stuart: If you disagree, please reopen.
As Jay mentioned, shift + tab does the trick here.
(In reply to Yousuf Philips (jay) from comment #1) > (In reply to Alex ARNAUD from comment #0) > > it's not possible to leave the texts fields with tab. > > As its is a multiline textbox and not a single line textbox, tabs are > treated as tabs, but shift+tab works as it should. Ctrl+tab is for switching > tabs of the dialog. > > @Stuart: If you disagree, please reopen. Your mind is correct for a sighted persons. Do you really think that a blind person should read the content of the dialog in reverse order ? It's already quite complicated to understand the screen for the blinds persons so IMO it isn't user-friendly. The envelope dialog is important for persons unable to write sender on the enveloper themselves. Best regards.
Hi! I totally agree with Alexarnaud. I'm blind to. Reverse navigating through the dialog takes a while! Regards, Raphaël
(In reply to Alex ARNAUD from comment #3) > Do you really think that a blind person should read the content of the > dialog in reverse order ? It's already quite complicated to understand the > screen for the blinds persons so IMO it isn't user-friendly. The bug report was opened about not being able to leave the textbox, which was incorrect, which is a different issue of the dialog not being a11y friendly. If you'd like to suggests ways to improve the dialog to make it easier for a11y users to work in it, i'm always up to hearing them. So let's use this bug for that rather than opening up a new one. So in other apps, when a user arrives at a multiline textbox that is to contain tab characters in it, how does navigation work there? I've checked some apps and some do not permit you to press tab in them (e.g. thunderbird's new contact dialog's other tab), while others do (qbittorrent's options dialog's bittorrent tab).
Can be also reproduced in LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
(In reply to Yousuf Philips (jay) from comment #5) > The bug report was opened about not being able to leave the textbox, which > was incorrect, which is a different issue of the dialog not being a11y > friendly. If you'd like to suggests ways to improve the dialog to make it > easier for a11y users to work in it, i'm always up to hearing them. So let's > use this bug for that rather than opening up a new one. You are completely right. > So in other apps, when a user arrives at a multiline textbox that is to > contain tab characters in it, how does navigation work there? I've checked > some apps and some do not permit you to press tab in them (e.g. > thunderbird's new contact dialog's other tab), while others do > (qbittorrent's options dialog's bittorrent tab). I propose this two behavior : - Disabling the usage of tab in theses fields or - ctrl+tab in theses fields leave them, switching between tabs could be done with ctrl+tab when the user keyboard focus is on an other item. Best regards.
(In reply to Alex ARNAUD from comment #7) > > So in other apps, when a user arrives at a multiline textbox that is to > > contain tab characters in it, how does navigation work there? I've checked > > some apps and some do not permit you to press tab in them (e.g. > > thunderbird's new contact dialog's other tab), while others do > > (qbittorrent's options dialog's bittorrent tab). > > I propose this two behavior : > - Disabling the usage of tab in theses fields This would be the safest thing to do as long as the fields dont need the use of a tab character in them. @Regina, @Cor, @Heiko: Input please. > - ctrl+tab in theses fields leave them, switching between tabs could be done > with ctrl+tab when the user keyboard focus is on an other item. Not sure you can overwrite the default handling of ctrl+tab, but we'd have to ask a dev if its possible. @Maxim, @Szymon, @Bubli: Input please.
(In reply to Yousuf Philips (jay) from comment #8) > (In reply to Alex ARNAUD from comment #7) > > I propose this two behavior : > > - Disabling the usage of tab in theses fields > > This would be the safest thing to do as long as the fields dont need the use > of a tab character in them. @Regina, @Cor, @Heiko: Input please. The labels have accelerators so you get out of this input field with alt+D/T/F... in case of English. Disabling tabs makes it impossible to simulate columns, which might be interesting for envelopes. -> WONTFIX Another observation in this dialog is at the Printer tab where the first selection with icons is not labeled. It is part of the tab sequence but without a focus frame so hardly to recognize.
(In reply to Yousuf Philips (jay) from comment #8) > (In reply to Alex ARNAUD from comment #7) > > > So in other apps, when a user arrives at a multiline textbox that is to > > > contain tab characters in it, how does navigation work there? I've checked > > > some apps and some do not permit you to press tab in them (e.g. > > > thunderbird's new contact dialog's other tab), while others do > > > (qbittorrent's options dialog's bittorrent tab). > > > > I propose this two behavior : > > - Disabling the usage of tab in theses fields > > This would be the safest thing to do as long as the fields dont need the use > of a tab character in them. @Regina, @Cor, @Heiko: Input please. > > > - ctrl+tab in theses fields leave them, switching between tabs could be done > > with ctrl+tab when the user keyboard focus is on an other item. > > Not sure you can overwrite the default handling of ctrl+tab, but we'd have > to ask a dev if its possible. @Maxim, @Szymon, @Bubli: Input please. Any input ? It's a major issue for keyboard-only users as visual-impaired people. Best regards.
(In reply to Yousuf Philips (jay) from comment #8) > > > - ctrl+tab in theses fields leave them, switching between tabs could be done > > with ctrl+tab when the user keyboard focus is on an other item. > > Not sure you can overwrite the default handling of ctrl+tab, but we'd have > to ask a dev if its possible. @Maxim, @Szymon, @Bubli: Input please. I think it is possible using IsMod1() to check if ctrl is used and KEY_TAB code. It could be an easy hack :) Useful links: http://opengrok.libreoffice.org/xref/core/include/vcl/keycod.hxx#34 http://opengrok.libreoffice.org/xref/core/offapi/com/sun/star/awt/KeyModifier.idl#37 Example of using key codes: http://opengrok.libreoffice.org/xref/core/svx/source/tbxctrls/itemwin.cxx#419 Envelope dialog: http://opengrok.libreoffice.org/xref/core/sw/source/ui/envelp/envlop1.cxx#192
** 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
This bug is still present on LibreOffice 6.1.2.1. Tab is not really useful for these field so looks like a good solution to not allow writting tab in these fields, in this case we could be able to jump to the next field instead of reading all the dialog in reverse order using tab key.
Task might have become a tad harder now with welded controls on Linux. Also perhaps a clarified definition of what should be done might be needed (modify multiline text behaviour, or just the global tab travelling)?
(In reply to Thorsten Behrens (CIB) from comment #14) > ...clarified definition of what should be done... Alex & UX people, please elaborate the planned changes.
(In reply to Heiko Tietze from comment #15) > (In reply to Thorsten Behrens (CIB) from comment #14) > > ...clarified definition of what should be done... > > Alex & UX people, please elaborate the planned changes. I propose to stay consistent to what Java Swing and Microsoft does, see there for the Microsoft way: https://docs.microsoft.com/fr-fr/dotnet/api/system.windows.forms.textboxbase.acceptstab?view=netframework-4.7.2 - Let tab behavior as it is - Fix shift tab because shift+tab does the same as tab - Control + tab would be used to leave the multi-lines elements Best regards, Alex.
Just for clarification, we talk about File > Wizards > Letter, right? The dialog has hotkeys (alt+B/F/P on the first step) and you can tab through active controls (though feedback of current focus is not correct for me). And shift-tab traverse the opposite way. What exactly is missing?
(In reply to Heiko Tietze from comment #17) > Just for clarification, we talk about File > Wizards > Letter, right? No, we're talking about Envelope dialog inside the insert menu. See comment #1. Best regards, Alex.
(In reply to Alex ARNAUD from comment #18) > (In reply to Heiko Tietze from comment #17) > > Just for clarification, we talk about File > Wizards > Letter, right? > > No, we're talking about Envelope dialog inside the insert menu. See comment > #1. Oops, comment #1 is not the description. See my initial description. Best regards, Alex.
Okay, this dialog looks indeed weird. Let's make a proposal for redesign.
(In reply to Alex ARNAUD from comment #16) > (In reply to Heiko Tietze from comment #15) > > (In reply to Thorsten Behrens (CIB) from comment #14) > > > ...clarified definition of what should be done... > > > > Alex & UX people, please elaborate the planned changes. > > I propose to stay consistent to what Java Swing and Microsoft does, see > there for the Microsoft way: > https://docs.microsoft.com/fr-fr/dotnet/api/system.windows.forms.textboxbase. > acceptstab?view=netframework-4.7.2 > - Let tab behavior as it is > - Control + tab would be used to leave the multi-lines elements That is actually what gtk3 does too. When the focus is inside a GtkTextView, tab inserts a tab, and control-tab switches to the next control. Even if control-tab usually switches tabs of the dialog. (In reply to Heiko Tietze from comment #20) > Okay, this dialog looks indeed weird. Let's make a proposal for redesign. Well, a redesign will not change the issue: as long as there are e.g. buttons after the input control which eats tabs, people who can only use a keyboard can not escape from it the normal way to reach the buttons, they'd have to shift-tab to escape backward, and press shift-tab a lot of times only to get back to the buttons, and possibly pressing one time too much and get stuck *again* in the input control, and thus have to do shift-tabs again (and possibly again pressing once too much, etc.). That is really not a usable behavior, while making an exception for control-tab just here would just work, and be coherent with other UI toolkits.
(In reply to Alex ARNAUD from comment #16) > - Let tab behavior as it is > - Fix shift tab because shift+tab does the same as tab > - Control + tab would be used to leave the multi-lines elements Fine for me. NB. I notice the TAB behavior is broken in more aspects in version Version: 6.3.0.0.alpha0+ Build ID: 89b1a00e08d8938714dd493fa27f08ba8d9b618d CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-04-21_15:52:39 Locale: nl-NL (nl_NL.UTF-8); UI-Language: en-US Calc: threaded
(In reply to Thorsten Behrens (allotropia) from comment #14) > ... a clarified definition of what should be done might be needed (In reply to Alex ARNAUD from comment #7) > - ctrl+tab in theses fields leave them, switching between tabs could be done > with ctrl+tab when the user keyboard focus is on an other item. (In reply to Alex ARNAUD from comment #16) > - Let tab behavior as it is > - Fix shift tab because shift+tab does the same as tab > - Control + tab would be used to leave the multi-lines elements (In reply to Samuel Thibault from comment #21) > That is actually what gtk3 does too. When the focus is inside a GtkTextView, > tab inserts a tab, and control-tab switches to the next control. Even if > control-tab usually switches tabs of the dialog. So the task is to traverse controls on (shift)+ctrl+tab as happening on other controls. Simple tab key should still insert a literal tab. Possible code pointer in comment 11. Caolan, are you bored?
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/474038abe7155bf7d85ae5a2e305d5ba37ab35ea Resolves: tdf#107625 make ctrl+tab act like tab when tab is an input char It will be available in 7.5.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0f348ba55db9eabe990b5bbeb42d1d94b3b70e79 Resolves: tdf#107625 make ctrl+tab act like tab when tab is an input char It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.