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.