Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1755029
Summary: | firefox-wayland: do not start with fullscreen | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Thomas Köller <thomas> | ||||||
Component: | weston | Assignee: | Richard Hughes <rhughes> | ||||||
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | unspecified | Docs Contact: | |||||||
Priority: | low | ||||||||
Version: | 31 | CC: | 0xalen+redhat, anto.trande, gecko-bugs-nobody, gp, jhorak, john.j5live, kengert, negativo17, pjasicek, rhughes, rstrode, sandmann, stransky | ||||||
Target Milestone: | --- | Keywords: | Reopened | ||||||
Target Release: | --- | ||||||||
Hardware: | x86_64 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2020-11-24 20:16:44 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 1054334 | ||||||||
Attachments: |
|
I tested that with mutter (mutter --wayland --nested &) and works for me, firefox uses wayland-1 display. Not sure why weston does not work. The same from me: I nested weston in a weston session. In the second (nested) weston I opened a terminal window and checked the WAYLAND_DISPLAY variable and it have had the value wayland-1. By an another test I executed: root # groupadd weston-launch root # usermod -a -G weston-launch $USER 1. Run a Gnome Wayland session. (Logged in from gdm) 2. Switched to a virtual terminal (Ctrl-Alt-F3) 3. On the virtual terminal run weston-launch 4. On the weston session opened a terminal window and get wayland-1 as the value of the WAYLAND_DISPLAY variable Could I close this ticket? (In reply to Gerd Pokorra from comment #2) > The same from me: > > I nested weston in a weston session. In the second (nested) weston I opened > a terminal window and checked the WAYLAND_DISPLAY variable and it have had > the value wayland-1. > > > By an another test I executed: > > root # groupadd weston-launch > root # usermod -a -G weston-launch $USER > > 1. Run a Gnome Wayland session. (Logged in from gdm) > 2. Switched to a virtual terminal (Ctrl-Alt-F3) > 3. On the virtual terminal run weston-launch > 4. On the weston session opened a terminal window and get wayland-1 as the > value of the WAYLAND_DISPLAY variable > > > Could I close this ticket? That is somewhat beside the point - I did not claim that WAYLAND_DISPLAY is set incorrectly. Its value is 'wayland-1' also for me, but firefox-wayland appears to ignore it and to use 'wayland-0' instead. (In reply to Martin Stransky from comment #1) > I tested that with mutter (mutter --wayland --nested &) and works for me, > firefox uses wayland-1 display. Not sure why weston does not work. Are you sure that you used firefox-wayland and not firefox X11 under Xwayland? One good way to make sure this is not the case might be to make sure the DISPLAY variable is unset. I do not know about mutter, so it may be a good idea to try to replicate my test case exactly by creating the very setup I described. I really think that the problem is with firefox-wayland (which is why I reported it as a firefox bug), not with wayland/weston/whatever, as other applications seem to honor WAYLAND_DISPLAY correctly. Can you please try your scenario with mutter compositor as I wrote at comment 1 ? (In reply to Martin Stransky from comment #5) > Can you please try your scenario with mutter compositor as I wrote at > comment 1 ? As I said, I do not know about mutter. Its manpage says, "mutter is a minimal X window manager ...". So I would conclude that this is not the kind of plain-wayland-no-x11 setup that weston gives me, and where I see the problem with firefox-wayland. If mutter really creates a new wayland display separate from the one it was started from, then how do I go about starting firefox-wayland on that display? I really would wish for someone bothering to try my setup, which really is not all that difficult ... If I start a weston session with the weston-launch the firefox-wayland window appears in the weston session. When I execute 'mutter --wayland --nested &' in a Gnome session I get a blue window but I can not start anything there. (In reply to Gerd Pokorra from comment #7) > If I start a weston session with the weston-launch the firefox-wayland > window appears in the weston session. > > When I execute 'mutter --wayland --nested &' in a Gnome session I get a blue > window but I can not start anything there. Same thing here. > I nested weston in a weston session. In the second (nested) weston I opened
> a terminal window and checked the WAYLAND_DISPLAY variable and it have had
> the value wayland-1.
I tried opening a recursive weston session, too. The window opens, but I cannot control anything inside, as the mouse does not work. But that is a different topic ...
This is not what I mean with a weston nested in a weston. It is without GNOME. The first weston I started direct from the chooser of gdm. I thought starting the firefox-wayland window in a weston session in that what you wanted to do and this works with the way over the weston-launch program. (In reply to Gerd Pokorra from comment #10) > This is not what I mean with a weston nested in a weston. It is without > GNOME. The first weston I started direct from the chooser of gdm. > > I thought starting the firefox-wayland window in a weston session in that > what you wanted to do and this works with the way over the weston-launch > program. I did some more experimentation, and this is what I found: If there is an active gnome session on wayland-0, and an instance of firefox-wayland is running in that session (let's call this case #1), then if firefox-wayland is started from a weston session on wayland-1, it will open its window on wayland-0, the gnome session. This is the behavior I described so far. If there is a gnome session on wayland-0, and an instance of firefox-wayland is _not_ running in that session (case #2a), or if there is no session on wayland-0 at all (case #2b), then if firefox-wayland is started from a weston session, it fails to start entirely, like so: case #2a: --------- [thomas@sarkovy ~]$ echo $WAYLAND_DISPLAY wayland-1 [thomas@sarkovy ~]$ unset DISPLAY [thomas@sarkovy ~]$ firefox-wayland Gdk-Message: 23:59:31.057: Error 71 (Protocol error) dispatching to Wayland disp lay. Exiting due to channel error. [thomas@sarkovy ~]$ [Child 5154, Chrome_ChildThread] WARNING: pipe error: Broken pipe: file /builddir/build/BUILD/firefox-69.0.1/ipc/chromium/src/chrome/common/ ipc_channel_posix.cc, line 728 ###!!! [Child][MessageChannel] Error: (msgtype=0xFFF7,name=<unknown IPC msg name >) Channel error: cannot send/recv case #2b: --------- [thomas@sarkovy ~]$ echo $WAYLAND_DISPLAY wayland-0 [thomas@sarkovy ~]$ unset DISPLAY [thomas@sarkovy ~]$ firefox-wayland Gdk-Message: 23:55:05.428: Error flushing display: Broken pipe Exiting due to channel error. Since I have configured firefox with multiple profiles, the profile selection dialog is displayed in cases #2a and #2b, but not in case #1. That dialog is opened on the weston display, as it is supposed to. Not displaying the profile selection dialog is also the behavior I get when opening a second firefox-wayland window in a gnome session. So, what I would conclude from this is that in case #1 the firefox-wayland instance started from the weston session detects the presence of an already running instance on wayland-0 and opens a new window there. Why it fails to start entirely in cases #2a and #2b I do not know. Ah I see. What you see is Firefox xremote service. When Firefox is already running any new firefox call will connect to the active FF instance. You can suppress that by -no-remote argument and you also need to use different profile by -P parameter. (In reply to Martin Stransky from comment #12) > Ah I see. What you see is Firefox xremote service. When Firefox is already > running any new firefox call will connect to the active FF instance. You can > suppress that by -no-remote argument and you also need to use different > profile by -P parameter. O.k., if this is so, that explains it. But opening the new window on a display other than the one firefox-wayland was invoked from is unexpected and confusing to the user; it certainly confused me. So what about case #2, where firefox refuses to start at all? I expect that you are sitting at a PC where the Workstation Edition of Fedora 30 is installed. There you have installed (dnf install weston) on top weston. By default in this case after booting gdm (GNOME Display Manager) will be executed. The weston package includes the file /usr/share/wayland-sessions/weston.desktop. When this file is installed you can choose before the login if you want to start a GNOME or Weston session. The second case describe step by step how to start a weston session at a second display when you have already started a GNOME session. root # groupadd weston-launch root # usermod -a -G weston-launch $USER (replace $USER with your username) 1. Run a Gnome Wayland session. (Logged in from gdm) 2. Switched to a virtual terminal (Ctrl-Alt-F3) 3. On the virtual terminal run weston-launch 4. Now executing 'firefox-wayland -no-remote' starts a window in the weston session In both cases you can put this lines ## button for firefox [launcher] icon=/usr/share/icons/hicolor/24x24/apps/firefox.png path=/usr/bin/firefox-wayland in the file ~/.config/weston.ini to get a launcher for firefox. (In reply to Gerd Pokorra from comment #14) > root # groupadd weston-launch > root # usermod -a -G weston-launch $USER (replace $USER with your username) > > 1. Run a Gnome Wayland session. (Logged in from gdm) > 2. Switched to a virtual terminal (Ctrl-Alt-F3) > 3. On the virtual terminal run weston-launch > 4. Now executing 'firefox-wayland -no-remote' starts a window in the weston > session I followed your instructions exactly. If there is a firefox instance running in the Gnome session, then an attempt to start firefox-wayland in the weston session first brings up the profile selection dialog (on the weston display). Then, after selecting a profile, an error dialog appears, saying, "Firefox is already running, but not responding. To open a new window, you must first close the existing Firefox process, or restart your system.". After confirming that dialog by clicking the the "Ok" button, firefox-wayland terminates normally (no errors reported). So I terminated the firefox-wayland process running inside the Gnome session and repeated the test. In this case, after selecting a profile, firefox-wayland crashes: [thomas@sarkovy ~]$ firefox-wayland -no-remote Gdk-Message: 15:03:14.444: Error 71 (Protocol error) dispatching to Wayland disp lay. [Child 17348, Chrome_ChildThread] WARNING: pipe error (3): Connection reset by p eer: file /builddir/build/BUILD/firefox-69.0.1/ipc/chromium/src/chrome/common/ip c_channel_posix.cc, line 358 Exiting due to channel error. Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close with rea son=AbnormalShutdown (t=2.05266) [GFX1-]: Receive IPC close with reason=Abnormal Shutdown [Child 17284, Chrome_ChildThread] WARNING: pipe error (3): Connection reset by p eer: file /builddir/build/BUILD/firefox-69.0.1/ipc/chromium/src/chrome/common/ip c_channel_posix.cc, line 358 Exiting due to channel error. No big surprise that starting firefox-wayland without the -no-remote option yields the exact same result: [thomas@sarkovy ~]$ firefox-wayland Gdk-Message: 15:04:44.646: Error 71 (Protocol error) dispatching to Wayland disp lay. [Child 17623, Chrome_ChildThread] WARNING: pipe error (3): Connection reset by p eer: file /builddir/build/BUILD/firefox-69.0.1/ipc/chromium/src/chrome/common/ip c_channel_posix.cc, line 358 Exiting due to channel error. [Child 17521, Chrome_ChildThread] WARNING: pipe error (29): Connection reset by peer: file /builddir/build/BUILD/firefox-69.0.1/ipc/chromium/src/chrome/common/i pc_channel_posix.cc, line 358 [Child 17521, Chrome_ChildThread] WARNING: pipe error (3): Connection reset by p eer: file /builddir/build/BUILD/firefox-69.0.1/ipc/chromium/src/chrome/common/ip c_channel_posix.cc, line 358 Exiting due to channel error. Please do not run firefox in the GNOME session and do not unset the DISPLAY variable in the weston session. By me executing 'firefox-wayland' starts the browser in the Weston session with the same profile and settings as I would start it in the GNOME session. If you should still have problems starting the firefox in the Weston session do the following test: Stop all firefox processes (killall -9 firefox) $ cd $ mv .mozilla .mozilla.old Start firefox-wayland in the Weston session. Do you get still an error after that? (In reply to Gerd Pokorra from comment #16) > Please do not run firefox in the GNOME session and do not unset the DISPLAY > variable in the weston session. By me executing 'firefox-wayland' starts the > browser in the Weston session with the same profile and settings as I would > start it in the GNOME session. I did not unset DISPLAY (although if I did, this should not make a difference, since I am running a native wayland display, right?). And, as you can see in my previous post, I am experiencing crashes only in the case where there is no firefox running in the gnome session, otherwise, it will refuse to start (funny, I was under the impression that the -no-remote switch were supposed to prevent this). (In reply to Gerd Pokorra from comment #17) > If you should still have problems starting the firefox in the Weston session > do the following test: > > Stop all firefox processes (killall -9 firefox) > $ cd > $ mv .mozilla .mozilla.old > > Start firefox-wayland in the Weston session. Do you get still an error after > that? After removing the ~/.mozilla directory firefox-wayland indeed starts on the weston display. Of course, the profile selection dialog is now gone. Fine. So now we are sure that firefox-wayland starts on a weston session. I use the firefox option '-no-remote' when I want to use firefox locally and a second firefox window from a remote machine. To see the files and use the settings form the remote machine then the second firefox on the remote machine have to be opened with the option '-no-remote'. 1. Would you now please stop again all firefox processes. 2. Then rename the new ~/.mozilla directory to ~/.mozilla.weston. 3. Rename the directory ~/.mozilla.old back to ~/.mozilla. (mv ~/.mozilla.old ~/.mozilla) What happens if you start only firefox in GNOME session? What happens if you only start firefox in the Weston session? Do you want to keep the original settings (that was ~/.mozilla.old)? With 'firefox -h' you can see the available options. May be you have to use: --no-remote (to get this option working) You see that options to work with different profiles: -P <profile> Start with <profile>. --profile <path> Start with profile at <path>. Starting firefox twice also works. I started firefox in a GNOME session. After that I open a Weston session. In the weston session I execute the command 'firefox-wayland -no-remote -P'. A dialouge opens and I created a new profile and called it weston. Then I choose it to open firefox. Now I can start firefox with 'firefox-wayland -no-remote -P weston'. (In reply to Gerd Pokorra from comment #22) > Starting firefox twice also works. > > I started firefox in a GNOME session. > > After that I open a Weston session. > > In the weston session I execute the command 'firefox-wayland -no-remote -P'. > > A dialouge opens and I created a new profile and called it weston. Then I > choose it to open firefox. > > Now I can start firefox with 'firefox-wayland -no-remote -P weston'. I did some more experimentation and found that the crash is apparently related to the window size. I found that I can run ff-wayland on the weston display just fine, repeatedly even, as long as I do not maximize the window (by double-clicking its title bar). If I do that, the window is maximized correctly, but after closing it, every subsequent attempt to restart ff-wayland leads to a crash. I can then switch back to the Gnome session, start ff-wayland there, unmaximize and then close the window. Back to weston session I can now start ff-wayland again with no crash. So it seems that starting with the window maximized is what causes the crash. (In reply to Thomas Köller from comment #23) > I did some more experimentation and found that the crash is apparently > related > to the window size. I found that I can run ff-wayland on the weston display > just fine, repeatedly even, as long as I do not maximize the window (by > double-clicking > its title bar). If I do that, the window is maximized correctly, but after > closing it, > every subsequent attempt to restart ff-wayland leads to a crash. > > I can then switch back to the Gnome session, start ff-wayland there, > unmaximize > and then close the window. Back to weston session I can now start ff-wayland > again > with no crash. > > So it seems that starting with the window maximized is what causes the crash. Same thing here. I use Weston 7.0.0 with Wayland Protocols 1.17 on Fedora 30. I use this script to start thunderbird on Weston: $ cat thunderbird-wayland #!/usr/bin/bash # # Run Thunderbird under Wayland # export MOZ_ENABLE_WAYLAND=1 # exec /usr/bin/thunderbird "$@" Starting thunderbird in fullscreen provides the same error: Gdk-Message: 15:04:44.646: Error 71 (Protocol error) dispatching to Wayland display. Please try run with WAYLAND_DEBUG=1 env variable, it may help to diagnose the problem. Created attachment 1621840 [details]
Debug information of firefox-wayland start (script debug.log; firefox-wayland)
Additional the trailer of the debug information: [321366,846] -> xdg_toplevel(300, 128) [321366,869] -> xdg_toplevel(0, 0) [321366,880] -> xdg_surface(0, 0, 1280, 1061) [321366,898] -> wl_surface(nil) [321366,909] -> wl_compositor(new id wl_region@43) [321366,920] -> wl_region(-10, -10, 1300, 1081) [321366,936] -> wl_surface(wl_region@43) [321366,943] -> wl_region() [321367,015] -> wl_surface(new id wl_callback@44) [321367,029] -> wl_surface() [321383,720] -> wl_buffer() [321383,760] -> wl_shm_pool(new id wl_buffer@45, 0, 1280, 1024, 5120, 0) [321385,354] wl_display(38) [321385,377] wl_display(43) [321385,386] wl_display(xdg_wm_base@18, 4, "xdg_surface buffer does not match the configured state") Gdk-Message: 15:02:01.470: Error 71 (Protocol error) dispatching to Wayland display. Exiting due to channel error. $ I have the same issue. First Firefox spews: Gdk-Message: 23:59:31.057: Error 71 (Protocol error) dispatching to Wayland display. Exiting due to channel error Then it shows: Gdk-Message: 23:55:05.428: Error flushing display: Broken pipe Exiting due to channel error. Running it with WAYLAND_DEBUG=1 produces a lot of output which ends with: wl_display(xdg_wm_base@18, 4, "xdg_surface buffer does not match the configured state") Gdk-Message: 15:02:01.470: Error 71 (Protocol error) dispatching to Wayland display. Exiting due to channel error. Upstream says it's a bug in Firefox: https://gitlab.freedesktop.org/wayland/weston/-/issues/379 I would say Wayland/Weston sucks. We've had it for close to 12 years now and mission-critical apps still don't work under it correctly. Firefox will have it fixed in version 76: https://bugzilla.mozilla.org/show_bug.cgi?id=1623060 OMG. This is just crazy. This bug might be safely closed. It should be already fixed in Firefox 74.0.1 and 75.0 for Fedora, I backport it there. I can not confirm this. After updating a Fedora 31 the Firefox Version is 75.0, but the problem still occur. Interesting is that I do not have this on Ubuntu. This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |
Created attachment 1618625 [details] weston.ini used Description of problem: I have two wayland displays active: my Gnome session (WAYLAND_DISPLAY=wayland-0) and a second one created by running weston in a virtual terminal using the drm backend (WAYLAND_DISPLAY=wayland-1). When I launch firefox-wayland from a terminal window on the weston display, the firefox window opens on the screen belonging to the Gnome session, and not on the weston display as it is supposed to. It seems to me that the WAYLAND_DISPLAY variable is ignored and the 'wayland-0' is used unconditionally. Version-Release number of selected component (if applicable): 69.0.1 How reproducible: always Steps to Reproduce: 1. Run a Gnome Wayland session. 2. On a virtual terminal, run weston using drm-backend.so 3. Run a shell in a terminal window on the weston display, check WAYLAND_DISPLAY variable (should be wayland-1). 4. Run firefox-wayland from there 5. Switch to the Gnome display; the firefox window will have been opened there. Actual results: Firefox window opens on wayland-0 display. Expected results: Firefox window should open on wayland-1 display. Additional info: