After opening a writer (or calc) document I normally exit the by hitting CTRL-W. All good. I open a writer (or calc) document. Press CTRL-F to search for text, enter the text string and then press ENTER. I then press CTRL-W to exit - no action. I take the mouse out of the search box and into the text and click anywhere I then press CTRL-W and can exit the file. I was expecting to be able to exit at any time, not just with the cursor in the text. Fedora 20/LO4.2.1.1 This "feature" also exists in Windows XP LO4.2.04
Yes, we have the same behavior when the focus is not in the text window, for example in the Navigator. Already reproducible in version 4.1.5. Same behavior with ctrl+Q to quit the application. Not sure if we should consider that as a bug, added UX-advise in CC. Best regards. JBF
(In reply to comment #1) > Not sure if we should consider that as a bug, added UX-advise in CC. Tim's issue sounds like a bug to me. The issue with the Navigator is a bit more tricky since the Navigator has an own (palette) window. But still, I think, per main-window key bindings should be respected wherever the focus is (within the window and its palette windows) unless they collide with a key binding for the current element. (In that case, the key binding for the element should take precendence.) Palette windows are also main-window specific, i.e. they don't become another main window's subwindow when focus changes from one main window to another. So this should be no problem to implement.
** 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 on a currently supported version of LibreOffice (4.4.2 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-05-02
this problem is still occurring in both writer and calc. Fedora 22. Version: 5.0.0.0.alpha1 Build ID: 77a35997fa7cff387b5b135ff0c42155f80e9884 Locale: en_AU
** 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 on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Still reproducible in LO 5.2.3.0+ and current master, both built at home under Ubuntu 16.04 x86-64. Best regards. JBF
** 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 on a currently supported version of LibreOffice (5.4.1 or 5.3.6 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170929
Still reproducible in LO 5.4.4.0.0+ built at home under Ubuntu 16.04 x86-64. Best regards. JBF
** 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
Still reproducible in LO 6.2.0.1.0+ under Ubuntu 18.04. Best regards. JBF
Adding needsUXEval as it was asked for in 2014.
Caolan, can we change this at all without explicitly binding generic keys for every single widget?
Have to admit, I get a bit confused between shortcuts assigned in VCL [1] vs. shortcuts assigned to .uno actions as accelerators [2], and which actually assert, and where used, in the UI. It seems like the usage has drifted apart. The mishandling of the Q_MOD1 (<Ctrl>+Q) assigned .uno:Quit action is see also bug 97511 =-ref-= [1] https://opengrok.libreoffice.org/xref/core/vcl/source/window/keycod.cxx?r=55402d82#37 [2] https://opengrok.libreoffice.org/xref/core/officecfg/registry/data/org/openoffice/Office/Accelerators.xcu?r=6607e291#222
You can just hit esc a few times and then ctrl+w. The general scheme of things is that the handling of an event bubbles up from the target widget so if not handled by it the event is passed to the parent to have a go. Don't really know if that's the case here or not. FWIW the same will happen if you put the focus in e.g. the fontname widget in the standard toolbar. I'll attach a hackaround for this one specific case if someone else want to take it and run with it.
Created attachment 154023 [details] make this work for this specific widget
Indeed, this happens in many places. E.g. Ctrl+W if focus is in Navigator.. nope. Questen is: is it fine to imrove some situations and have the rest (hard to fix, or unknown) untouched?
Let's apply Caolan's patch(es) situation-dependent. Basically the fizzing events should work but I'm not sure that alt+f4 or ctrl+w needs to work in every context.
Still the case in: Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: 24087697d5cf78aac346d4dcea0596373e15a95c CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Tested with Ctrl+Q after opening the search bar.