Wayland compositor does not work with Firefox #3115
Comments
|
Same thing happens for me on rawhide. However the version is still 0.15.2. I will try 1.0.0 beta when I have time. Everything seems to work in gnome and weston. |
|
Hi, thanks for reaching out! You might want to first try in rootston (wlroots' reference compositor). I just tried the latest Flatpak nightly and it works there (!). There are performance issues though. I also noticed you create a lot of I'll try to see why it doesn't work in sway master. |
|
I can reproduce problems on fedora 29 with firefox 63 and sway 1.0.0 beta 1. It's way closer than it was last time I checked. It actually runs and you can kind of use it. But scrolling is choppy and certain context menus will crash it. To crash it: Launch |
The address bar crash has been fixed in Firefox 65. |
|
Just curious (maybe not releated) but there are still bugs on mixed dpi multimonitor setup? |
This sounds like a Xwayland-related bug (which has been fixed). We're talking about the Wayland version here. |
|
I think I used wayland version, but I'm not sure. And it was not only me, there are other people who have bugs on mixed dpi multimonitor setup: |
The same with sway 1.0 beta...
...similar thing reported at b.m.o: https://bugzilla.mozilla.org/show_bug.cgi?id=1493493
Quick shot COPR build for Rawhide: |
|
Firefox-nightly 65.0a1 does not even launch for me with |
|
Firefox nightly 65.0a1 still has the browser bar crash. It seems to perform in an identical fashion to firefox 63, including the same error message output and performance issues. |
|
I tried the hg master of firefox, wlroots and sway. And I'm observing the same behavior as @JonnyMako. But I also tried to start firefox in weston, and it appears to be starting to be okay. I'm not quite sure how to debug this issue. Any help to debug this further would be appreciated here. |
|
@JonnyMako I was seeing the same |
|
@stransky: just merged a patch that prevents Firefox crashes in wlroots. Now I'm able to run it as long as I don't copy something (the patch for this second crash is pending). However…
I'm unable to reproduce this. Can you make sure you're running the latest sway and wlroots commits? Note that even if it works, it's very slow. That might be due to the fact Firefox creates ~50 (In both Sway and Weston, Firefox uses |
Further note that it gets slower with every key stroke, until it just freezes. Additionally, for non-us keyboard layouts, modifier keys don't work. (I filed a bug about this on mozilla). |
Can you please provide a firefox backtrace where the wl_keyboard objects are created? I'm not aware of that at Firefox code. Thanks. |
|
I see only this place - so is the wl_seat send multiple times? |
|
Here are a few backtraces (fedora firefox-63.0.3-1.fc29.x86_64 package): associated WAYLAND_DEBUG log always looks like: It seems to happen pretty much all the time: when focus changes (window enter), when you focus a field where keyboard can be used, etc... |
|
Thanks, it should be handled by https://bugzilla.mozilla.org/show_bug.cgi?id=1507475 |
|
phabricator link of the same: https://phabricator.services.mozilla.com/D12255 (more direct for people like me) Haven't looked at the code in details but yes I believe this should help; not listing all global registries everytime you need something is the way to go! :) |
|
I downloaded a build with the patch for bug 1507475 from autoland (direct link linux x64 pgo) and can confirm that Firefox runs far more smoothly now on latest sway-git/wlroots-git. edit: modifier keys also work smoothly now and don't get lost under load as before. |
|
Firefox is not just usable but fast and stable using the build in #3115 (comment) (previous comment) and the wlroots fix in swaywm/wlroots#1384. |
|
Thanks for the confirmation, I'll backport the wl_keyboard part of the patch to Fedora Firefox package. |
|
Great! Firefox with wayland backend is working well enough for me to switch to using it by default! A couple of minor issues:
|
Does scrolling the page underneath the menu fix it? |
Yes, scrolling gets rid of the context menu. The issue is not limited to context menus though. The menus in the menu bar are drawn over each other. So if I select File menu followed by Edit menu, then Edit menu is drawn over the still seemingly open File menu. All menus are reset when cursor is moved over the webpage area. |
|
This one is likely a sway bug. Can you open a separate issue about it? |
Will do. Also, in newer firefox-nightly wayland, selecting and copying any text from webpage crashes firefox. I still run into the problem with firefox not starting up if clipboard has content. I suspect these are related. |
|
You need to use swaywm/wlroots#1384. |
Gotcha. Thanks. |
Can you please provide a backtrace of the crash? I'd like to fix that. Thanks. |
|
Also auto updating nightly sometimes crashes Sway. |
Please submit stack traces ( |
|
|
Thanks, looks like it. FWIW, non-trivial Wayland clients should always use |
|
@stransky Another thing our users reported is that sometimes menus are off-screen and/or hidden. This happens because you use subsurfaces instead of xdg-popups. Subsurfaces spanning outside of the window geometry have no guarantee to be visible, whereas xdg-popups will be more cleverly displayed by the compositor. |
|
|
I'm seeing lots of crashes in nightly builds starting yesterday. Just opening a new tab and typing into url field seems to crash firefox, for example. Anyone else seeing frequent crashes? |
|
Yes. Since yesterday I believe.
Den fre 7 dec. 2018 17:35JonnyMako <[email protected]> skrev:
… I'm seeing lots of crashes in nightly builds starting yesterday. Just
opening a new tab and typing into url field seems to crash firefox, for
example. Anyone else seeing frequent crashes?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#3115 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AABurA5Kx_7zZBJqnNTbW56hdSv4gvOuks5u2pi0gaJpZM4YZw7u>
.
|
|
Is the Flatpak fixed? I just installed it and it still has this issue. Running on Kubuntu 18.10. |
|
You don't need that flatpak any more to test wayland builds. |
I think it's https://bugzilla.mozilla.org/show_bug.cgi?id=1423598 |
|
I have an issue with |
|
@ojab I have this issue as well, and it's not just tab switching but the Alt key behaviour at large. I can't even Alt+Left/Right arrow to navigate pages. |
|
I've got a similar issues today with Firefox on fedora 29 with the latest patches of both: it crashes frequently and gives other browser issues. But Chrome crashed as well just now, so not sure what to think of it... |
|
The problems I see with Firefox 65 (running as native wayland application) in sway-1.0-rc1:
|
|
@eternal-sorrow Your 1. and 2. have probably the same cause as #3561, firefox blocking while it isn't rendered on screen. Telegram might have the same problem. |
|
@eternal-sorrow is 3 similar to #3055? |
It kind of is, as far as I can see, referenced issue happens after firefox startup, also it's probably related to firefox on Xwayland. My problem happens only with native firefox wayland application. Also it happens in very strange circumstances (I still can't reliably reproduce it). |
Happening to me too with Fedora 29, Sway & wlroots master and Firefox 66 Beta. |
|
@trobjo @firat with GDK_BACKEND set to wayland and running firefox, switching tty's (1 -> 2 -> 1) will temporarily fix the alt + [1,9] tab navigation. |
|
I'm currently using Firefox Nightly and it seems all issues have been fixed |
|
Any remaining issues are probably firefox problems. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
and others
Hello,
I work on Firefox Wayland port and I'm having an issues with Wayland Firefox on Sway compositor. Mouse cursor is not shown, popup menus are not shown and the browser does not response to uset input.
KDE/Kwim (https://bugs.kde.org/show_bug.cgi?id=397834) have similar problems. It can be caused by wl_subsurface which is attached as an overlay of wl_surface owned by main Firefox toplevel GtkWindow.
You can check Firefox on Wayland by 3 ways:
ac_add_options --enable-default-toolkit=cairo-gtk3-wayland
and run as GDK_BACKEND=wayland ./firefox
Please let me know if I can help.
The text was updated successfully, but these errors were encountered: