search

werererer / japokwm

A wlroots and dwl based tiling wayland compositor based around creating layouts
BSD 2-Clause "Simplified" License
142 stars 3 forks source link

Cannot open firefox or forks but chromium works #34

Closed Magnitudexx closed 2 years ago

Magnitudexx commented 2 years ago

when i try to run firefox or a fork of firefox it doesnt show the window although i can see the borders around it

werererer commented 2 years ago

I can't reproduce this issue. Have you tried the development branch? 0.4 is nearly finished and would be nice if you can test it there before the next big release. :). And can you tell me your output of firefox -v, japokwm -v?

Magnitudexx commented 2 years ago

japokwm version japokwm 0.3-80a634f (Dec 20 2021, branch 'master')and japokwm 0.3-99f82b59 (Dec 21 2021, branch 'development') firefox version Mozilla Firefox 95.0.1

werererer commented 2 years ago

You probably need to install xorg-xwayland if you are on archlinux or something similar so that it works. firefox doesn't run without it. Perhaps I need to mention it somewhere... Btw firefox probably didn't crash immediately because you have compiled japokwm with the support for xwayland(the default way). If that fixed it for you we can close this issue :).

Magnitudexx commented 2 years ago

Don't think that is the issue, i have xorg-xwayland installed but i am also running firefox native by exporting MOZ_ENABLE_WAYLAND="1 firefox"

werererer commented 2 years ago

I see I can reproduce it. I will look into it immediately

werererer commented 2 years ago

I'm working hard to find the issue. in the meantime try using it with MOZ_ENABLE_WAYLAND="0" and let it run on xwayland instead ;).

werererer commented 2 years ago

I found out that firefox uses xdg subsurfaces which are handled very poorly by this wm. I tried to copy the implementation from sway but failed... Anyways I finally heard about wlroots scene. Implementing that instead will fix a lot of issues this one included.

Magnitudexx commented 2 years ago

I'm interested in helping out with that

werererer commented 2 years ago

That sounds Amazing :D. I will push a fork of development and need to force reset it in a minute (I messed up some stuff xD). In there there is already some work from stuff that I already tried. To successfully implement wlr_scene you need to take reference of cage and tinywl when they where compatible with wlroots 0.15.0. If you are on archlinux you have to compile them yourself but wlroots 0.15.0 should release soon here.

firefox won't immediately work in wlr_scenes though but I opened an issue: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3350. So implementing wlr_scenes would fix this issue by the release of wlroots 0.16.0.

I have to fix my notifications btw sorry for answering so late ^^'.

Also let's continue work on wlr_scenes in #36.

werererer commented 2 years ago

I implemented enough of the wlr_scene api such that basic things work again. The work is currently on the wlr_scene branch and I will merge back when it is completed(it is currently rather unstable).

Here I tested it out: https://youtu.be/L_FW232hRoQ:

Note: you have to use wlroots(head) and compile it yourself because wlroots 0.15.0 had a bug where it didn't work.

werererer commented 2 years ago

Reopened because wlr_scene causes other problems. I have to find the root cause manually.

werererer commented 2 years ago

I did it :D. I forgot to send frame_done to subsurfaces of xdg_shell based programs in render.c. It works now in development :partying_face:. I will just clean up the code a bit. Oh and for everyone else who faces this issue. Firefox creates a surface that is just gray and then a subsurface which has the content. So if you don't handle subsurfaces at all only a gray window will appear.