Many thanks for your report.

It this just an issue when connecting via RDP or on the screen attached to the RPi directly as well?

Could you try to connect via VNC?
Tiny hassle-free (ancient) TightVNC executable: https://www.tightvnc.com/download/1.3.10/tightvnc-1.3.10_x86_viewer.zip
Type in your RPi IP followed by :1, like 192.168.0.100:1, then hit Connect.

Ok, I will try it.
Thanks for your advice!!
I will post comment with screenshot to next post.

(Add)
I found similar issue
numixproject/numix-gtk-theme#206
https://bbs.archlinux.org/viewtopic.php?id=196061
I will try it too.

I don’t know why, but now I could not see any black border.
I will close issue for temporarily or permanently

how to erase black border

1. Open Window Manager Tweaks by Application or Setting Manager.
2. Go Tab "Compositor"
3. Check to

• Enable display compositing

That`s all!

Screenshot

Before

After

Hope you could solve it!

Window opacity seems to be what causes the black border when compositing is not enabled, or window shadows. We install xcompmgr generally with desktops to provide this feature but I'm not sure how it is invoked, if its as well via VNC and/or XRDP.

Interesting. In my case display compositing was enabled by default, xcompmgr added as Xfce autostart entry, being invoked for persistent VNC session as well as for separate XRDP session. Now I also see that we explicitly install it as autostart entry (/etc/xdg/autostart/xcompmgr.desktop) when dietpi-software installs Xserver, however this provides composition is does not necessarily enable it for the desktop.

I tested to disable compositing on XRDP session and disable Firefox title bar and cannot see any black border here, shadows and window/menu transparency is disabled automatically.
On pure VNC session at least with the very old tiny TightVNC viewer, compositing does not work at all. Enabling/disabling it on the settings has no effect. Interestingly Firefox seems to recognise this somehow an does not show the option to enable/disable title bar. Even when I change the settings back on XRDP, on VNC the title bar is still shown while other style settings like dark mode are correctly applied.
I didn't test on local session, would be interesting how all those work together or not.

@TamaTamaGoGo
Did you choose a specific theme for the window manager or just default (actually your screenshots look like default)?
And one quick note re-reading your reproduce instructions: Firefox is pre-installed with all our desktops as default browser, so hitting the browser icon on panel will start it. probably we should replace it with the Firefox icon 😉. But no harm with apt-get install firefox-esr it should just tell you that the package is installed already.

Verified on local session:

• xcompmgr is started with -a flag which is faster but disables a few features and it looks like hiding Firefox title bar is one of them.
• It can be easily verified by opening a terminal and doing:

killall xcompmgr
xcompmgr -a # See black border, stop via ctrl+c
xcompmgr # See no black border

Not sure how to handle best. Remove -a flag when Xfce is installed? Add a hint to online docs otherwise?

... found out now that Xfce with default xfwm4 window manager has integrated compositing. E.g. when disabling xcompmgr, starting an Xfce session and trying to start xcompmgr throws an error message that xfwm4 is already the running compositor. Also the related settings only have an effect when xfwm4 does compositing. In the local session, xcompmgr -a was started before xfwm4, in which care it is the active compositor which is why on my test the settings had no effect. Using xfwm4 also allows all settings to work fine on VNC. Even when disabling compositing now, there is no black border around Firefox.

@TamaTamaGoGo
Please do:

rm /etc/xdg/autostart/xcompmgr.desktop
apt purge xcompmgr

Logout and login and you should be able to disable compositing in settings, which might speed up experience on slow devices and still have a nice Firefox window.

So we need to skip xcompmgr install on Xfce.

Fixed for new Xfce installs: b94feb2
Changelog: a6467b8
Adjust call on Kodi launch on C2: abbd217

(Actually DietPi occurred some error at boot, so I burned with test “aarch64 (amv8)”)
aarch64 works application with no black bolder.
Um.. I will try armv7l with another SD to check...
(Added : thanks for correspondence!
Sorry for the inconvenience)

Fixed for new Xfce installs: b94feb2
Changelog: a6467b8
Adjust call on Kodi launch on C2: abbd217

Is the Firefox-esr automatically install when install xfce by DietPi-Software?
sudo apt-get install firefox-esr

Said Firefox-esr was already installed.

(Added : b94feb2 Code seems firefox-esr will automatically install)

Reply for research

@MichaIng
I will research it at my raspi4 with no remote connection
After researching I will change here to result.
Try at aarch64 version at 2020/07/18, download at 2020/07/17.

No.1

killall xcompmgr
xcompmgr -a 
# See black border, stop via ctrl+c
xcompmgr 
# See no black border

Result
xcompmgr - Not Found

xcompmgr: no process found
bash: xcompmgr: command not found
bash: xcompmgr: command not found

No.2

rm /etc/xdg/autostart/xcompmgr.desktop
apt purge xcompmgr

Result

rm: cannot remove '/etc/xdg/autostart/xcompmgr.desktop': No such file or directory

Reading package lists... Done
Building dependency tree       
Reading state information... Done
Package 'xcompmgr' is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Both of them - Not Found

Think
I think it was caused by new commit made by owner.
In my case instead of xcompmgr, another installed?

Video
(I converted .mp4 to .gif, but takes some times...)
Click to jump big view, so you can read.

I am sorry.
record, convert, download and upload takes about some minutes...

Many thanks for testing, always good to have multiple verifications.

Is the Firefox-esr is automatically installed when I install xfce by DietPi-Software?

Yes it is, although I'm thinking to change this somewhere in the future, as we offer Chromium as well, of course the repo has many other browsers and some might not need a browser at all. Probably adding Firefox as separate install option instead and for user convenience add a browser selection menu when any desktop is installed?

What a good idea!
I think there have man whose want to use Chromium, but another want use FireFox.
Sorry to trouble you, but if available to add, I want to order you to add it future.

(I think install with DietPi-Software is easiest...
I want to use epiphany-browser or midori too.)

Don't we discuss at new issue?

Don't we discuss at new issue?

Good idea, feel free to open this as a feature request, reasonable indeed 👍.

I will open...
(Added : added issue with template Feature Request
Link is ↓)
#3683

(Actually DietPi occurred some error at boot, so I burned with test “aarch64 (amv8)”)
aarch64 works application with no black bolder.
Um.. I will try armv7l with another SD to check...
(Added : thanks for correspondence!
Sorry for the inconvenience)

Um...
It seems xfce default enable display compositing.
@MichaIng
Please check the settings of Window Manager Tweaks > Compositor > Enable display compositing
In my case, when I install xfce freshly, I couldn't see black bolder.
But setting disable, black bolder showed again!
It may affect why I couldn't see any black bolder.
(But some thinking why the black bolder appeard when I installed xfce with DietPi-Software
[a week ago]
Did you commit and debug it?)

Did you apt purge xcompmgr and reboot and then with compositing disabled you see a black border?

Yes Xfce has internal compositing as mentioned above, however disabling it without having xcompmgr -a doing some light server-side compositing didn't lead to black boarders in my case. I believe that xcompmgr -a was the culprit since it makes applications believe that compositing is available while it is only a very limited set. So i.e. Firefox thought it can use compositing to remove the window border but xcompmgr -a does not allow this functionality but a bulky alternative that leads to the black border.

bash: xcompmgr: command not found

???
#3665 (comment)

Log said

rm: cannot remove '/etc/xdg/autostart/xcompmgr.desktop': No such file or directory

Ah sorry, I misunderstood you post. Yeah so everything is as it should be.

Strange that even without xcompmgr Firefox shows the black border. In my case it works fine:

But a small white border is there in both cases that I cannot see in your case. Ahh... closing and re-opening Firefox made the little white boarder go away. Even the tiny white border is still much better then the big black one that I only get when disabling Xfce-internal compositing first and enabling xcompmgr -a instead:

Hm...
I think owner had committed b94feb2.
And it looks like in my case
xcompmgr
would not installed?

I think after disable display compositing, and when you could not see any black bolder, in my case logout and login and appeared black one.
logout by xfce logout GUI and
startx
and open FireFox-esr, I could see black bolder...

Um, I will try armv6 version what the black bolder appeared.

Reply for research

@MichaIng
I will research it at my raspi4 with no remote connection
After researching I will change here to result.
Try at armv6 version at 2020/07/17, download at 2020/07/08.

No.1

killall xcompmgr
xcompmgr -a 
# See black border, stop via ctrl+c
xcompmgr 
# See no black border

Result

No.2

rm /etc/xdg/autostart/xcompmgr.desktop
apt purge xcompmgr

Result

Think

Video
(I converted .mp4 to .gif, but takes some times...)
Click to jump big view, so you can read.

Many thanks for doing so much tests. However from our end we cannot do more. If Firefox requires full (instead of limited xcompmgr -a) composing, then it simply needs to be enabled, it is by default anyway on Xfce. xcompmgr -a is also bad as a default on Xfce since it breaks their compositing options GUI completely, which is not a nice experience for users without knowing the background. We added this for performance reasons from what I read (before my time) but best performance one gets with disabled compositing, not with a limited xcompmgr -a. The latter only overrides/blocks defaults, but better to leave choice to user transparently.

Thank you for your help!
I hope it will never happen future.

For now, I will close this issue.
Or maybe I will close it forever.
Thanks!

Research

(again..., I am sorry for reoepn this issue but I noticed it so I reopened and comment it...)
I installed xcompmgr and when I run

xcompmgr

Video
Video is the easiest way to see what I tried

Note
No.1
run command

xcompmgr

Result
It said Xfwm4 is already running

no.2
Check xfwm4

xfwm4

No.3
Relpace screen with Compotior OFF

xfwm4 --compositor=off --replace

Result
Um...
I can see black bolder around gedit (text editor)...
It may affect...

After
Relpace screen with Compotior ON

xfwm4 --compositor=on --replace

Result
I couldn't see any black bolder around.

Little Note
In my case, DietPi-Software automatically installed xfwm4 instead of xcompmgr.
But when I set Compositor to OFF, I could see black bolder, so that's similar to xcompmgr.

Yes that is all expected. The xfce package itself pulls xfwm4 as dependency, it is the default window manager of xfce and has compositing included (in opposition to e.g. LXDE), hence the incompatibility with xfwm4 internal compositing + xcompmgr external compositing. That was what the whole issue was about and why we don't install xcompmgr anymore 😉.

Hiding the window title in Firefox is a compositing feature, hence it requires a fully-fledged compositing implementation, else the black border, so keep it enabled or re-enable Firefox window title bar.

Ok, I understood why!
Thanks give me advice and hint and changed commit!
Now I will close.