Bug 79657 - LibreLogo: Unable to enter commands when toolbar is wrapped
Summary: LibreLogo: Unable to enter commands when toolbar is wrapped
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.0.6.2 release
Hardware: Other All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard: target:6.0.0 target:6.1.0
Keywords:
Depends on:
Blocks: LibreLogo Toolbars-Overflow
  Show dependency treegraph
 
Reported: 2014-06-04 22:47 UTC by Yousuf Philips (jay) (retired)
Modified: 2025-11-23 12:49 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
how the toolbar and commandline look (86.74 KB, image/png)
2014-06-04 22:47 UTC, Yousuf Philips (jay) (retired)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2014-06-04 22:47:47 UTC
Created attachment 100425 [details]
how the toolbar and commandline look

When the LibreLogo toolbar is wrapped, you are unable to access the commandline field.
Comment 1 Firas Hanife 2014-06-22 16:31:55 UTC
Same here on openSUSE with 4.1, 4.2 and 4.3.

Changing Status to NEW and updating affected LibreOffice version.
Comment 2 Yousuf Philips (jay) (retired) 2014-06-22 16:36:04 UTC
I assume the Logo toolbar was added in 4.0 and i can confirm it is the same behaviour in 4.0.6 and 4.4 alpha.
Comment 3 Owen Genat (retired) 2014-09-30 11:30:53 UTC
Summary amended for consistency with other LibreLogo reports.
Comment 4 QA Administrators 2015-10-14 19:57:42 UTC Comment hidden (obsolete)
Comment 5 Julien Nabet 2016-11-27 20:31:33 UTC
With LO Debian package 5.2.3, I can also reproduce this when I just enable the Logo toolbar.
But if I restart LO, the toolbar is fully display because it has moved on a newline.
Also, even without restarting LO, the toolbar can be moved to a newline.

Now I don't know if the display could be also fixed just when enabling the toolbar.
Comment 6 Yousuf Philips (jay) (retired) 2017-10-08 12:17:57 UTC
Still present.

Version: 6.0.0.0.alpha0+
Build ID: 74b47af9885ba4c59195fedc1e0510b8b056a025
CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; 
Locale: en-US (en_US.UTF-8); Calc: group

Maxim: Any thoughts about how to deal with text fields that are being wrapped?
Comment 7 Maxim Monastirsky 2017-10-09 13:57:14 UTC
(In reply to Yousuf Philips (jay) from comment #6)
> Maxim: Any thoughts about how to deal with text fields that are being
> wrapped?
Text fields (as any other control) can be displayed in the overflow popup, as you can test already with other toolbars. What special about LibreLogo is that it's implemented as a (bundled) extension, rather than a regular toolbar (i.e. it's in officecfg/registry/data/org/openoffice/Office/Addons.xcu instead of sw/uiconfig), and its controls need a special care to work. I have a fix for this part.

There is however a general problem with controls inside the overflow popup, as they don't get the focus, so it isn't possible to enter anything there (other than right click > Paste). It doesn't affect all platforms, so gtk2/gtk3 and macOS are affected, but not KDE or Windows. There is a similar behavior with the basic shapes popup, if you add a control there (e.g. the font name control). I have some idea how to fix that too, but need to find out how to overcome some unwanted side effects...
Comment 8 Commit Notification 2017-10-16 21:36:09 UTC
Maxim Monastirsky committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=616f21db9e50a77b0c02dfb123f871a742f46216

tdf#79657 Support add-on controls in the overflow toolbar

It will be available in 6.0.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.
Comment 9 Maxim Monastirsky 2017-10-16 21:40:34 UTC
The focus problem under gtk is still pending.
Comment 10 Commit Notification 2017-12-20 16:14:44 UTC
Maxim Monastirsky committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=861086a21449acb168e52e4eab606692200d2622

Related: tdf#79657 Different approach to disable the context menu

It will be available in 6.1.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.
Comment 11 Xisco Faulí 2018-01-22 11:00:20 UTC
A polite ping to Maxim Monastirsky: is this bug fixed? if so, could you
please close it as RESOLVED FIXED ? Thanks
Comment 12 Maxim Monastirsky 2018-01-25 21:47:32 UTC
(In reply to Xisco Faulí from comment #11)
> is this bug fixed?
No, see comment 9.
Comment 13 Xisco Faulí 2018-04-26 08:27:06 UTC
Dear Maxim Monastirsky,
This bug has been in ASSIGNED status for more than 3 months without any
activity. Resetting it to NEW.
Please assigned it back to yourself if you're still working on this.
Comment 14 QA Administrators 2019-04-27 02:51:33 UTC Comment hidden (obsolete)
Comment 15 QA Administrators 2021-04-27 03:34:23 UTC Comment hidden (obsolete)
Comment 16 QA Administrators 2023-04-29 03:29:37 UTC Comment hidden (obsolete)
Comment 17 QA Administrators 2025-04-29 03:10:03 UTC Comment hidden (obsolete)
Comment 18 Yousuf Philips (jay) (retired) 2025-11-23 12:49:32 UTC
The issue mentioned in comment 9 works fine in gen and gtk3 vcl backends, as well as windows 10. It doesn't work in kf5 vcl backend. Not sure what the situation is for osx.

Version: 25.8.3.2 (X86_64)
Build ID: 8ca8d55c161d602844f5428fa4b58097424e324e
CPU threads: 4; OS: Linux 6.11; UI render: default; VCL: kf5 (cairo+xcb)
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded