Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XWayland Firefox and GTK2 tooltips/menus etc. take up half the screen, like normal windows #46

Open
WLCIssuesBot opened this issue May 3, 2017 · 16 comments
Labels

Comments

@WLCIssuesBot
Copy link
Collaborator

Issue by robotanarchy
Tuesday Jan 05, 2016 at 14:54 GMT
Originally opened as Cloudef/wlc#104


This screenshot describes it best:

Screenshot

Happens to Firefox, Geany, Roxterm tooltips and menus. Also the autocompletion bar ("Awesome Bar") in Firefox.

I'm running sway on Void Linux with musl libc.

I've tried to fix this in Cloudef/wlc#102, but it turns out that it was a coincidence that it suddenly worked and it didn't really fix it.

So to fix this, we'll need more information.

Who else does have this issue?

  • Which compositor do you run? (sway or orbment?)
  • Which Linux distribution do you run?
  • How did you compile wlc?
@WLCIssuesBot
Copy link
Collaborator Author

Comment by crondog
Wednesday Jan 06, 2016 at 11:09 GMT


Hmm so with FF 43.0.1-2 I do not get this issue. However I get a similar issue with texstudio (qt) with menus

This is with Arch and sway/orbment compiled with cmake . -DCMAKE_BUILD_TYPE=Debug and Release

@WLCIssuesBot
Copy link
Collaborator Author

Comment by robotanarchy
Wednesday Jan 06, 2016 at 12:01 GMT


From the #sway IRC channel:

zotek:

I had this issue on very old wlc/sway
Gentoo, wayland 1.7 at the time

TheRealJohnGalt (who has the same issue currently):

I'm running sway on voidlinux glibc, built with your overlay

@WLCIssuesBot
Copy link
Collaborator Author

Comment by robotanarchy
Wednesday Jan 06, 2016 at 13:02 GMT


@Cloudef : Do you have an idea, how we can debug this issue?

@WLCIssuesBot
Copy link
Collaborator Author

Comment by Cloudef
Wednesday Jan 06, 2016 at 19:30 GMT


It's most likely issue with atoms prop being set after window creation. So the window creation to for wlc needs to be delayed until we have got the initial atoms. Otherwise the window will be created as if it was normal window.

The information here is all I know I'm afraid Cloudef/wlc#102 (comment)

@WLCIssuesBot
Copy link
Collaborator Author

Comment by Cloudef
Wednesday Jan 06, 2016 at 19:40 GMT


It might also be issue with invalid calling convetion as the stuff for x11/xcb and few others in wlc still use weak linking. See: Cloudef/wlc#46

@WLCIssuesBot
Copy link
Collaborator Author

Comment by robotanarchy
Thursday Jan 07, 2016 at 22:20 GMT


@Cloudef: I have another idea, where this issue could be from: Could it be that Firefox re-uses its windows and wlc deletes them once they are hidden?

I'll debug this further, but that is what I currently think is responsible.

I can pretty much reproduce this:

  • Open Firefox
  • First, a tooltip gets displayed fine
  • Second time, the tooltip just doesn't show up
  • Third time (and all following), it looks like on the screenshot.
  • When restarting Firefox, the first tooltip is normal again etc.

@WLCIssuesBot
Copy link
Collaborator Author

Comment by robotanarchy
Saturday Jan 09, 2016 at 00:17 GMT


Here are some logfiles to undermine my theory. Basically they contain the output of xwininfo -tree -root and then xprop -id on every window (full log script).

I ran it after opening firefox, and then for the first 3 times while the tooltip should be displayed, moving the mouse away between each log file. Behavior is exactly like described in my post above (displays fine, is invisible, is tiling like on the screenshot).

The logfiles can be diffed easily to find changes between the windows, and as far as I can tell the window ID is always the same (0x10008bd "Close tab (Ctrl+W)": ("Popup" "Firefox")).

(I also had a roxterm open, don't mind that).

Logfiles: https://robotanarchy.space/debugging_firefox.tar.gz

@WLCIssuesBot
Copy link
Collaborator Author

Comment by Cloudef
Thursday Jan 14, 2016 at 07:59 GMT


Window reuse is not uncommon in X11. Each time window is unmapped in X11 on wlc side the view is destroyed due to the surface being destroyed on Xwayland side as well. Once they are mapped back the view is created again. I'll debug this more myself as well in near future (tm). The #46 might be worth fixing as well, as anything can happen if the weak linked function prototypes are wrong.

@WLCIssuesBot
Copy link
Collaborator Author

Comment by zetok
Sunday Jan 17, 2016 at 17:45 GMT


So, I still have this issue, with both chromium and ff on newest sway/wlc. Just so you know.

@WLCIssuesBot
Copy link
Collaborator Author

Comment by robotanarchy
Sunday Apr 03, 2016 at 09:56 GMT


I didn't find the time to do this yet, but after @Cloudef debugged this issue with me for some hours and we didn't get anywhere, he recommended the following:

yeah just bisect, there aren't many commits. Just the set that touches xwm, I think I included xwm: in the commit message for each

... so maybe someone else, who is affected, may try to bisect the code and find where the bug was introduced.

@WLCIssuesBot
Copy link
Collaborator Author

Comment by PluMGMK
Sunday Apr 03, 2016 at 10:49 GMT


Actually I haven't had this issue in a long time. The suggestions from typing in the location bar in Firefox flash and have trouble resizing, but I don't know if that's a separate issue.

@WLCIssuesBot
Copy link
Collaborator Author

Comment by aereaux
Sunday Apr 17, 2016 at 20:53 GMT


I still have this issue with tooltips and dropdowns only being shown once (I've specifically been testing with Xfe, but it should be reproducible with firefox and other things). I've figured out that using the current git master, the issue appears when running cmake with -DCMAKE_BUILD_TYPE=Release, and doesn't appear when running cmake with -DCMAKE_BUILD_TYPE=Upstream. I'm going to try to bisect using -DCMAKE_BUILD_TYPE=Release as soon as I get the chance.

@WLCIssuesBot
Copy link
Collaborator Author

Comment by Cloudef
Monday Apr 18, 2016 at 13:48 GMT


Release / Upstream change would indicate there is still race condition going somewhere here hmm..

@WLCIssuesBot
Copy link
Collaborator Author

Comment by ids1024
Sunday Apr 24, 2016 at 22:14 GMT


I seem to be having this problem with qutebrowser, which is running natively without xwayland. Chromium, on the other hand, seems to work fine (in xwayland).

This is with the latest git of wlc and sway.

@WLCIssuesBot
Copy link
Collaborator Author

Comment by PluMGMK
Sunday Apr 24, 2016 at 22:30 GMT


@ids1024 Yep, same thing with Otter Browser now that you mention it. QtWayland actually seems to have a lot of problems on wlc/sway…

@WLCIssuesBot
Copy link
Collaborator Author

Comment by t0b1nux
Friday Jul 01, 2016 at 10:59 GMT


With regard to the new status of swaywm/sway#571, do you still experience theses problems with latest version of wlc ? (for my part, I don't)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant