Bug Hunting Session
Bug 98419 - severe UI regressions
Summary: severe UI regressions
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
5.1.1.1 rc
Hardware: All Linux (All)
: medium critical
Assignee: Not Assigned
URL:
Whiteboard: target:5.2.0 target:5.1.2
Keywords:
Depends on:
Blocks: 98724 98726
  Show dependency treegraph
 
Reported: 2016-03-04 15:19 UTC by Lionel Elie Mamane
Modified: 2016-10-25 19:08 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
"one partocular document" from point D (9.69 KB, application/vnd.oasis.opendocument.text)
2016-03-04 15:24 UTC, Lionel Elie Mamane
Details
screenshot of weird orange scrolling bar (33.51 KB, image/png)
2016-03-04 15:29 UTC, Lionel Elie Mamane
Details
my gtk2 dialog from basic, all ok for me (12.21 KB, image/png)
2016-03-10 10:50 UTC, Caolán McNamara
Details
my gtk3 dialog from basic, all ok for me (12.35 KB, image/png)
2016-03-10 10:50 UTC, Caolán McNamara
Details
too high msgbox (1.80 KB, image/png)
2016-03-17 09:50 UTC, Lionel Elie Mamane
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lionel Elie Mamane 2016-03-04 15:19:38 UTC
(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"
Comment 1 Lionel Elie Mamane 2016-03-04 15:24:03 UTC
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).
Comment 2 Lionel Elie Mamane 2016-03-04 15:24:52 UTC
Created attachment 123293 [details]
"one partocular document" from point D
Comment 3 Lionel Elie Mamane 2016-03-04 15:29:26 UTC
Created attachment 123294 [details]
screenshot of weird orange scrolling bar
Comment 4 V Stuart Foote 2016-03-04 20:12:01 UTC
@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?
Comment 5 Lionel Elie Mamane 2016-03-04 20:38:01 UTC
(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?
Comment 6 Caolán McNamara 2016-03-09 17:29:06 UTC
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 ?
Comment 7 Lionel Elie Mamane 2016-03-09 17:43:44 UTC
(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.
Comment 8 Commit Notification 2016-03-09 21:19:37 UTC
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.
Comment 9 Commit Notification 2016-03-10 10:45:19 UTC
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.
Comment 10 Caolán McNamara 2016-03-10 10:49:41 UTC
I know what the toolbar problem is and that should be fixed now (B).
Comment 11 Caolán McNamara 2016-03-10 10:50:08 UTC
Created attachment 123461 [details]
my gtk2 dialog from basic, all ok for me
Comment 12 Caolán McNamara 2016-03-10 10:50:35 UTC
Created attachment 123462 [details]
my gtk3 dialog from basic, all ok for me
Comment 13 Caolán McNamara 2016-03-10 11:06:30 UTC
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 ?
Comment 14 Caolán McNamara 2016-03-10 12:22:24 UTC
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
?
Comment 15 Lionel Elie Mamane 2016-03-10 14:08:03 UTC
(In reply to Caolán McNamara from comment #14)
> what's the output of
> gsettings get org.gnome.desktop.interface gtk-theme
> ?

'Adwaita'
Comment 16 Lionel Elie Mamane 2016-03-10 14:10:33 UTC
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.
Comment 17 Lionel Elie Mamane 2016-03-10 14:17:56 UTC
(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)
Comment 18 Lionel Elie Mamane 2016-03-10 14:18:31 UTC
(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.
Comment 19 Caolán McNamara 2016-03-10 14:56:51 UTC
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 ?
Comment 20 Lionel Elie Mamane 2016-03-10 15:16:55 UTC
(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.
Comment 21 Lionel Elie Mamane 2016-03-10 15:18:24 UTC
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.
Comment 22 Robinson Tryon (qubit) 2016-03-11 09:40:26 UTC
(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.
Comment 23 Caolán McNamara 2016-03-11 15:25:00 UTC
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 ?
Comment 24 Commit Notification 2016-03-14 18:54:36 UTC
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.
Comment 25 Commit Notification 2016-03-14 19:43:33 UTC
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.
Comment 26 Caolán McNamara 2016-03-17 09:23:26 UTC
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.
Comment 27 Lionel Elie Mamane 2016-03-17 09:49:53 UTC
(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.
Comment 28 Lionel Elie Mamane 2016-03-17 09:50:26 UTC
Created attachment 123655 [details]
too high msgbox
Comment 29 Lionel Elie Mamane 2016-03-17 09:54:07 UTC
(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.
Comment 30 Lionel Elie Mamane 2016-03-17 09:55:37 UTC
(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.