1480053 - [flatpak][gnome-shell] Opening a new window using ctrl+N doesn't work until the Gnome Shell overview is activated

Status: RESOLVED WORKSFORME

(Core :: Widget: Gtk, defect)

Description

[Yariv]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0
Build ID: 20180801010158

Steps to reproduce:

In a 'Gnome Shell Wayland' session on Ubuntu 18.04 (Gnome Shell v. 3.28.2):
First, install Firefox Nightly (Wayland) using the 'flatpak' repo https://firefox-flatpak.mojefedora.cz/
Open the just-installed Firefox nightly. Once the Firefox window is fully displayed, try to open another window using the keyboard shortcut ctrl+N.


Actual results:

Firefox freezes. If I now activate the 'overview' mode of Gnome Shell, either by getting the mouse cursor to the top left corner of the screen or by pressing the 'meta' key on the keyboard, the new Firefox window appears. Exiting the 'overview' mode of Gnome shell I now have 2 operational Firefox windows as expected (the first window is no longer frozen).

The same thing happens when trying to open a new 'private' window. Also, the same or similar bug happens when trying to download a file - the file download dialog only appears after entering the 'overview' mode of Gnome Shell.


Expected results:

A new Firefox window should appear. The 2 windows should be immediately operational.

Comment 1

[Takuro Ashie [:ashie]]

It reproduces also on my GNOME environment when layer acceleration is enabled (layers.acceleration.force-enabled: true).

* Ubuntu 18.04
* GNOME Shell on Wayland

$ hg tip
changeset:   429522:d57a89840dbb
tag:         tip
fxtree:      central
parent:      429449:929ceb6c82fa
parent:      429521:01d7fd373ccb
user:        Bogdan Tara <[e-mail]>
date:        Wed Aug 01 00:58:55 2018 +0300
summary:     Merge inbound to mozilla-central.  a=merge

But it doesn't reproduce on Weston even if layer acceleration is enabled.

Comment 2

[Martin Stránský [:stransky] (ni? me)]

I suspect this is an issue with XRemote service. Do you run firefox flatpak only or do you have ale running a different firefox instance under different profile?

Comment 3

[Martin Stránský [:stransky] (ni? me)]

I think I can reproduce it but a different way and it's flatpak specific. For me when the new window is opened I see only a blank page which is non-operational. Looks like a Bug 1484921 to me, let's wait until is fixed and retest this one again. Strangely enough I can reproduce that with flatpak build only, plain nightly/wayland build work as expected. Adding Jan as he is our flatpak expert.

Comment 4

[Yariv]

(In reply to Martin Stránský [:stransky] from comment #3)
> I think I can reproduce it but a different way and it's flatpak specific.
> For me when the new window is opened I see only a blank page which is
> non-operational. Looks like a Bug 1484921 to me, let's wait until is fixed
> and retest this one again. Strangely enough I can reproduce that with
> flatpak build only, plain nightly/wayland build work as expected. Adding Jan
> as he is our flatpak expert.

I only run the flatpak version. No other Firefox instance is running. As Mr. Ashie said in the first comment, this bug doesn't reproduce on Weston. Btw I think that the flatpak repo no longer builds the nightly version - the latest build is from 18 Aug 2018.

Comment 5

[Yariv]

Maybe related to this bug - the flatpak GNOME runtime is at version 3.26 while the host runs GNOME 3.28. This might explain why the non-flatpak version behaves differently.

Comment 6

[Christian Stadelmann]

This may be related to the fact that Gtk has problems presenting new windows: https://gitlab.gnome.org/GNOME/gtk/issues/624

Comment 7

[Yariv]

With the flatpak FirefoxNightly version 20181108022619 this bug appears to be gone. In addition copying text from Firefox then pasting to other applications suddently works as well, including from the URL box.

Not sure what changed, however with this version I have to run Firefox from the command line using 
> GDK_BACKEND=wayland flatpak run org.mozilla.FirefoxNightly
otherwise it will start in xwayland mode.

Comment 8

[Yariv]

Eh, might have commented to soon. Now it doesn't work for 'Private Browsing' windows - still have to enter the 'overview' mode of Gnome shell for the window to appear. 'Normal' windows worked for a while then required 'overview' as well. It seems to work sporadically.

Comment 9

[Yariv]

(In reply to undefined from comment #undefined)
> 

Forgot to mention that hardware compositing is enabled for me as well (layers.acceleration.force-enabled: true). Didn't seem important at the time. My GPU is an Intel one (HD530 - the one that comes along with the core i7-6700K cpu). I think that this bug is related to https://bugzilla.mozilla.org/show_bug.cgi?id=1509275 and https://bugzilla.mozilla.org/show_bug.cgi?id=1489902

Comment 10

[Yariv]

(In reply to Takuro Ashie [:ashie] from comment #1)
> It reproduces also on my GNOME environment when layer acceleration is
> enabled (layers.acceleration.force-enabled: true).
> 
> * Ubuntu 18.04
> * GNOME Shell on Wayland
> 
> $ hg tip
> changeset:   429522:d57a89840dbb
> tag:         tip
> fxtree:      central
> parent:      429449:929ceb6c82fa
> parent:      429521:01d7fd373ccb
> user:        Bogdan Tara <[e-mail]>
> date:        Wed Aug 01 00:58:55 2018 +0300
> summary:     Merge inbound to mozilla-central.  a=merge
> 
> But it doesn't reproduce on Weston even if layer acceleration is enabled.

Sorry, my last comment was supposed to be a reply to this comment.

Comment 11

[Yariv]

I think that this bug can be closed now, on current nightly (build id 20181213145339) it no longer reproduces.

Comment 12

[Takuro Ashie [:ashie]]

It works for me too.