Bug 1191112 - [Build 39.1] When navigating through YaST module screens the next screen appears, but its content is not loaded
[Build 39.1] When navigating through YaST module screens the next screen appe...
Status: RESOLVED FIXED
: 1190217 (view as bug list)
Classification: openSUSE
Product: PUBLIC SUSE Linux Enterprise Server 15 SP4
Classification: openSUSE
Component: YaST2
unspecified
Other Other
: P2 - High : Normal
: ---
Assigned To: YaST Team
https://openqa.suse.de/tests/7219530/...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2021-09-28 17:12 UTC by Oleksandr Orlov
Modified: 2022-10-10 12:25 UTC (History)
12 users (show)

See Also:
Found By: openQA
Services Priority:
Business Priority:
Blocker: Yes
Marketing QA Status: ---
IT Deployment: ---


Attachments
Gif that shows the issue (90.53 KB, image/gif)
2021-09-28 17:12 UTC, Oleksandr Orlov
Details
Screenshot with issue example - partitioner (48.77 KB, image/png)
2021-09-28 17:13 UTC, Oleksandr Orlov
Details
Screenshot with issue example - nfs client (47.25 KB, image/png)
2021-09-28 17:13 UTC, Oleksandr Orlov
Details
Screenshot with issue example - kernel settings (29.87 KB, image/png)
2021-09-28 17:14 UTC, Oleksandr Orlov
Details
y2logs for partitioner glitch (2.51 MB, application/x-xz)
2021-09-28 17:14 UTC, Oleksandr Orlov
Details
vm-settings.xml (5.53 KB, text/xml)
2022-01-27 14:55 UTC, Oleksandr Orlov
Details
Optional Kenrel Command Line Parameter glitched entry (26.64 KB, image/png)
2022-03-30 14:30 UTC, George Gkioulis
Details
Optional Kenrel Command Line Parameter entry fixed by clicking on it (30.73 KB, image/png)
2022-03-30 14:31 UTC, George Gkioulis
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Oleksandr Orlov 2021-09-28 17:12:28 UTC
Created attachment 852807 [details]
Gif that shows the issue

The issue started reproducing from build 31.2 and faced in different YaST modules (e.g. scc, lan, Kernel Settings, partitioner). I've found most easy steps that allow to reproduce the issue manually with "Kernel Settings" module.

Steps to reproduce:
1. Install latest version of SLE15-SP4 (e.g. 39.1)
2. Run YaST Control Center in Qt;
3. Select "Kernel Settings" module;
4. When the module is opened, select "Kernel Settings" tab and focus on the content of the window.

Expected result:
The content that corresponds to the respective tab is shown.
Actual result:
Content of the previous tab is shown ("PCI ID Setup") and "Enable SysRq Keys" checkbox appears on top of it, so it looks like glitch. Please, see screenshot and gif to see how it looks.

NOTE: Sometimes it works correctly, which is seen on gif image, but if select tab again, it happens again as well.

Please, contact me in Slack or Libera.Chat #yast channel (oorlov) in case you need my assistance in reproducing the issue.

## Reproducible

Fails since (at least) Build [31.2](https://openqa.suse.de/tests/7029316)

Always latest result in this scenario: [latest](https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=Online&machine=64bit&test=sles%2Bsdk%2Bproxy_SCC_via_YaST&version=15-SP4)
Comment 1 Oleksandr Orlov 2021-09-28 17:13:36 UTC
Created attachment 852808 [details]
Screenshot with issue example - partitioner
Comment 2 Oleksandr Orlov 2021-09-28 17:13:59 UTC
Created attachment 852809 [details]
Screenshot with issue example - nfs client
Comment 3 Oleksandr Orlov 2021-09-28 17:14:16 UTC
Created attachment 852810 [details]
Screenshot with issue example - kernel settings
Comment 4 Oleksandr Orlov 2021-09-28 17:14:58 UTC
Created attachment 852811 [details]
y2logs for partitioner glitch
Comment 5 Knut Alejandro Anderssen González 2021-09-30 13:41:43 UTC
As it is manually reproducible it would be nice if you could a deeper look as apparently from logs there is nothing wrong and probably something not so easy to fix.
Comment 6 Stefan Hundhammer 2021-10-13 12:34:57 UTC
Those are redraw glitches completely beyond our (as the YaST team) control.

It might be in X11 or in Qt. If this is in a QEMU environment, I strongly suspect that this is yet another one of those QEMU problems that we keep seeing all the time.
Comment 7 Knut Alejandro Anderssen González 2021-10-13 15:49:45 UTC
Stefan, could you take a look? what do you think?
Comment 8 Stefan Dirsch 2021-10-13 16:21:16 UTC
Indeed we would need to know the -vga and -display options, which are being used for qemu here.
Comment 9 Stefan Hundhammer 2021-10-13 16:23:23 UTC
I notice that in each case, a tab widget is involved.

In each case, the old background is not properly erased as it should before redrawing; there are remnants of the previous background visible.

But the redrawing itself appears to work; only the part that does NOT need to be redrawn is wrong.

Does this build have a newer Qt lib?

In what environment does this happen? QEMU? Also VirtualBox? Or where else?
Comment 10 Stefan Hundhammer 2021-10-13 16:27:25 UTC
What confuses me even more is that this appears to use the OLD tabs prior to this PR:

  https://github.com/libyui/libyui/pull/31

What we should be seeing are tabs that don't stretch all the width of the window, and frames on the left, bottom and right. But none of that is there. Why not?

That PR went into the master branch, i.e. YaST:Head, so it should actually be there in SLE-15-SP4.
Comment 11 Oleksandr Orlov 2021-10-13 16:33:32 UTC
(In reply to Stefan Dirsch from comment #8)
> Indeed we would need to know the -vga and -display options, which are being
> used for qemu here.

This is the command that is used for running qemu in openQA (thought, I do not see -vga and -display options there):

/usr/bin/qemu-system-x86_64 -only-migratable -chardev ringbuf,id=serial0,logfile=serial0,logappend=on -serial chardev:serial0 -audiodev none,id=snd0 -device intel-hda -device hda-output,audiodev=snd0 -global isa-fdc.fdtypeA=none -m 1024 -cpu qemu64 -netdev user,id=qanet0 -device virtio-net,netdev=qanet0,mac=52:54:00:12:34:56 -boot order=c -device usb-ehci -device usb-tablet -smp 1 -enable-kvm -no-shutdown -vnc :118,share=force-shared -device virtio-serial -chardev pipe,id=virtio_console,path=virtio_console,logfile=virtio_console.log,logappend=on -device virtconsole,chardev=virtio_console,name=org.openqa.console.virtio_console -chardev pipe,id=virtio_console1,path=virtio_console1,logfile=virtio_console1.log,logappend=on -device virtconsole,chardev=virtio_console1,name=org.openqa.console.virtio_console1 -chardev socket,path=qmp_socket,server,nowait,id=qmp_socket,logfile=qmp_socket.log,logappend=on -qmp chardev:qmp_socket -S -device virtio-scsi-pci,id=scsi0 -blockdev driver=file,node-name=hd0-overlay0-file,filename=/var/lib/openqa/pool/28/raid/hd0-overlay0,cache.no-flush=on -blockdev driver=qcow2,node-name=hd0-overlay0,file=hd0-overlay0-file,cache.no-flush=on -device virtio-blk,id=hd0-device,drive=hd0-overlay0,bootindex=0,serial=hd0 -blockdev driver=file,node-name=cd0-overlay0-file,filename=/var/lib/openqa/pool/28/raid/cd0-overlay0,cache.no-flush=on -blockdev driver=qcow2,node-name=cd0-overlay0,file=cd0-overlay0-file,cache.no-flush=on -device scsi-cd,id=cd0-device,drive=cd0-overlay0,serial=cd0

Locally I used Virtual Manager with the default settings

Display Spice:
<graphics type="spice" port="5900" autoport="yes" listen="127.0.0.1">
  <listen type="address" address="127.0.0.1"/>
  <image compression="off"/>
</graphics>

Video QXL:
<video>
  <model type="qxl" ram="65536" vram="65536" vgamem="16384" heads="1" primary="yes"/>
  <alias name="video0"/>
  <address type="pci" domain="0x0000" bus="0x00" slot="0x01" function="0x0"/>
</video>

Please, let me know if you need any additional info.
Comment 12 Oleksandr Orlov 2021-10-13 16:44:34 UTC
(In reply to Stefan Hundhammer from comment #9)
> I notice that in each case, a tab widget is involved.
> 
> In each case, the old background is not properly erased as it should before
> redrawing; there are remnants of the previous background visible.
> 
> But the redrawing itself appears to work; only the part that does NOT need
> to be redrawn is wrong.
> 
> Does this build have a newer Qt lib?

Could you please tell me which version is expected, I'll check which version is used there and compare.

> In what environment does this happen? QEMU? Also VirtualBox? Or where else?

Seems like this happens in QEMU, but also we have better coverage on QEMU. So I can check on other backends (e.g. s390x) and tell you the result.

On VirtualBox I didn't try, but I used VirtualManager which is using kvm and the manual steps that I provided you, the ones from VirtualManager.
Comment 13 Stefan Hundhammer 2021-10-13 18:44:56 UTC
The new tabs arrived with libyui-qt15-4.2.12.
Comment 14 Stefan Hundhammer 2021-10-13 18:51:11 UTC
There were delays with those changes, but they eventually were accepted in late August after skipping a number of versions:

  https://build.suse.de/request/show/249077
Comment 15 Stefan Dirsch 2021-10-22 16:06:17 UTC
> > Could you please tell me which version is expected, I'll check which version is used there and compare.
> The new tabs arrived with libyui-qt15-4.2.12.

@Oleksandr So could you provide this information, please?
Comment 16 Stefan Hundhammer 2021-10-25 09:33:57 UTC
From the screenshots we can clearly see that this started happening before the new tabs arrived: The tabs are stretching the entire width, and there are no frames all around the tab, only at the top.

So it might be a problem with backing store, either on the X11 side or on the Qt side: Qt is rendering everything into a pixel buffer starting with Qt 5.x and transfers that buffer to the X server / Wayland display whenever necessary; it doesn't use Xlib primitives for drawing operations anymore since the Qt 4.x times.

Can we narrow this down further?

Do we know if it also happens in a Wayland environment?

Is there a difference between affected scenarios what X extensions are available? 

Or OpenGL with hardware support / software rendering only?
Comment 17 Stefan Hundhammer 2021-10-25 09:37:48 UTC
More background info about the tabs in libyui-qt:

https://github.com/libyui/libyui/issues/20
https://github.com/libyui/libyui/pull/31

(accepted to IBS in late August; see comment #14)
Comment 18 Stefan Dirsch 2021-10-25 11:35:41 UTC
(In reply to Stefan Hundhammer from comment #16)
> From the screenshots we can clearly see that this started happening before
> the new tabs arrived: The tabs are stretching the entire width, and there
> are no frames all around the tab, only at the top.

Ok. So this answers comment#15. Nevertheless I think we should try again with new tabs. Possibly 
with that change the issue goes away (yes, that then would be by accident!).

> So it might be a problem with backing store, either on the X11 side or on
> the Qt side: Qt is rendering everything into a pixel buffer starting with Qt
> 5.x and transfers that buffer to the X server / Wayland display whenever
> necessary; it doesn't use Xlib primitives for drawing operations anymore
> since the Qt 4.x times.
> 
> Can we narrow this down further?

Not sure how ...

> Do we know if it also happens in a Wayland environment?

Yes, that should be tested.

> Is there a difference between affected scenarios what X extensions are
> available? 

You mean X extension savailable on Xorg and Xwayland, if it works on Xwayland? I assumed we would use
Qt Wayland backend for YaST when running on a Wayland session ...

> Or OpenGL with hardware support / software rendering only?

Since we're talking about Qemu I'm pretty sure software rendering is active here.
Comment 19 Oleksandr Orlov 2021-10-25 15:20:25 UTC
(In reply to Stefan Hundhammer from comment #16)

So, this is the info that I've collected so far:

1. The issue is not reproduced on SLE15-SP4 Build 15.1 (released 19.07.2021), but it is reproduced on Build 18.1 (released 28.07.2021).
2. Version of libyui-qt15 on Build 15.1 (where the issue is NOT happen): 4.1.4-3.3.1
Version of libyui-qt15 on Build 18.1 (where the issue is NOT happen): 4.2.16-1.1
3. X -version (SLE15-SP4 Build 15.1)

X.Org X Server 1.20.3
X Protocol Version 11, Revision 0
Build Operating System: openSUSE SUSE LINUX
Current Operating System: Linux localhost 5.3.18-57-default #1 SMP Wed Apr 28 10:54:41 UTC 2021 (ba3c2e9) x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.3.18-57-default root=UUID=be3c5168-d4cb-47a6-968f-e9e9c8feeb63 splash=silent resume=/dev/disk/by-uuid/cca778a2-8b15-4470-b507-b76184bf030d mitigations=auto quiet
Build Date: 14 April 2021  12:00:00PM
 
Current version of pixman: 0.34.0
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.

X -version (SLE15-SP4 Build 18.1):

X.Org X Server 1.20.3
X Protocol Version 11, Revision 0
Build Operating System: openSUSE SUSE LINUX
Current Operating System: Linux localhost 5.14.5-1-default #1 SMP Fri Sep 24 12:44:40 UTC 2021 (24dfde2) x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.14.5-1-default root=UUID=0abb1ac5-611c-4023-baac-72e9baf016ce splash=silent resume=/dev/disk/by-uuid/59fc71c1-32da-460e-aca9-e814c52f5d68 mitigations=auto quiet
Build Date: 24 September 2021  12:00:00PM
 
Current version of pixman: 0.40.0
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.


> Do we know if it also happens in a Wayland environment?

I checked, it is not reproduced on GNOME with Wayland and on IceWM window manager. Only reproduced on GNOME with x11.

> Is there a difference between affected scenarios what X extensions are
> available? 

The same set of X extensions is used on both builds:
number of extensions:    27
    BIG-REQUESTS  (opcode: 133)
    Composite  (opcode: 142)
    DAMAGE  (opcode: 143, base event: 91, base error: 152)
    DOUBLE-BUFFER  (opcode: 145, base error: 153)
    DPMS  (opcode: 147)
    DRI2  (opcode: 154, base event: 119)
    GLX  (opcode: 151, base event: 95, base error: 158)
    Generic Event Extension  (opcode: 128)
    MIT-SCREEN-SAVER  (opcode: 144, base event: 92)
    MIT-SHM  (opcode: 130, base event: 65, base error: 128)
    Present  (opcode: 148)
    RANDR  (opcode: 140, base event: 89, base error: 147)
    RECORD  (opcode: 146, base error: 154)
    RENDER  (opcode: 139, base error: 142)
    SECURITY  (opcode: 137, base event: 86, base error: 138)
    SHAPE  (opcode: 129, base event: 64)
    SYNC  (opcode: 134, base event: 83, base error: 134)
    X-Resource  (opcode: 149)
    XC-MISC  (opcode: 136)
    XFIXES  (opcode: 138, base event: 87, base error: 140)
    XFree86-DGA  (opcode: 153, base event: 112, base error: 179)
    XFree86-VidModeExtension  (opcode: 152, base error: 172)
    XINERAMA  (opcode: 141)
    XInputExtension  (opcode: 131, base event: 66, base error: 129)
    XKEYBOARD  (opcode: 135, base event: 85, base error: 137)
    XTEST  (opcode: 132)
    XVideo  (opcode: 150, base event: 93, base error: 155)

> Or OpenGL with hardware support / software rendering only?

OpenGL is not used.

Please, let me know if any additional info is needed.
Comment 20 Stefan Dirsch 2021-10-25 15:43:45 UTC
Thanks a lot for your testing!
Comment 22 Stefan Hundhammer 2021-10-25 15:53:55 UTC
If you can't access the Trello link, don't worry; this is only our internal tool in the YaST team to move tasks around in our Scrum boards. We try to keep all relevant information in the Bug where it is publicly accessible.
Comment 23 Stefan Hundhammer 2021-10-26 13:26:51 UTC
Oleksandr, since this problem appears in an installed system, we could try to narrow it down with different widget themes and with other non-YaST Qt programs.

On modern desktops like GNOME or KDE, Qt uses special plug-ins even for applications that are not native to the desktop to emulate the native desktop team as closely as possible.

It might be possible that the default theme plug-in is buggy; so please let's try that.

First of all, please install a non-YaST Qt program that also uses tabs and check if the problem appears there as well. You could use QDirStat and open its configuration dialog (Edit -> Configure) and switch tabs.

Then you could try switching the desktop's widget theme to a different one.

To check it independently of the desktop, please install qt5ct and set this environment variable and then start it:

  export QT_QPA_PLATFORMTHEME=qt5ct
  qt5ct

Use the combo box at the top left in its first tab to switch to a different widget theme. There should be at least "Fusion", "Windows" and those that your desktop uses ("Adwaita" and "Adwaita-Dark" for me). Don't forget to hit the "Apply" button.

Does any of that change anything?
Comment 24 Stefan Hundhammer 2021-10-26 13:32:03 UTC
(In reply to Stefan Hundhammer from comment #23)
> On modern desktops like GNOME or KDE, Qt uses special plug-ins even for
> applications that are not native to the desktop to emulate the native
> desktop team as closely as possible.
          ^^^^
          theme
Comment 25 Oleksandr Orlov 2021-10-26 13:50:49 UTC
(In reply to Stefan Hundhammer from comment #23)
> Oleksandr, since this problem appears in an installed system, we could try
> to narrow it down with different widget themes and with other non-YaST Qt
> programs.
> 
> On modern desktops like GNOME or KDE, Qt uses special plug-ins even for
> applications that are not native to the desktop to emulate the native
> desktop team as closely as possible.
> 
> It might be possible that the default theme plug-in is buggy; so please
> let's try that.
> 
> First of all, please install a non-YaST Qt program that also uses tabs and
> check if the problem appears there as well. You could use QDirStat and open
> its configuration dialog (Edit -> Configure) and switch tabs.
> 
> Then you could try switching the desktop's widget theme to a different one.
> 
> To check it independently of the desktop, please install qt5ct and set this
> environment variable and then start it:
> 
>   export QT_QPA_PLATFORMTHEME=qt5ct
>   qt5ct
> 
> Use the combo box at the top left in its first tab to switch to a different
> widget theme. There should be at least "Fusion", "Windows" and those that
> your desktop uses ("Adwaita" and "Adwaita-Dark" for me). Don't forget to hit
> the "Apply" button.
> 
> Does any of that change anything?

Ok. I'll try to do so. The only tough thing is that this issue is not reproduced in some YaST modules that also use Tabs and Menu Items. But I'll try to do my best.
Comment 26 openQA Review 2021-11-12 00:18:26 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: x11-desktopapps-message@64bit-2gbram
https://openqa.suse.de/tests/7619659

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`
Comment 27 Stefan Dirsch 2021-11-15 20:29:54 UTC
Let' s set this to NEEDINFO due to comments #23/25.
Comment 28 openQA Review 2021-11-30 00:09:43 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: x11-desktopapps-message@64bit-2gbram
https://openqa.suse.de/tests/7758510

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`
Comment 29 Stefan Hundhammer 2021-12-09 10:31:29 UTC
See also bug #1187118: Another redraw problem, this time in NCurses.

And AFAICS it also only happens in a QEMU environment (still unconfirmed).
Comment 30 openQA Review 2021-12-24 00:19:00 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: x11-desktopapps-message@64bit-2gbram
https://openqa.suse.de/tests/7888123

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`
Comment 31 openQA Review 2022-01-07 00:32:44 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: x11-desktopapps-message@64bit-2gbram
https://openqa.suse.de/tests/7924498

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`
Comment 32 Stefan Dirsch 2022-01-10 16:30:26 UTC
(In reply to Stefan Dirsch from comment #27)
> Let' s set this to NEEDINFO due to comments #23/25.

Oleksandr, are you still interested?
Comment 33 QK ZHU 2022-01-19 08:10:08 UTC
*** Bug 1190217 has been marked as a duplicate of this bug. ***
Comment 34 Jia Zhaocong 2022-01-20 07:30:54 UTC
Adding some of my observations:

I think the same thing happens on evolution testing: https://openqa.suse.de/tests/7977616#step/evolution_mail_imap/20 , the left part tab list is not refreshed correctly.

From comment#19, I see that kernel is upgrade from 5.3 to 5.14, maybe this kernel change caused this bug?


@Oleksandr, I can not reproduce the evolution glitch in VM.  I want to ask your attachment 852807 [details] (the gif), is it manually reproduced or captured from openqa?
Comment 35 Oleksandr Orlov 2022-01-20 14:00:36 UTC
(In reply to Stefan Hundhammer from comment #23)
> Oleksandr, since this problem appears in an installed system, we could try
> to narrow it down with different widget themes and with other non-YaST Qt
> programs.
> 
> On modern desktops like GNOME or KDE, Qt uses special plug-ins even for
> applications that are not native to the desktop to emulate the native
> desktop team as closely as possible.
> 
> It might be possible that the default theme plug-in is buggy; so please
> let's try that.
> 
> First of all, please install a non-YaST Qt program that also uses tabs and
> check if the problem appears there as well. You could use QDirStat and open
> its configuration dialog (Edit -> Configure) and switch tabs.
> 
> Then you could try switching the desktop's widget theme to a different one.
> 
> To check it independently of the desktop, please install qt5ct and set this
> environment variable and then start it:
> 
>   export QT_QPA_PLATFORMTHEME=qt5ct
>   qt5ct
> 
> Use the combo box at the top left in its first tab to switch to a different
> widget theme. There should be at least "Fusion", "Windows" and those that
> your desktop uses ("Adwaita" and "Adwaita-Dark" for me). Don't forget to hit
> the "Apply" button.
> 
> Does any of that change anything?

Tried everything from above and the issue was not reproduced. As I said, this is not happened even not in all YaST modules. And it is not only related to Tabs, the issue may be reproduced when navigating through partitioner (where tabs are not used), which I shown in attached screeenshot.
Comment 36 Oleksandr Orlov 2022-01-20 14:01:53 UTC
(In reply to Jia Zhaocong from comment #34)
> @Oleksandr, I can not reproduce the evolution glitch in VM.  I want to ask
> your attachment 852807 [details] (the gif), is it manually reproduced or
> captured from openqa?

The issue on my gif is reproduced manually. This scenario is not used in openQA.
Comment 37 Oleksandr Orlov 2022-01-20 14:09:43 UTC
(In reply to Stefan Dirsch from comment #32)
> (In reply to Stefan Dirsch from comment #27)
> > Let' s set this to NEEDINFO due to comments #23/25.
> 
> Oleksandr, are you still interested?

We still interested in this issue to be fixed and now we see other people who reporting this.

Unfortunately, I can not tell you more then I already provided. I just checked the steps that I written in the first comment on build 81.1 and the issue is still reproduced.

So, I guess it will be more effective if developers will try to reproduce the issue with the steps provided.

From my side, I can share you an environment if you need it, just contact me in Slack (Oleksandr Orlov or #team-lsg-qe-yast channel) and support with reproducing the issue. If you would like to install the system by yourself and try it out, you can use last iso: https://openqa.suse.de/tests/7977497/asset/iso/SLE-15-SP4-Online-x86_64-Build81.1-Media1.iso
Comment 38 Stefan Dirsch 2022-01-25 15:58:51 UTC
Looks like the issue is not part of the OpenQA video here

https://openqa.suse.de/tests/8011125/video?filename=video.ogv
Comment 39 Stefan Dirsch 2022-01-25 16:07:38 UTC
(In reply to Oleksandr Orlov from comment #36)
> (In reply to Jia Zhaocong from comment #34)
> > @Oleksandr, I can not reproduce the evolution glitch in VM.  I want to ask
> > your attachment 852807 [details] (the gif), is it manually reproduced or
> > captured from openqa?
> 
> The issue on my gif is reproduced manually. This scenario is not used in
> openQA.

Can you describe your environment for this producer, please? Is this a regular installation on bare metal? Which gfx card? Or VM in QEMU (which gfx emulation did you use?)? Or installation via VNC? Or installation via ssh?
Comment 40 Stefan Hundhammer 2022-01-26 09:47:22 UTC
Over night I got the idea that this might be connected to the libyui REST API (which OpenQA uses), so I installed those packages to check if I can reproduce the problem then; but sadly no, I still cannot reproduce this.

That's those packages:

- libyui-rest-api15
- libyui-qt-rest-api15
- libyui-ncurses-rest-api15

The idea was that the REST API might change the timing behavior, or it might block signals for a short time, or something like that; but I could not observe any change with or without it.
Comment 41 Oleksandr Orlov 2022-01-27 14:45:03 UTC
(In reply to Stefan Hundhammer from comment #40)
> Over night I got the idea that this might be connected to the libyui REST
> API (which OpenQA uses), so I installed those packages to check if I can
> reproduce the problem then; but sadly no, I still cannot reproduce this.
> 
> That's those packages:
> 
> - libyui-rest-api15
> - libyui-qt-rest-api15
> - libyui-ncurses-rest-api15
> 
> The idea was that the REST API might change the timing behavior, or it might
> block signals for a short time, or something like that; but I could not
> observe any change with or without it.

So, again. The issue that I shown in Steps to reproduce is just ONE in a row of a lot of cases. And the reason why I placed the steps is that it is easy to reproduce it manually with almost 100% result, while following them. 

The problem is more wide and touches a lot of YaST modules, which is seen from openQA jobs.

Also, we don't use libyui-rest-api yet in module testing, so it is definitely not related to it. Also, when I reproduced it manually, I didn't use libyui-rest-api as well.
Comment 42 Oleksandr Orlov 2022-01-27 14:54:46 UTC
(In reply to Stefan Dirsch from comment #39)
> (In reply to Oleksandr Orlov from comment #36)
> > (In reply to Jia Zhaocong from comment #34)
> > > @Oleksandr, I can not reproduce the evolution glitch in VM.  I want to ask
> > > your attachment 852807 [details] (the gif), is it manually reproduced or
> > > captured from openqa?
> > 
> > The issue on my gif is reproduced manually. This scenario is not used in
> > openQA.
> 
> Can you describe your environment for this producer, please? Is this a
> regular installation on bare metal? Which gfx card? Or VM in QEMU (which gfx
> emulation did you use?)? Or installation via VNC? Or installation via ssh?

For manual reproducing, I just used Virtual Machine Manager with default settings. I attached them, please see vm-settings.xml

Then just default installation with Desktop Module (pressing "Next" button on all screens and filling in all the required fields).

For openQA failures, I already pasted the configuration of qemu in https://bugzilla.suse.com/show_bug.cgi?id=1191112#c11.

In openQA there are different YaST modules used and steps are more complex, but the failures are stable (they are not sporadic), e.g. https://openqa.suse.de/tests/8030611#step/yast2_control_center/86, https://openqa.suse.de/tests/8030611#step/yast2_lan_restart_bond/24

For example, here it is s390x (Login Settings is selected but the right section is still showns a content for Security Overview), and this proofs that issue is not only reproducible on x64: 
https://openqa.suse.de/tests/8014875#step/yast2_security/23
Comment 43 Oleksandr Orlov 2022-01-27 14:55:18 UTC
Created attachment 855665 [details]
vm-settings.xml
Comment 44 Stefan Dirsch 2022-01-27 15:20:24 UTC
(In reply to Oleksandr Orlov from comment #43)
> Created attachment 855665 [details]
> vm-settings.xml

So VGA type appears to be QXL. Thanks.
Comment 45 Stefan Dirsch 2022-02-09 17:24:59 UTC
I'll have a look myself ASAP. Meanwhile it would be good to know, whether you see the same issues when using cirrus or std as vga type.
Comment 46 openQA Review 2022-02-23 23:58:32 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: yast2_ncurses
https://openqa.opensuse.org/tests/2205146

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`
Comment 47 openQA Review 2022-03-24 00:05:07 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: yast2_ncurses
https://openqa.opensuse.org/tests/2255743

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`

Expect the next reminder at the earliest in 56 days if nothing changes in this ticket.
Comment 48 Stefan Weiberg 2022-03-29 06:59:02 UTC
Is there any update on this issue? I can see quite some soft fails in openQA due to this bug.
Comment 49 Stefan Dirsch 2022-03-29 09:12:46 UTC
(In reply to Stefan Weiberg from comment #48)
> Is there any update on this issue? I can see quite some soft fails in openQA
> due to this bug.

No. What do you mean with "Soft fails in openQA" here? Can you give me examples?

(In reply to Stefan Dirsch from comment #45)
> I'll have a look myself ASAP. Meanwhile it would be good to know, whether
> you see the same issues when using cirrus or std as vga type.

This hasn't been answered either. It would have been good to know, if these issues are limited to usage of QXL.
Comment 50 Stefan Weiberg 2022-03-29 09:42:20 UTC
This test is for example marked as "softfailed" linked to this bug:
https://openqa.suse.de/tests/8405670#step/scc_registration/5

Soft failed refers to a bug found in a test case, which is flagged but has a workaround available to not let the test hard fail.
Comment 51 Stefan Dirsch 2022-03-29 10:00:56 UTC
Ok. Thanks for explanation.
Comment 52 George Gkioulis 2022-03-30 14:29:44 UTC
(In reply to Stefan Dirsch from comment #45)
> I'll have a look myself ASAP. Meanwhile it would be good to know, whether
> you see the same issues when using cirrus or std as vga type.

Hi, I am able to reproduce this issue both for standard VGA and Cirrus VGA in qemu.

steps to reproduce:
1. open terminal in gnome shell
2. su
3. yast2 bootloader
4. alternate between Kernel Parameters tab and Bootloader Options tab until, in Kernel Parameters tab, the Optional Kernel Command Line Parameter entry glitches. I will attach example screenshot.

Of course there are multiple ways of reproducing this glitch in yast2 Qt, this is just one scenario.
Comment 53 George Gkioulis 2022-03-30 14:30:32 UTC
Created attachment 857517 [details]
Optional Kenrel Command Line Parameter glitched entry
Comment 54 George Gkioulis 2022-03-30 14:31:18 UTC
Created attachment 857518 [details]
Optional Kenrel Command Line Parameter entry fixed by clicking on it
Comment 55 George Gkioulis 2022-03-31 08:50:29 UTC
I
Comment 56 openQA Review 2022-04-14 23:55:03 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: remote_vnc_controller
https://openqa.suse.de/tests/8503570

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`

Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.
Comment 57 Stefan Weiberg 2022-04-27 17:06:42 UTC
Do you have any update on this issue?
Comment 58 Stefan Dirsch 2022-04-27 17:26:27 UTC
Unfortunately, no. :-(
Comment 59 Stefan Weiberg 2022-05-03 09:21:44 UTC
Is there any assistance you require to get this resolved? It would be great to have this resolved in SUSE:SLE-15-SP4:GA prior to the GMC.
Comment 60 Stefan Dirsch 2022-05-03 10:48:07 UTC
Let's be honest. This isn't a trivial task. I even have no clue how to investigate this at all. I think it's unrealistic to hope for a fix still for GMC.
Comment 61 openQA Review 2022-05-18 00:50:29 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: qam-allpatterns+addons
https://openqa.suse.de/tests/8648310

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`

Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.
Comment 62 openQA Review 2022-06-15 01:20:54 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: qam-allpatterns+addons
https://openqa.suse.de/tests/8930776

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`

Expect the next reminder at the earliest in 56 days if nothing changes in this ticket.
Comment 63 Jonathan Rivrain 2022-06-16 12:22:04 UTC
The issue is still present in GM, now visible in maintenance : https://openqa.suse.de/tests/8964840#step/yast2_bootloader/17
Comment 64 openQA Review 2022-07-01 00:40:36 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: qam-allpatterns+addons
https://openqa.suse.de/tests/9014036

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`

Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.
Comment 65 openQA Review 2022-07-29 01:07:30 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: gnome
https://openqa.suse.de/tests/9226173

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`

Expect the next reminder at the earliest in 56 days if nothing changes in this ticket.
Comment 66 Stefan Hundhammer 2022-08-17 12:57:52 UTC
See also TW bug #1199020.
Comment 67 Stefan Hundhammer 2022-08-18 12:53:13 UTC
*** Bug 1199020 has been marked as a duplicate of this bug. ***
Comment 68 Steffen Winterfeldt 2022-08-19 07:49:03 UTC
Would you mind opening up the bug to the community by changing the product to
PUBLIC SUSE Enterprise Server?
Comment 70 Stefan Hundhammer 2022-08-29 14:33:06 UTC
After some more debugging it is possible that this is a problem in our .qss style sheets that we use during installation, or a problem in Qt's style sheet engine.

See 

  https://bugzilla.suse.com/show_bug.cgi?id=1199020#c42
  https://bugzilla.suse.com/show_bug.cgi?id=1199020#c43

This might be the same problem after all. Investigating.
Comment 71 Stefan Hundhammer 2022-08-31 08:14:31 UTC
From what we learned in bug #1199020, this is almost certainly not an X11 bug.

Rather, it's a weird combination of Qt style sheets and the Qt libs behaving in a weird way when a QWidget property autoFillBackground is set while it also has a QSS style sheet assigned that sets a background (color or pixmap or gradient).

I am positive that this is now fixed with

  https://github.com/libyui/libyui/pull/81

which introduces a workaround for this situation.
Comment 72 Joaquín Rivera 2022-09-02 06:41:40 UTC
Hi, it is resolved, but is there any rpm to take a look? I didn't see it yet in OBS (yast head or new build for SLE-15-SP5). At least for the libyui version.
Could you please indicate what combination of package should resolve it?

If it works, it would be great (specially for old automation with needles which still exists) and we should have it as well via maintenance update for SLE-15-SP4 where is messing up with many tests.
Comment 73 George Gkioulis 2022-09-12 11:08:02 UTC
Hi, as Joaquin said, since this is marked as resolved could we have access to an .rpm file to verify the bug? Also when do we expect this to land as maintenance update for 15-SP4?
Comment 74 Stefan Hundhammer 2022-09-13 09:44:53 UTC
It turned out that autosubmission didn't work properly. Now it should thanks to @lslezak. The RPM should arrive shortly.
Comment 75 Stefan Hundhammer 2022-09-13 09:45:45 UTC
The 15-SP4 backport is on our radar.
Comment 76 Stefan Hundhammer 2022-09-14 15:08:41 UTC
Trello card for the backport to SLE-15 SP4:

https://trello.com/c/t8bQXqjU/
Comment 77 Stefan Hundhammer 2022-09-15 08:18:03 UTC
PR for the backport to SLE-15 SP4:

  https://github.com/libyui/libyui/pull/83
Comment 78 George Gkioulis 2022-10-10 08:09:48 UTC
It seems that we are encountering the same issue again, despite the fix having landed in the new build:
https://openqa.suse.de/tests/9681079#step/iscsi_client/53

I will reopen the bug (feel free to undo this if I am wrong, or if I need to create a new bug).
Comment 79 Stefan Hundhammer 2022-10-10 08:14:44 UTC
This is becoming the neverending story: We are at comment 79 now.

Please open a new bug; this is already much too confusing with all the attachments from all the different attachments from all the different cases.
Comment 80 George Gkioulis 2022-10-10 08:52:21 UTC
(In reply to Stefan Hundhammer from comment #79)
> This is becoming the neverending story: We are at comment 79 now.
> 
> Please open a new bug; this is already much too confusing with all the
> attachments from all the different attachments from all the different cases.

Thank you Stefan, I have created https://bugzilla.suse.com/show_bug.cgi?id=1204176
Comment 81 Felix Miata 2022-10-10 12:25:21 UTC
(In reply to George Gkioulis from comment #80)
> (In reply to Stefan Hundhammer from comment #79)
> > This is becoming the neverending story: We are at comment 79 now.

> > Please open a new bug; this is already much too confusing with all the
> > attachments from all the different attachments from all the different cases.
 
> Thank you Stefan, I have created
> https://bugzilla.suse.com/show_bug.cgi?id=1204176

Bug 1204176 is not accessible to openSUSE users. This bug is.