(severity critical if it happens for "many users") I run xfce4 on Debian GNU/Linux. On both my own debug build and the Debian package, the UI becomes seriously unsusable. I get the impression VCL chooses to use QT and not GTK (as I think it did before). Some examples: PROBLEM A (not too bad): from Basic, msgbox "foo" shows a dialog that is far too big for the text PROBLEM B 1) show a floating toolbar 2) put mouse pointer on title of toolbar 3) push left mouse button, don't release it 4) move mouse 5) release mouse button 6) move mouse again expected result: the toolbar is moved to the position of the mouse at step 5 and does not move during step 6. actual result: the toolbar follows the mouse during step 6. The mouse is grabbed and cannot be used to do anything else, such as e.g. use the LibreOffice menus, or open a terminal to type "killall soffice.bin"
Also: C - some scrolling bars are a weird blue-and-orange. D - when opening one particular Writer document, cannot open any menu in Writer. Menus in blank document work. If I use SAL_USE_VCLPLUGIN=gtk, a msgbox "foo" from Basic shows an empty dialog. The toolbar and menu problem does not happen (with GTK forced).
Created attachment 123293 [details] "one partocular document" from point D
Created attachment 123294 [details] screenshot of weird orange scrolling bar
@Lionel, * Can not confirm on Windows 8.1 Ent 64-bit en-US nor Windows 10 Pro 64-bit en-US with Version: 5.1.1.2 (x64) Build ID: fe4d9e69c82c6ee6db3c27cd5e2d47558afa80ac CPU Threads: 8; OS Version: Windows 6.29; UI Render: default; Locale: en-US (en_US) -- nor with 5.1.1.3 (x64) So, suspect this is xfce4 only... so isn't this "just" a gtk2/gtk3 issue?
(In reply to V Stuart Foote from comment #4) > Can not confirm on Windows (...) Yes, X11-specific (in terms of LibreOffice platforms, Linux-specific) is very probable :) Should have put it immediately. The question is: does it happen for more users, or is it somehow specific to my specific setup?
It sounds like you have a gtk3 enabled libreoffice (the default) on a machine with a fairly old gtk3 and so are getting glitches because of holes in the themeing for supporting older gtk3 versions. (The "orange" sounds like the debugging background color in a debugging build to indicate unpainted regions) You can test if export SAL_USE_VCLPLUGIN=gtk makes a difference. If it does, then waht is your gtk3 version ?
(In reply to Caolán McNamara from comment #6) > It sounds like you have a gtk3 enabled libreoffice (the default) on a > machine with a fairly old gtk3 and so are getting glitches because of holes > in the themeing for supporting older gtk3 versions. (The "orange" sounds > like the debugging background color in a debugging build to indicate > unpainted regions) > > You can test if export SAL_USE_VCLPLUGIN=gtk makes a difference. If it does, > then waht is your gtk3 version ? Yes, SAL_USE_VCLPLUGIN=gtk makes a difference, but also exhibits regressions, albeit less serious ones. See comment 1. I discovered that for problem B (when the toolbar gets stuck to the mouse which is grabbed), double-clicking often ungrabs the mouse and leaves the floating toolbar where it is. I discovered I had mostly GTK+3 version 3.18.8-1, but one package still 3.14.5-1+deb8u1, so I did: [UPGRADE] libgtk-3-bin:amd64 3.14.5-1+deb8u1 -> 3.18.8-1 [UPGRADE] libgtksourceview-3.0-1:amd64 3.14.1-1 -> 3.18.2-1 [UPGRADE] libgtksourceview-3.0-common:amd64 3.14.1-1 -> 3.18.2-1 the problems stay.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=380e5a98d2f20d77b8fc51bbea74f554dd24cdd1 Related: tdf#98419 use gtk_window_begin_move_drag bodge for wayland only It will be available in 5.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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=51d1fca2041ba4478c5abae59b1ed4fee37ea1ee Related: tdf#98419 gtk3: reimplement passing window move control to wm... It will be available in 5.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.
I know what the toolbar problem is and that should be fixed now (B).
Created attachment 123461 [details] my gtk2 dialog from basic, all ok for me
Created attachment 123462 [details] my gtk3 dialog from basic, all ok for me
For me under gtk2 and gtk3 the basic dialog is the same, no problems for me so I can't reproduce something to fix it. Obviously both are super wide to fit the debugging title in. But that's to be expected with a debugging build. i.e. an example of msgbox "foo", 0, "foo" will set a short replacement title. Is the "far too big" problem this "very wide cause of title" issue ?
wrt "C" orange in scrollbars I have an install with equal gtk version so if I can get your theme I can try and reproduce that and fix it seeing as its presumably unpainted part of scrollbar area. So what's the output of gsettings get org.gnome.desktop.interface gtk-theme ?
(In reply to Caolán McNamara from comment #14) > what's the output of > gsettings get org.gnome.desktop.interface gtk-theme > ? 'Adwaita'
I rebuilt with commit 380e5a98d2f20d77b8fc51bbea74f554dd24cdd1 Author: Caolán McNamara <caolanm@redhat.com> Date: Wed Mar 9 21:16:50 2016 +0000 Related: tdf#98419 use gtk_window_begin_move_drag bodge for wayland only Change-Id: Ica19aef9b94e0c11e014f48b7801ecb0c110c44b and the floating toolbar move problem does not happen anymore.
(In reply to Caolán McNamara from comment #11) > Created attachment 123461 [details] > my gtk2 dialog from basic, all ok for me (In reply to Caolán McNamara from comment #12) > Created attachment 123462 [details] > my gtk3 dialog from basic, all ok for me They are OK in master for me, too. The problem is in 5.1. The same for the orange scrolling bars: not reproducible in master. (But master has other problems that make it unusable for me... bug 98418)
(In reply to Lionel Elie Mamane from comment #16) > I rebuilt with > > commit 380e5a98d2f20d77b8fc51bbea74f554dd24cdd1 > Author: Caolán McNamara <caolanm@redhat.com> > Date: Wed Mar 9 21:16:50 2016 +0000 > > Related: tdf#98419 use gtk_window_begin_move_drag bodge for wayland only > > Change-Id: Ica19aef9b94e0c11e014f48b7801ecb0c110c44b > > > and the floating toolbar move problem does not happen anymore. For full clarity, that was in master.
https://gerrit.libreoffice.org/23121 for 5-1 dialog size problem backport I believe wrt, C, Adwaita theme, odd I have the same and I don't have arrows in my scrollbars. Does gedit also have arrows in its scrollbars ?
(In reply to Caolán McNamara from comment #19) > https://gerrit.libreoffice.org/23121 for 5-1 dialog size problem backport I > believe > wrt, C, Adwaita theme, odd I have the same and I don't have arrows in my > scrollbars. Does gedit also have arrows in its scrollbars ? Installed gedit. Yes scrollbars have arrowheads (shapes like < and >) at the end, but are not orange (but blue and gray). For full clarity, the red arrows pointing to some areas of the scrollbars on my screenshot are hand-drawn by me to point to the problem areas.
Hmm... In gedit, when creating a new tab or closing one, I sometimes get a problem akin to the floating toolbar problem, but less serious: a single click stops it.
(In reply to Commit Notification from comment #8) > Caolán McNamara committed a patch related to this issue. > It has been pushed to "master": Looks like actual work is being done on this bug, so I'm moving it out of UNCONFIRMED -> NEW.
A and B have fixes in the 5-1 queue C The orange is almost certainly coming from... 5.1 vcl/unx/gtk3/gtk3gtkframe.cxx #if OSL_DEBUG_LEVEL > 0 // set background to orange m_aFrame->clear( basebmp::Color( 255, 127, 0 ) ); #endif which sets the bg to orange and expects that it gets overpainted so that any orange visible is a bug. I however can't reproduce a situation where I get such orange portions in a debugging 5-1. "some scrolling bars are a weird blue-and-orange" suggests that not all have this problem, is this the case ? Only some situations show the orange ? D Not a clue, works fine for me. Is it a menubar that has entries but doesn't show the menus when clicked on or what sort of breakage do you get ?
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1f061d64989f74ea517f9e4951fc856211e7d9f0&h=libreoffice-5-1 Related: tdf#98419 set a min size on un-resizeable non-layout dialogs It will be available in 5.1.2. 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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fe0d47bc77742ba830e07d036e4fef8154f8a185&h=libreoffice-5-1 Related: tdf#98419 use gtk_window_begin_move_drag bodge for wayland only It will be available in 5.1.2. 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.
I'm going to close this. I know there are two outstanding issues, but I can't reproduce them and its a bit of a mess by now. If you still have the other two issues I suggest filing a new report for each. (and try non dbgutil mode (or hack out the line I mentioned above) to see if the orange goes away and what remains looks ok, or if the orange is replaced by e.g. solid white/black where it shouldn't be.
(In reply to Caolán McNamara from comment #13) > For me under gtk2 and gtk3 the basic dialog is the same, no problems for me > so I can't reproduce something to fix it. Obviously both are super wide to > fit the debugging title in. But that's to be expected with a debugging > build. i.e. an example of > msgbox "foo", 0, "foo" > will set a short replacement title. Is the "far too big" problem this "very > wide cause of title" issue ? No. The dialog is too _high_, and also in a non-debug build (the Debian package). But you fixed it now.
Created attachment 123655 [details] too high msgbox
(In reply to Caolán McNamara from comment #23) > D Not a clue, works fine for me. Is it a menubar that has entries but > doesn't show the menus when clicked on or what sort of breakage do you get ? I get it only in this specific document (attachment 123293 [details]). The menu "flashes" in that it very briefly opens and immediately closes. Even if I leave my mouse button pushed, the menu immediately closes.
(In reply to Caolán McNamara from comment #26) > I'm going to close this. I know there are two outstanding issues, but I > can't reproduce them and its a bit of a mess by now. If you still have the > other two issues I suggest filing a new report for each. Fair enough. Will do that.