Steps: 1) Open LO 2) Tools > Extension Manger 3) Select an extension that has an 'Options' button 4) Click 'Options' button and then cancel the dialog 5) Notice that 'Options' button now has keyboard focus 6) Press up or down until you get to an entry without an 'Options' button 4) Press spacebar 5) Blank options dialog appears Version: 5.3.0.0.alpha0+ Build ID: f7513f0f53f2d074c08610a68fb787bb379c31d4 CPU Threads: 2; OS Version: Linux 3.19; UI Render: default; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-09-02_23:58:05 Locale: en-US (en_US.UTF-8); Calc: group
Confirmed with v4.4.0.3 / Windows 7. In v4.2.0.4 there's a crash if I do this, the current behavior might be the result of a fix to that crash. Adjusting importance, since it doesn't affect professional work.
Yes the crash happens from 3.4 to 4.2 and doesnt in 4.3.
Created attachment 127872 [details] Extension Manager Error on Pressing Space When No Disable Button There is more. Similar behavior observed also for "Disable" and "Remove" buttons. It gives an error message in those cases. (See the screenshot)
@Mohammet: Can we move the 'Options' button out of the list and have it on a row below the list along with buttons for 'add', 'update' and 'remove', rather than some of these buttons being next to the close button?
Muhammet Kara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b193f283457c290e2cd75df0f3f6a185b66a516d tdf#102004 Do not open options for extensions without options It will be available in 5.3.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.
(In reply to Yousuf Philips (jay) from comment #4) > @Mohammet: Can we move the 'Options' button out of the list and have it on a > row below the list along with buttons for 'add', 'update' and 'remove', > rather than some of these buttons being next to the close button? Let's close this bug report as it has already been fixed with the merged patch. And continue discussing the UI changes of this dialog on a separate bug report.
> Oct 12 10:39:57 <sberg> caolan, re b193f283457c290e2cd75df0f3f6a185b66a516d, I wonder whether Disable() should be implicitly done in Hide() (i.e., if there's more dialogs that would need such fixing) > Oct 12 10:39:59 <IZBot> core - tdf#102004 Do not open options for extensions without options - http://cgit.freedesktop.org/libreoffice/core/commit/?id=b193f283457c290e2cd75df0f3f6a185b66a516d > Oct 12 10:46:56 <caolan> sberg: hmm, I bet something somewhere depends on Hide not Disabling anything. Reading the bug it seems that the focus remains "stuck" in the hidden button so the keyboard press still goes to it > Oct 12 10:47:03 <caolan> that doesn't happen for me locally > Oct 12 10:48:27 <sberg> maybe a difference in platform? but anyway, lets keep it that way, then > Oct 12 10:49:32 <caolan> same behaviour in gtk3, gtk and gen for me. Wonder if its a windows thing. Probably a bug there to keep the focus in a hidden widget or something
(In reply to Stephan Bergmann from comment #7) > > Oct 12 10:39:57 <sberg> caolan, re b193f283457c290e2cd75df0f3f6a185b66a516d, I wonder whether Disable() should be implicitly done in Hide() (i.e., if there's more dialogs that would need such fixing) > > Oct 12 10:39:59 <IZBot> core - tdf#102004 Do not open options for extensions without options - http://cgit.freedesktop.org/libreoffice/core/commit/?id=b193f283457c290e2cd75df0f3f6a185b66a516d > > Oct 12 10:46:56 <caolan> sberg: hmm, I bet something somewhere depends on Hide not Disabling anything. Reading the bug it seems that the focus remains "stuck" in the hidden button so the keyboard press still goes to it > > Oct 12 10:47:03 <caolan> that doesn't happen for me locally > > Oct 12 10:48:27 <sberg> maybe a difference in platform? but anyway, lets keep it that way, then > > Oct 12 10:49:32 <caolan> same behaviour in gtk3, gtk and gen for me. Wonder if its a windows thing. Probably a bug there to keep the focus in a hidden widget or something It also happens (before the patch) on Pardus/Debian Stretch with GNOME desktop: CPU Threads: 4; OS Version: Linux 4.7; UI Render: default; Locale: en-US (en_US.utf8); Calc: group