can´t resize window on wayland
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox84 | --- | disabled |
People
(Reporter: w.pelser, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(3 files)
Screenshot_20201126_083424.jpg
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0
Steps to reproduce:
open firefox window on wayland, not maximized, but as a part of the screen, then tried to maximize the window, or tried to make this window partially bigger with the cursor.
Actual results:
The result is, that the KDE-plasma part of the window is changing its size as expected, but not the firefox window itself. It is flickering between the old size and the expected size.
Unstable.
Expected results:
Resizing should be working without instability, as it was on FF <= 83
|
||
Comment 1•5 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
closing such a flickering FF (with artefacts) and starting it again makes it stable again, in the wanted window size
|
||
Comment 3•5 years ago
|
||
Do I understand correctly that you use KDE/Wayland?
Thanks.
Correct!
If you need any other info, please send a request. about:support is added, although it is experimental.
|
||
Comment 6•5 years ago
•
|
||
Which distribution and version is this on? Which kwin-wayland version?
"windowLayerManagerType": "Basic",
"failures": [
"[GFX1-]: Failed to create EGLContext!: 0x3009",
"[GFX1-]: FEATURE_FAILTURE_WEBRENDER_INITIALIZE_UNSPECIFIED",
"[GFX1-]: Failed to connect WebRenderBridgeChild.",
"[GFX1-]: Failed to create EGLContext!: 0x3009",
"[GFX1-]: Failed to create EGLContext!: 0x3005",
"[GFX1-]: Failed GL context creation for WebRender: 0",
"gfx.webrender.compositor": true,
"gfx.webrender.compositor.force-enabled": true,
Please disable these two prefs, they are not implemented.
Could you try to find a regression range?
$ pip3 install --upgrade mozregression
$ MOZ_ENABLE_WAYLAND=1 ~/.local/bin/mozregression --good 82 --bad 84 --pref gfx.webrender.all:true
Is this bug still reproducible with latest Nightly?
$ MOZ_ENABLE_WAYLAND=1 ~/.local/bin/mozregression --launch 2020-11-24 --pref gfx.webrender.all:true
Command was:
MOZ_ENABLE_WAYLAND=1 ~/.local/bin/mozregression --good 82 --bad 84 --pref gfx.webrender.all:true
But here the two versions 83.0a1 and 85.0a1 were used, not the expected version 84.xx. Result is: no defect in both cases.
Please send me a working command, if needed.
openSUSE-Tumbleweed-x86_64 snapshot20201123 / kwin5 5.20.3-1.1
Of course, i know that they are not implemented, but I still have the hope. that they may be work some day. for me ......., but et seems to be too old.
So I have disabled them first and then started mozregression with the result mentioned above.
Now I tried different commands to test the right versions.
walther@localhost:~> MOZ_ENABLE_WAYLAND=1 ~/.local/bin/mozregression --good 2020-09-21 --bad 2020-10-23 --pref gfx.webrender.all:true**********
You should use a config file. Please use the --write-config command line flag to help you create one.
0:03.15 INFO: Testing good and bad builds to ensure that they are really good and bad...
0:03.15 INFO: Downloading build from: https://archive.mozilla.org/pub/firefox/nightly/2020/09/2020-09-21-21-36-12-mozilla-central/firefox-83.0a1.en-US.linux-x86_64.tar.bz2
===== Downloaded 100% =====
0:48.75 INFO: Running mozilla-central build for 2020-09-21
1:00.26 INFO: Launching /tmp/tmp423shit2/firefox/firefox
1:00.26 INFO: Application command: /tmp/tmp423shit2/firefox/firefox -profile /tmp/tmp8bd1m4uq.mozrunner
1:00.27 INFO: application_buildid: 20200921213612
1:00.27 INFO: application_changeset: a5cdfde00f159276453541049a8cbb5f7043ae2a
1:00.27 INFO: application_name: Firefox
1:00.27 INFO: application_repository: https://hg.mozilla.org/mozilla-central
1:00.27 INFO: application_version: 83.0a1
Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry' or 'exit' and press Enter): good
1:17.76 INFO: Downloading build from: https://archive.mozilla.org/pub/firefox/nightly/2020/10/2020-10-23-21-47-13-mozilla-central/firefox-84.0a1.en-US.linux-x86_64.tar.bz2
1:43.73 INFO: Running mozilla-central build for 2020-10-23
1:57.60 INFO: Launching /tmp/tmpfgo_dama/firefox/firefox
1:57.60 INFO: Application command: /tmp/tmpfgo_dama/firefox/firefox -profile /tmp/tmpg7bl9n9k.mozrunner
1:57.61 INFO: application_buildid: 20201023214713
1:57.61 INFO: application_changeset: 1980f87855fc557e7ef6bb24b66c4d2df5606afa
1:57.61 INFO: application_name: Firefox
1:57.61 INFO: application_repository: https://hg.mozilla.org/mozilla-central
1:57.61 INFO: application_version: 84.0a1
Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry' or 'exit' and press Enter): exit
2:24.48 INFO: To resume, run:
2:24.48 INFO: /home/walther/.local/bin/mozregression --pref gfx.webrender.all:true --repo=mozilla-central --good=2020-09-21 --bad=2020-10-23
walther@localhost:~> MOZ_ENABLE_WAYLAND=1 ~/.local/bin/mozregression --good 2020-09-21 --bad 2020-10-31 --pref gfx.webrender.all:true
You should use a config file. Please use the --write-config command line flag to help you create one.
0:02.06 INFO: Testing good and bad builds to ensure that they are really good and bad...
0:02.06 INFO: Downloading build from: https://archive.mozilla.org/pub/firefox/nightly/2020/09/2020-09-21-21-36-12-mozilla-central/firefox-83.0a1.en-US.linux-x86_64.tar.bz2
===== Downloaded 100% =====
0:47.93 INFO: Running mozilla-central build for 2020-09-21
0:59.69 INFO: Launching /tmp/tmpuf8a1wev/firefox/firefox
0:59.69 INFO: Application command: /tmp/tmpuf8a1wev/firefox/firefox -profile /tmp/tmpm9b3nx4c.mozrunner
0:59.70 INFO: application_buildid: 20200921213612
0:59.70 INFO: application_changeset: a5cdfde00f159276453541049a8cbb5f7043ae2a
0:59.70 INFO: application_name: Firefox
0:59.70 INFO: application_repository: https://hg.mozilla.org/mozilla-central
0:59.70 INFO: application_version: 83.0a1
Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry' or 'exit' and press Enter): good
1:17.78 INFO: Downloading build from: https://archive.mozilla.org/pub/firefox/nightly/2020/10/2020-10-31-21-05-17-mozilla-central/firefox-84.0a1.en-US.linux-x86_64.tar.bz2
1:43.47 INFO: Running mozilla-central build for 2020-10-31
1:56.81 INFO: Launching /tmp/tmpeg6z1wmp/firefox/firefox
1:56.81 INFO: Application command: /tmp/tmpeg6z1wmp/firefox/firefox -profile /tmp/tmpp7g660yh.mozrunner
1:56.82 INFO: application_buildid: 20201031210517
1:56.82 INFO: application_changeset: cac5627ac1add823a368c260311e12f3b7db1beb
1:56.82 INFO: application_name: Firefox
1:56.82 INFO: application_repository: https://hg.mozilla.org/mozilla-central
1:56.82 INFO: application_version: 84.0a1
Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry' or 'exit' and press Enter): exit
2:09.89 INFO: To resume, run:
2:09.89 INFO: /home/walther/.local/bin/mozregression --pref gfx.webrender.all:true --repo=mozilla-central --good=2020-09-21 --bad=2020-10-31
walther@localhost:~> MOZ_ENABLE_WAYLAND=1 ~/.local/bin/mozregression --good 2020-09-21 --bad 2020-11-15 --pref gfx.webrender.all:true
You should use a config file. Please use the --write-config command line flag to help you create one.
0:01.97 INFO: Testing good and bad builds to ensure that they are really good and bad...
0:01.97 INFO: Downloading build from: https://archive.mozilla.org/pub/firefox/nightly/2020/09/2020-09-21-21-36-12-mozilla-central/firefox-83.0a1.en-US.linux-x86_64.tar.bz2
===== Downloaded 100% =====
1:59.10 INFO: Running mozilla-central build for 2020-09-21
2:10.67 INFO: Launching /tmp/tmpcd7eeb0b/firefox/firefox
2:10.67 INFO: Application command: /tmp/tmpcd7eeb0b/firefox/firefox -profile /tmp/tmpfllqs8p9.mozrunner
2:10.68 INFO: application_buildid: 20200921213612
2:10.68 INFO: application_changeset: a5cdfde00f159276453541049a8cbb5f7043ae2a
2:10.68 INFO: application_name: Firefox
2:10.68 INFO: application_repository: https://hg.mozilla.org/mozilla-central
2:10.68 INFO: application_version: 83.0a1
Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry' or 'exit' and press Enter): good
2:24.45 INFO: Downloading build from: https://archive.mozilla.org/pub/firefox/nightly/2020/11/2020-11-15-21-32-16-mozilla-central/firefox-84.0a1.en-US.linux-x86_64.tar.bz2
2:53.98 INFO: Running mozilla-central build for 2020-11-15
3:07.63 INFO: Launching /tmp/tmpgx6zv1wa/firefox/firefox
3:07.63 INFO: Application command: /tmp/tmpgx6zv1wa/firefox/firefox -profile /tmp/tmpf37ixj8n.mozrunner
3:07.65 INFO: application_buildid: 20201115213216
3:07.65 INFO: application_changeset: b9dd8e54c8ae449638635758a6571285655a4d0c
3:07.65 INFO: application_name: Firefox
3:07.65 INFO: application_repository: https://hg.mozilla.org/mozilla-central
3:07.65 INFO: application_version: 84.0a1
Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry' or 'exit' and press Enter): exit
3:24.56 INFO: To resume, run:
3:24.56 INFO: /home/walther/.local/bin/mozregression --pref gfx.webrender.all:true --repo=mozilla-central --good=2020-09-21 --bad=2020-11-15
I pressed "exit" because the issue did not occur. All the versions were "good".
|
Reporter | |
Comment 10•5 years ago
|
||
Just installed nightly 85.0a1 (2020-11-25)(64-bit) on my machine and the bug is there too. mozillaregression seems to be unable to detect this issue.
|
||
Comment 11•5 years ago
|
||
If you use Plasma, make sure that WebRender is enabled. We've found that Firefox provides incomplete wl_shm_buffer client buffers (this goes against the spec), which may result in all sorts of visual artifacts.
|
|
Reporter | |
Comment 12•5 years ago
|
||
this is a screenshot to show the issue.
|
|
Reporter | |
Comment 13•5 years ago
|
||
In my about:config:
gfx.webrender.all true
gfx.webrender.enabled true
The issue remains
|
|
||
Comment 14•5 years ago
|
||
Strange, I can't reproduce the issue. Note that I'm running kwin built from git master and firefox 83.
|
|
||
Comment 15•5 years ago
|
||
Can you try disabling the server side decoration? You can do it by unchecking "Title Bar" in the customize page.
|
|
Reporter | |
Comment 16•5 years ago
|
||
(In reply to Vlad Zahorodnii [:zzag] from comment #14 + #15)
Strange, I can't reproduce the issue. Note that I'm running kwin built from git master and firefox 83.
Can you try disabling the server side decoration? You can do it by unchecking "Title Bar" in the customize page.
FF 83 does not have this issue, FF 84beta/nightly or 85nightly are required.
What do you mean with "Title Bar" ? There is a "menu bar" or "side bar", only in about:config there is a "title bar", but changing this setting takes no effect on this bug.
|
|
||
Comment 17•5 years ago
|
||
(In reply to W.Pelser from comment #16)
FF 83 does not have this issue, FF 84beta/nightly or 85nightly are required.
For what it's worth, I can't reproduce this bug in Firefox 85 (Nightly) either.
What do you mean with "Title Bar" ? There is a "menu bar" or "side bar", only in about:config there is a "title bar", but changing this setting takes no effect on this bug.
I asked to open the "Customize" page and uncheck the "Title Bar" checkbox.
|
|
Reporter | |
Comment 18•5 years ago
|
||
The "Title Bar" comes from KDE/Plasma and is reacting in the right way, when I change the size of the window. FF as a gtk-application does not react in the expected way. I use this "Title Bar" very often.
|
|
||
Comment 19•5 years ago
|
||
(In reply to W.Pelser from comment #9)
Now I tried different commands to test the right versions.
walther@localhost:~> MOZ_ENABLE_WAYLAND=1 ~/.local/bin/mozregression --good 2020-09-21 --bad 2020-10-23 --pref
I pressed "exit" because the issue did not occur. All the versions were "good".
Please run it again and type "good" when it's good. At the end, mozregression will close itself and tell you the last good revision + first bad revision + pushlog url - please copy only that.
|
|
Reporter | |
Comment 20•5 years ago
|
||
The result is somehow strange: On my desktop FF 84 shows the described issue, but with
MOZ_ENABLE_WAYLAND=1 ~/.local/bin/mozregression --good 2020-09-21 --bad 2020-10-23 --pref gfx.webrender.all:true
I got the result:
ERROR: Build was expected to be bad! The initial good/bad range seems incorrect, because no bad version could be found.
(That is the reason why I choose always "exit" above.)
So I tried now mozregression with FF 85 included and it could detect a bad version of FF 85.
MOZ_ENABLE_WAYLAND=1 ~/.local/bin/mozregression --good 2020-09-21 --bad 2020-11-24 --pref gfx.webrender.all:true
This are the last 4 lines:
16:06.10 INFO: Last good revision: 785624cc9edfc68ebc6428f8a3cac45fdeb74383
16:06.10 INFO: First bad revision: 72e7d30ced00970f4d717f12ce3a01f5d202d1be
16:06.10 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=785624cc9edfc68ebc6428f8a3cac45fdeb74383&tochange=72e7d30ced00970f4d717f12ce3a01f5d202d1be
I have no explanation why mozregression can only detect the issue with FF 85 and not with FF 84, but never mind.
|
|
||
Comment 21•5 years ago
|
||
(In reply to W.Pelser from comment #20)
Thanks! Your graphics card is so old that it only supports OpenGL 2.1, but OpenGL 3.2 is required for WebRender (and also for WebGL 2).
Please set all WebRender prefs back to their default.
(Users like you will also get WebRender in the future, but with a software GL implementation.)
bug 1677825 made sure that Firefox falls back to using Basic (software rendering) instead of using the old depreated buggy OpenGL backend ("Compositing: OpenGL" on about:support).
Please also set layers.acceleration.force-enabled (the deprecated OpenGL backend) back to its default, it's unsupported.
Does disabling these prefs fix the bug?
Are you able to find a better range with one of these commands?
$ MOZ_ENABLE_WAYLAND=1 ~/.local/bin/mozregression --good 82 --bad 84 --pref gfx.webrender.force-disabled:true
$ MOZ_ENABLE_WAYLAND=1 ~/.local/bin/mozregression --good 82 --bad 84 --pref gfx.webrender.force-disabled:true layers.acceleration.force-enabled:true
|
|
Reporter | |
Comment 22•5 years ago
|
||
Thanks! Your graphics card is so old that it only supports OpenGL 2.1, but OpenGL 3.2 is required for WebRender (and also for WebGL 2).
Please set all WebRender prefs back to their default.
(Users like you will also get WebRender in the future, but with a software GL implementation.)
Maybe, I have to wait!
bug 1677825 made sure that Firefox falls back to using Basic (software rendering) instead of using the old depreated buggy OpenGL backend ("Compositing: OpenGL" on about:support).
Please also set layers.acceleration.force-enabled (the deprecated OpenGL backend) back to its default, it's unsupported.Does disabling these prefs fix the bug?
Are you able to find a better range with one of these commands?
$ MOZ_ENABLE_WAYLAND=1 ~/.local/bin/mozregression --good 82 --bad 84 --pref gfx.webrender.force-disabled:true
$ MOZ_ENABLE_WAYLAND=1 ~/.local/bin/mozregression --good 82 --bad 84 --pref gfx.webrender.force-disabled:true layers.acceleration.force-enabled:true
I followed all your advices, but no change.
On OS tumbleweed this issue occurs only on plasma-full-wayland, not on plasma or plasma-wayland, I just tested it.
|
|
Reporter | |
Comment 23•5 years ago
|
||
There is another strange misbehavior of FF:
If I set in "about:config":
"gfx.webrender.all false",
firefox becomes absolute unusable. The window is completely unstable and is always flickering, sometimes total empty, so that my wallpaper background is visible.
I always have to set in about:config:
"gfx.webrender.all true"
This is then the information in about:support
WEBRENDER available by default
force_enabled by user: Force enabled by pref
disabled by env: Not qualified
unavailable by runtime: WebRender initialization failed
So it should be disabled, but it is absolutely necessary!
|
|
Reporter | |
Comment 24•5 years ago
|
||
Additional info:
thunderbird 78.5.0-1.1 is only stable on my desktop, if "gfx.webrender.all true" is set!
|
|
Reporter | |
Comment 25•5 years ago
|
||
This is the correct layout of comment #22
Thanks! Your graphics card is so old that it only supports OpenGL 2.1, but OpenGL 3.2 is required for WebRender (and also for WebGL 2).
Please set all WebRender prefs back to their default.
(Users like you will also get WebRender in the future, but with a software GL implementation.)
Maybe, I have to wait!
bug 1677825 made sure that Firefox falls back to using Basic (software rendering) instead of using the old depreated buggy OpenGL backend ("Compositing: OpenGL" on about:support).
Please also set layers.acceleration.force-enabled (the deprecated OpenGL backend) back to its default, it's unsupported.Does disabling these prefs fix the bug?
Are you able to find a better range with one of these commands?
$ MOZ_ENABLE_WAYLAND=1 ~/.local/bin/mozregression --good 82 --bad 84 --pref gfx.webrender.force-disabled:true
$ MOZ_ENABLE_WAYLAND=1 ~/.local/bin/mozregression --good 82 --bad 84 --pref gfx.webrender.force-disabled:true layers.acceleration.force-enabled:true
I followed all your advices, but no change.
On OS tumbleweed this issue occurs only on plasma-full-wayland, not on plasma or plasma-wayland, I just tested it.
|
|
Reporter | |
Comment 26•5 years ago
|
||
fixed in Firefox 85.0 Beta 5 (and Nightly 87.0a1 too)
I wanted to close this bug as resolved and fixed, but there is only the item "RESOLVED / WORKSFORME", so I choose this one.
Description
•