Right click on Brave/Firefox and see a black border/red border

I thought it would be better to post it here…

Since the other day, in the browser Brave of APPVM and DisposableVM, a black frame appears when right clicking. Recently an update has come in Debian12Xfce, but even after updating and rebooting, the same symptom appears.In FirefoxESR, right click shows a red lined frame.

In addition, I had previously heard about the network disconnecting after starting WindowsQube (sys-firewall dropping), but I have confirmed that the same problem occurs even after removing WindowsQube. sys-firewall can be started Internet connection is still available, so it seems to be a good idea to restart the system each time.

I think black filling between blue frame and white context menu in brave is because you have dark theme in brave. If you change theme from dark to light then it should be white.
The same goes for firefox, if you set dark theme in firefox then it’ll have black filling between red frame and white context menu as well.

Can you describe your issue with sys-firewall in more details?
What do you mean by sys-firewall dropping?

1 Like

Thank you, the Brave theming is the same as Linux and I was using the light theme for both Firefox/Brave. FirefoxESR was pre-installed and I did not change any settings.

The sys-firewall shutdown means that, for example, when I start Qube, a notification appears in the top right-hand corner, but after QubesOS starts, the internet connection is available for about one minute, then a notification appears in the top right-hand corner saying that the sys-firewall has been shutdown, and after that, the internet connection is lost. The internet connection is no longer available.

If the sys-firewall is started again after it has been shut down, the internet connection will not be disconnected after that.

I’ve got the same issue since I reinstalled Brave on fedora-40 two days ago.
I tried it with bot the Flatpak & the “standard” version, the error seems to be on both.

Did you get this error since you use fedora-40?

The Flathub page of brave already warns of a legacy windowing system.. Maybe fedora-40 changed something?

If not, I have another idea I didn’t try yet: check the compositor settings in the window manager tweaks in the qubes. I don’t this this is the origin of the error because then the same error would occur on other apps too, but maybe it’s a try worth.

1 Like

Thanks. I have Debian12-xfce. I have received several update notifications for debian12-xfce recently, and I did the update, and I must not have received any update notifications for Brave itself, so there may be a problem with the QubesOS side of the update with the Brave windowing system. However, Firefox reported that it has a red border, which I think is normal, my apologies.

After checking it again it doesn’t seem to be the same way for firefox, the space between red frame and menu is transparent for firefox:
firefox-menu
I’m not sure what happened with brave in your qube.

Maybe there is some issue with your sys-firewall template.
For example some issue with its system storage.
Maybe it’s trying to fix filesystem errors during the qube start or you’ve increased the template storage size but didn’t start/stop the template after this change so on each app qube start it’s resizing the filesystem.
Try to start/stop the sys-firewall template and reboot to check if it’ll fix the issue.
You can also check the system storage usage in the template, maybe it’s out of free space.

1 Like

As for Brave, there seems to be a similar case with someone else than me. I’ve had several notifications of updates in the last few days, so maybe that’s the reason? I think.

Oh! Indeed, the Private storage max size in the sys-firewall template is set to 50.0GB. initial memory:500MB , MaxMemory to 20GB. You have been warned in red, so I will reboot with 500MB/2GB and storage max size set to 15GB. This may solve the problem.

Private storage size of your template shouldn’t matter since it’s not used by app qubes, only System storage of your template is used by the app qubes so check the System storage of your template.
Check the output of this command in your template terminal to see the % of storage usage:

df -h

The System storage is mounted on “/”.

1 Like

debian-12-xfce.

df -h produced this output.

ファイルシス       サイズ  使用  残り 使用% マウント位置
/dev/mapper/dmroot    20G  9.8G  8.7G   53% /
none                  20G  9.8G  8.7G   53% /usr/lib/modules
devtmpfs             4.0M     0  4.0M    0% /dev
tmpfs                1.0G     0  1.0G    0% /dev/shm
tmpfs                 70M  712K   69M    2% /run
tmpfs                5.0M     0  5.0M    0% /run/lock
/dev/xvdb            2.0G  686M  1.3G   36% /rw
tmpfs                 35M   80K   35M    1% /run/user/1000

I had Brave 1.66.118 installed from deb repository in debian-12-minimal template and it worked without this issue.
Now I’ve updated the template and Brave updated to version 1.67.116 and now I have the same issue.
So I guess some change in latest Brave version is causing this issue.

1 Like

It looks OK.
Do you have disposable sys-firewall qube?
Did you change sys-firewall Private storage size?
What’s the sys-firewall Private storage size right now?

Related issue:

1 Like

It is unclear whether it is disposable or not, but the Template in sys-firewall is default-dvm(current), so it is considered disposable.

Private storage max size was pulling the default-dvm setting, or I made it 15GB, and Maxsize of memory was set to 2GB, but Storage is back to the original 50GB even if memory is left as it is. As for memory, the warning is no longer displayed and the sys-firewall no longer crashes. Thank goodness.

Yes, it’s disposable.

If you want to change the sys-firewall Private storage size then don’t change it for sys-firewall itself, change it for sys-firewall disposable template default-dvm, since disposable sys-firewall is using the Private storage from its disposable template. Also don’t forget to start/stop the qube (default-dvm) after changing it’s Private storage size so it’ll take effect and resize the storage.

Glad to hear that the issue is fixed for you.

1 Like

Might be similar to this issue: Fedora 37 Nautilus: broken widget GtkPopoverMenu (black background instead of transparency) · Issue #8081 · QubesOS/qubes-issues · GitHub

It seems to be an issue with latest Brave when used in DE without compositing, not specific to Qubes OS:

1 Like

We were initially concerned that QubesOS had been hacked, but the ice has broken. I will reinstall the one previous version to resolve the issue.

I’d account for different software implementing their menus their own way. The black background is, as I suppose, when an application tries to draw a fancy composited shadow, but the black filling is due to how the graphics get sanitized. I showcased a similar thing here.

With Firefox I suppose the implementation is different, so that it redraws a visible area as part of the menu windows, on which it then tries to draw the actual menu, faking the transparency. You can try this on your own by dragging the main Firefox window after spawning such a menu and see if the background of the menu changes in real-time.