User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:85.0) Gecko/20100101 Firefox/85.0

Steps to reproduce:

Starting firefox beta Firefox 85.0 Beta 5 (or nightly Nightly 87.0a1 too)

Actual results:

When I start Firefox 85.0 Beta 5 (or nightly Nightly 87.0a1 too), the GUI only reacts delayed, when there is an entry with mouse or keyboard. it is hardly usable.
F.I:

• menu bar items must be clicked twice to open the submenu
• entries into the search bar are delayed or sometimes completely missing, deleting an entry is always delayed sometimes impossible
• Help/about firefox/the subwindow , where searching for updates is shown, does not change, if update is downloaded, or it changed very delayed.
  Clicking on the main page of firefox updates this subwindow at once.

Expected results:

Immediately reaction is expected

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Might be a dup of bug 1616894, see https://bugzilla.mozilla.org/show_bug.cgi?id=1616894#c12. If that's the case, you should be able to work around it by setting widget.wayland_vsync.enabled to false in about:config. Fixed in KWin 5.21.

W.Pelser, can you confirm?

No I can't. Tested with kwin 5.21 and widget.wayland_vsync.enabled or widget.wayland_vsync.enabled to false, but there was no substantial change.

Hm, can you check if nightly is any better?

(In reply to Robert Mader [:rmader] from comment #5)

Hm, can you check if nightly is any better?
stdout beta:
*@desktop-a4fml:~> /home/walther/.firefox/beta/firefox/firefox
[GFX1-]: glxtest: libGLESv2 glGetString returned null

###!!! [Parent][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost

*@desktop-a4fml:~>

Nightly is very much better. Only the menu bar does need two mouse clicks or so . But I could it test it tomorrow with more time.

stdout nightly:
*@desktop-a4fml:> /home/walther/.firefox/nightly/firefox/firefox
[GFX1-]: Failed to create EGLContext!: 0x3009
[GFX1-]: Failed to create EGLContext!: 0x3005
[GFX1-]: Failed GL context creation for WebRender: 0
[GFX1-]: Failed to create EGLContext!: 0x3009
[GFX1-]: Failed to create EGLContext!: 0x3005
[GFX1-]: Failed GL context creation for WebRender: 0
[GFX1-]: Failed to create EGLContext!: 0x3009
[GFX1-]: Failed to create EGLContext!: 0x3005
[GFX1-]: Failed GL context creation for WebRender: 0
[GFX1-]: Failed to get shared GL context
[GFX1-]: Failed to create EGLContext!: 0x3009
[GFX1-]: Failed to create EGLContext!: 0x3005
[GFX1-]: Failed GL context creation for WebRender: 0
[GFX1-]: Failed to create EGLContext!: 0x3009
[GFX1-]: Failed to create EGLContext!: 0x3005
[GFX1-]: Failed GL context creation for WebRender: 0
[GFX1-]: FEATURE_FAILURE_WEBRENDER_INITIALIZE_UNSPECIFIED
[GFX1-]: Failed to connect WebRenderBridgeChild.
[GFX1-]: Fallback WR to SW-WR
*@desktop-a4fml:>

*@desktop-a4fml:> /home/walther/.firefox/nightly/firefox/firefox
[GFX1-]: Failed to create EGLContext!: 0x3009
[GFX1-]: Failed to create EGLContext!: 0x3005
[GFX1-]: Failed GL context creation for WebRender: 0
[GFX1-]: Failed to create EGLContext!: 0x3009
[GFX1-]: Failed to create EGLContext!: 0x3005
[GFX1-]: Failed GL context creation for WebRender: 0
[GFX1-]: Failed to create EGLContext!: 0x3009
[GFX1-]: Failed to create EGLContext!: 0x3005
[GFX1-]: Failed GL context creation for WebRender: 0
[GFX1-]: Failed to get shared GL context
[GFX1-]: Failed to create EGLContext!: 0x3009
[GFX1-]: Failed to create EGLContext!: 0x3005
[GFX1-]: Failed GL context creation for WebRender: 0
[GFX1-]: Failed to create EGLContext!: 0x3009
[GFX1-]: Failed to create EGLContext!: 0x3005
[GFX1-]: Failed GL context creation for WebRender: 0
[GFX1-]: FEATURE_FAILURE_WEBRENDER_INITIALIZE_UNSPECIFIED
[GFX1-]: Failed to connect WebRenderBridgeChild.
[GFX1-]: Fallback WR to SW-WR
*@desktop-a4fml:>

comment 7 is obsolete. I can't fill into the text in right manner without the lines. Sorry.

(In reply to Robert Mader [:rmader] from comment #5)

Hm, can you check if nightly is any better?
#2
Deleting single letters in the address bar is very delayed, sometimes not the first one, but later on. Deleting the complete address works immediately.
In about:config making changes is delayed.
Is webrender software working for me? If it is enabled in about.config , it seems to be so. The GFX1 errors in stdout are gone then. It seems not to be enabled by default, in opposite to the information given in about:support.

Could you paste you about:support from nigthly? It should look better after bug 1689207 landed.

This is about:support after having changed the profile from nightly default to my user default one. When writing this comment the delay is annoying. It is better to write comments with with the actual version of firefox.

(In reply to Robert Mader [:rmader] from comment #5)

Hm, can you check if nightly is any better?

Setting widget.wayland_vsync.enabled to false in about:config make it somehow easier to write on this page, because then I can cut off the delay by clicking once or twice with the mouse on this field. It is better, but not good. Sometimes this field is working as expected, sometimes not. Strange behavior. The hdd seems to react, always when there are written some signs on this page. This is very unusual.

(In reply to Robert Mader [:rmader] from comment #5)

Hm, can you check if nightly is any better?

Maybe this could be interesting for you:
*@desktop-a4fml:~> /home/walther/.firefox/nightly/firefox/firefox

###!!! [Child][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost

###!!! [Child][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost

(firefox:5336): Gdk-WARNING **: 17:39:16.025: Tried to unmap the parent of a popup

Please look into the attachments, where the right versions are mentioned. As expected firefox BuildID=20210226094123 Milestone=88.0a1 has the same issue.

Changing
gfx.webrender.software.opengl from false to true
seems to solve this issue in my case.

(In reply to W.Pelser from comment #15)

Changing
gfx.webrender.software.opengl from false to true
seems to solve this issue in my case.

This solution works with FF 88 beta, not with FF 86

(In reply to W.Pelser from comment #16)

This solution works with FF 88 beta, not with FF 86

Yes, it was only introduced in bug 1673342 - what you see, however, is very likely a KWin bug with SW-WR. Mind opening a bug at https://bugs.kde.org/enter_bug.cgi?product=kwin and link it to this one (and vice-versa)?

N(In reply to Robert Mader [:rmader] from comment #17)

(In reply to W.Pelser from comment #16)

This solution works with FF 88 beta, not with FF 86

Yes, it was only introduced in bug 1673342 - what you see, however, is very likely a KWin bug with SW-WR. Mind opening a bug at https://bugs.kde.org/enter_bug.cgi?product=kwin and link it to this one (and vice-versa)?

New test with FF 89 nightly shows, that "gfx.webrender.software.opengl true" is not longer needed. So I don´t think, that there is a kwin-bug. (?)

(In reply to W.Pelser from comment #18)

New test with FF 89 nightly shows, that "gfx.webrender.software.opengl true" is not longer needed. So I don´t think, that there is a kwin-bug. (?)

Does that mean the issue is fixed on nightly?

(In reply to Robert Mader [:rmader] from comment #19)

(In reply to W.Pelser from comment #18)

New test with FF 89 nightly shows, that "gfx.webrender.software.opengl true" is not longer needed. So I don´t think, that there is a kwin-bug. (?)

Does that mean the issue is fixed on nightly?

No, on some sites there is no delay, but on this site in the field "Search Bugs" the delay remains, if "gfx.webrender.software.opengl" is turned to false.

Ah I see. Then this is likely a dup of 1693472, see bug 1693472 comment 5

I have the same problem with FF 88 from Flathub repo + KDE wayland + Firefox window protocol is wayland. But FF 88 from Fedora 34 dnf repo + KDE wayland + Firefox window protocol is wayland does not have problem. Please fix.