Bug 1626757 - xfce4-panel vs. gtk3 changes cause .xession-errors to fill up in hours
Summary: xfce4-panel vs. gtk3 changes cause .xession-errors to fill up in hours
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: garcon
Version: 29
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Mukundan Ragavan
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-09-08 09:39 UTC by Ali Akcaagac
Modified: 2019-07-17 14:16 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-07-17 14:16:26 UTC


Attachments (Terms of Use)
xsession-error file (93.44 KB, application/x-bzip)
2018-09-08 09:39 UTC, Ali Akcaagac
no flags Details
xsession-error 2 (4.92 KB, application/x-bzip)
2018-09-08 10:39 UTC, Ali Akcaagac
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1624292 None CLOSED Icons in Xfce menu are absurdly big 2019-07-17 14:15:33 UTC

Internal Links: 1624292

Description Ali Akcaagac 2018-09-08 09:39:25 UTC
Created attachment 1481724 [details]
xsession-error file

Somehow the recent changes of Gtk+ causes xfce4-panel to issue gtk-warnings when undersized icons (whatever that means) are used.

For example:
My Panel has a height of 24 pixel and a length of 100% of the notebook screen. Basicly a top bar that is 24 pixel height. As I've been using it for the past - however long that is (years and more).

With recent updates of Gtk+, somehow I noticed that my .xession-errors file is getting huge in a short timeframe. Within 2-3 hours of using Xfce4, the file exceeds 8mb and more.

Looking inside the file gives informations that somehow the panel tries to wrap an icon in 24x24 pixel, while Gtk+ demands 24x28 as the smallest possible icon type of thing. For some icons I get minimal size possible of 43x26 and so on.

I will attach the entire .xsession-errors file here, so this can be reviewed. I don't bother getting these messages, because xfce4-panel shows everything correctly. What bothers me is, that the error file is constantly growing in a short timeframe.

I can basicly enter:

watch -t -n 1 ls -l ~/.xsession-errors

and see how it grows...

Comment 1 Ali Akcaagac 2018-09-08 09:39:55 UTC
And yes... All Fedora packages :)

Fedora 29 x86_64

Comment 2 Raphael Groner 2018-09-08 10:05:25 UTC
We see a similiar bug #1624292 with too large icons. Maybe try to reproduce with latest update for garcon:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-c4f721db41

Comment 3 Ali Akcaagac 2018-09-08 10:39:13 UTC
No this is *not* a garcon issue!

Excursion:
I was using Xfce 4.13 since beginning under Fedora 27(28. Compiled everything from sources back that time. I was aware of the garcon issue, since the developers changed code that reflects the visual presentation of icons. This was a known issue and got also reported by me to the b.x.o.

https://bugzilla.xfce.org/show_bug.cgi?id=13593

I was told by the maintainer, that they changed code in garcon, that affected the visual representation of icons (repeating myself here).

But this issue has never been an issue for me because the icons i've been using had all a uniform size (changed icon set).

Until recently I was using Xfce4 from git because of testing, reporting and fixing issues.

Now that Fedora changed to Xfce4 4.13 I ended up using the legitimate packages that come from Fedora. I've also been using Fedora 29 beginning 1 or 2 weeks before the actual branch to Fedora 29 happened. Till then I haven't noticed any increasing .xsession-error logs. They've always been around a few kb's.

But around 1 or 2 weeks ago things changed (after some gtk3 update came in). And the logs keep filling up here.

To make it short:
I just downloaded the garcon update and rebooted. Same issue. Logs filling up. Please find atached a new log with same output.

The warnings are thrown out by Gtk3 and not by Garcon or the Panel.

What I believe is this: Something has changed in Gtk3, that causes this. Or with other words: The Gtk3 that has been updated recently, is too new for Xfce4. Causing some incompatibilities. But as said. I'm just speculating here.

Comment 4 Ali Akcaagac 2018-09-08 10:39:44 UTC
Created attachment 1481772 [details]
xsession-error 2

Comment 5 Ali Akcaagac 2018-09-08 11:23:55 UTC
I think I was able to isolate even more.

Howto reproduce:

1) Start a fresh Xfce4 session
2) Set a top panel with a row height of 24 pixel

Done...

Explaination (spekulative):

1) The panel is set with a row height of 24 pixels
2) This enforces the items inside it to be below 24 pixels. Normally I would say the icons, applets etc are around 20 - 22 pixels
3) This causes the .xsession-error to get filled up instantly
4) Even opening the defaul application launcher (not whiskermenu) but the normal menu, then you can see how .xsession-error increases by 20-50kb in one action

This happens less, if I increase the top panel's row height to say 28 or 32 pixel.

So basicly x < 24 is an issue.

I just set the panel row height to 16 pixels (the lowest possible) and one access to the application menu increased .xsession-error by over 200kb in size

Comment 6 Ali Akcaagac 2018-09-08 11:35:41 UTC
I forgot to mention this:

1) I just reinstalled all of xfce4 from rpm. This includes applications, libraries, garcon, exo, *xfce4*, Thunar etc. to ensure the packages are all up to date, complete and from Fedora.

2) I also like to mention that - when I was still using Fedora 27/28 and when I started using Xfce4 Git (over 1.5 years ago), that this kind of *filling* issue didn't exist. I generated rpm packages from Xfce4 Git based upon Fedoras *.spec files.

Besides the *garcon* thing, I never had any issues. Problems started with Fedora 29.

Currently I am struggling 3 issues:

1) Lightdm-gtk sometimes doesn't load up, dropping me back to console. Have to issue systemctl restart lightdm (restart, because the first instance died). No it's not the dbus issue.

2) Xfwm4 composite (the one that received some backports a few days ago). Causes heavy flickering and blinking here. Sometimes Xfwm4 simplies dies a horrible dead, respawns a couple of times until it dies. Disabling composite (as nonamedoc did) solved the issues (temporarely). This never happened with Fedora 27/28. With Fedora 29 this is an massive issue. It's not just blinking (sometimes) it can also kill off all interaction. Sometimes you can't switch to a console to issue an reboot.

3) The .xsession-error filling issue. Never happened with Fedora 27/28.

I wonder what happens, if the announced *GNOME 3 MegaUpdate* will cause to Xfce4. Will things still be compatible ?

Comment 7 Raphael Groner 2018-09-08 11:36:36 UTC
> No this is *not* a garcon issue!

What else then to blame? garcon is the general (core) library for rendering.

Upstream sees indeed some issues with gtk3 and scaling of icons in gdk-pixbuf, as already mentioned in the other downstream bug #1624292.
https://bugzilla.gnome.org/show_bug.cgi?id=686514

Comment 8 Raphael Groner 2018-09-08 11:44:56 UTC
(In reply to Ali Akcaagac from comment #6)
> I forgot to mention this:

Please don't confuse several issues. You should open another bug for each issue.

<snip>
> Currently I am struggling 3 issues:
> 
> 1) Lightdm-gtk sometimes doesn't load up, dropping me back to console. Have
> to issue systemctl restart lightdm (restart, because the first instance
> died). No it's not the dbus issue.

Confirmed. For me, the general boot process takes a long time till lightdm-gtk shows its login screen. I'm still investigating what component to blame. Maybe it's due to recent general system changes done with dbus-broker. Again, this is a different issue and should get discussed in a separate bug.

> 2) Xfwm4 composite (the one that received some backports a few days ago).
> Causes heavy flickering and blinking here. Sometimes Xfwm4 simplies dies a
> horrible dead, respawns a couple of times until it dies. Disabling composite
> (as nonamedoc did) solved the issues (temporarely). This never happened with
> Fedora 27/28. With Fedora 29 this is an massive issue. It's not just
> blinking (sometimes) it can also kill off all interaction. Sometimes you
> can't switch to a console to issue an reboot.

That should be fixed with another update. Please check if you've applied everything of updates-testing. Notice that F29 is still not declared as stable.

> 3) The .xsession-error filling issue. Never happened with Fedora 27/28.

See above.

> I wonder what happens, if the announced *GNOME 3 MegaUpdate* will cause to
> Xfce4. Will things still be compatible ?

Well, we'll see what happens. Integration testing is not easy and as said, F29 is not announced yet as stable.

Thanks for testing and your feedback.

Comment 9 Ali Akcaagac 2018-09-08 11:52:21 UTC
(In reply to Raphael Groner from comment #7)
> > No this is *not* a garcon issue!
> 
> What else then to blame? garcon is the general (core) library for rendering.

I understand this theory. Still I am wondering why my .xsession-error never received 8mb in size within a few hours of usage before. And before I was using Xfce4 Git (entirely Gtk3 enabled) on Fedora 27/28. The garcon issue with big icons as shown in the screenshots of #1624292 was known to me but never caused .xsession-error to increase that massively. I need to check whether verbosity or debugging got enabled in one of the spec files along the chain. That may explain this situation and could also be a normal thing for a beta release. So people can report better on bugs etc...

Comment 10 Mukundan Ragavan 2018-09-08 15:47:01 UTC
(In reply to Raphael Groner from comment #8)
> 
> Confirmed. For me, the general boot process takes a long time till
> lightdm-gtk shows its login screen. I'm still investigating what component
> to blame. Maybe it's due to recent general system changes done with
> dbus-broker. Again, this is a different issue and should get discussed in a
> separate bug.
> 
that's SELinux.

https://bugzilla.redhat.com/show_bug.cgi?id=1625218

Comment 11 Ali Akcaagac 2019-07-17 14:16:26 UTC
Issues are gone, therefore closing the bug.


Note You need to log in before you can comment on or make changes to this bug.