Icons on the root window don't always refresh when damaged or displayed

[siebenmann]

Upfront Information

Please provide the following information by running the command and providing the output.

• Fvwm3 version (run: fvwm3 --version) fvwm3 1.0.7 (1.0.6a-1-g8670b593) with support for: ReadLine, XPM, PNG, SVG, Shape, XShm, SM, Bidi text, XRandR, XRender, XCursor, XFT, NLS

• Linux distribution or BSD name/version Fedora 36 (but also on Fedora 37)

• Platform (run: uname -sp) Linux x86_64

Expected Behaviour

I use icon-on-root iconified windows with 'IconBox none'. Some of the time when an icon is created or damaged, fvwm3 doesn't repaint the icon and/or the icon title. One of the things that will trigger this is de-iconifying an icon (via a mouse click on it in my setup) where the icon or the expanded icon title overlaps with another icon beside it. The section that the icon or icon title overlapped will not be repainted. Another reproduction appears to be creating iconified windows in a burst. I have a test Wish program for a libX11 related issue that opens two iconified windows in fixed position, and when I run it under fvwm3 the second icon isn't painted either for the icon or for the icon title.

(I use 'Style "*" Icon xlogo32', so xlogo32 is the icon used for both icons. This occurs for other programs with their own icons, such as Firefox.)

Here is that program:

#!/usr/bin/wish
wm title . "iconify example"
pack [button .b2 -text "exit" -command exit]
wm iconposition . 500 500
wm iconify .

toplevel .sec
pack [label .sec.l -text "This is a label"]
pack [button .sec.ok -text "OK" -command {puts "OK"}]
wm title .sec "Another icon"
wm iconposition .sec 600 600
wm iconify .sec

Bringing the mouse cursor to such a non-repainted icon or title will repaint it properly, as will various things that cause large scale refreshes (switching to another virtual screen, putting a window over the area of the icons, etc).

Unfortunately nothing is reported in fvwm3's logging. This issue didn't happen in fvwm2.

[ThomasAdam]

I suspect this is related to #693

[siebenmann]

Merely Maximize and un-maximize doesn't cause any issues for me, and the problem in #693 sounds somewhat different in that my icons definitely don't get repainted either (or painted at all; where they should be is the root window background). But icon failure-to-repaint certainly does sound related. I just checked my configuration and my current configuration does 'Iconify off' to de-iconify things.

Since this happens on deiconification but not when I just move the mouse off an icon with icon text that's extended to damage a neighboring icon, it feels like fvwm3 is losing track of some work it has to do (or not noticing it).

[ThomasAdam]

It's the same underlying cause.

I can't reproduce your scenario though in the way you've put it, but I can in #693 though -- so knowing this is related is important to me when I diagnose this further.

[ThomasAdam]

Well, I managed to bisect this problem to this commit: 5c17c83df4605d2d97999740cf180af983298896

I wonder if the following fix is correct:

[~/p/fvwm3]{1667}[master][2101dcc][!] % git diff                                         
diff --git a/libs/FEvent.c b/libs/FEvent.c
index 7e062118..cf5b35b4 100644
--- a/libs/FEvent.c
+++ b/libs/FEvent.c
@@ -610,7 +610,7 @@ Bool FCheckPeekIfEvent(

        cpa.predicate = predicate;
        cpa.arg = arg;
-       cpa.found = False;
+       cpa.found = True;
        XCheckIfEvent(display, &dummy, _fev_pred_check_peek, (char *)&cpa);
        if (cpa.found == True)
        {

I think by setting cpa.found = False, we're throwing away one Expose event, as by the time we get here, we have one to process. The call to XCheckIfEvent() will either still return true in that case, or false in other circumstances, so I suspect this change is correct.

[siebenmann]

I think that this change wouldn't work and in fact would be dangerous. _fev_pred_check_peek() returns immediately if cpa->found is True, without calling the predicate function and without filling in cpa->event. But FCheckPeekIfEvent assumes that if cpa->found is True, cpa->event is valid. So I think the XCheckIfEvent call would effectively do nothing and then we'd copy stack garbage to *event_return.

[siebenmann]

The other oddity I see in FCheckPeekIfEvent() and what it calls is that if there are multiple events of the same type in the event queue, I think it returns the last such event, because _fev_pred_check_peek() always returns False while stashing the matched event in cpa->event. If there are multiple matching events (eg multiple Expose events), the last one will overwrite all of the other ones in cpa->event.

[siebenmann]

A third oddity: the return value of _prev_weed_is_expose() appears to be mismatched with the value that FWeedAndHandleIfEvents() expects, because FWeedAndHandleIfEvents uses _fev_pred_weed_if() as its predicate function, which seems to have a completely different return code convention than FCheckPeekIfEvent()'s predicate handler. The former expects a 0 to 3 return value, I think, while the latter expects a boolean True/False. _prev_weed_is_expose() is returning true/false (1 or 0), which looks right for FCheckPeekIfEvent() but not FWeedAndHandleIfEvents().

My very rough guess is that _prev_weed_is_expose() should return either 0 (not expose) or 3 (is expose), but I'm not sure about that second return code. I don't think it can return 1 because FWeedAndHandleIfEvents() seems to expect to handle only one event.

[ThomasAdam]

Send a patch, @siebenmann.

[ThomasAdam]

I don't know of @domivogt is about, but he will be able to help. If not, I'll have to look at this at the weekend.

[siebenmann]

I will see if I can understand this code well enough to create a patch that won't subtly break everything, but I'm not certain I will be able to. The event handling here is deep waters in both fvwm and libX11 and I'm not familiar with either. The code doesn't look correct to me as it is but I don't know how to fix it so that it works, in part because every simple fix seems likely to have side effect consequences (eg, consuming only one Expose event in the code called by handle_all_expose(), which seems maybe bad).

My guess is that FWeedAndHandleIfEvents() may need a major reconstruction so that it makes multiple passes over the events, each time retrieving one event to handle and calling the handler function. But that looks like a big infrastructure change and possibly a new API for the function instead of the FWeedIfEvents() one. That assumes that all Expose events have to be handled individually, instead of only doing one at the end.

[siebenmann]

I'm currently running a fvwm3 built with this frankly terrifying hack patch and it hasn't exploded and doesn't seem to have any of the expose issues. Given the code duplication (eg _fev_pred_check_peek_one() is a changed version of the original just for the new FWeedAndHandleIfEvents) and other issues I wouldn't even try to use this as is as a long term, maintainable change, but maybe it can be useful as a starting point.

diff --git a/libs/FEvent.c b/libs/FEvent.c
index 7e062118..b557a712 100644
--- a/libs/FEvent.c
+++ b/libs/FEvent.c
@@ -152,6 +152,20 @@ static Bool _fev_pred_check_peek(
        return False;
 }

+static Bool _fev_pred_check_peek_one(
+        Display *display, XEvent *event, XPointer arg)
+{
+       _fev_check_peek_args *cpa = (_fev_check_peek_args *)arg;
+
+       cpa->found = cpa->predicate(display, event, cpa->arg);
+       if (cpa->found == True)
+       {
+               cpa->event = *event;
+               return True;
+       }
+       return False;
+}
+
 static Bool _fev_pred_weed_if(Display *display, XEvent *event, XPointer arg)
 {
        _fev_weed_args *weed_args = (_fev_weed_args *)arg;
@@ -540,20 +554,28 @@ int FWeedAndHandleIfEvents(
        int (*handler) (Display *display, XEvent *event, XPointer arg),
        XPointer arg)
 {
-       _fev_weed_args weed_args;
+       _fev_check_peek_args cpa;
        XEvent e;
+       Bool found;
+       int count = 0;

        assert(fev_is_invalid_event_type_set);
-       memset(&weed_args, 0, sizeof(weed_args));
-       weed_args.weed_predicate = weed_predicate;
-       weed_args.arg = arg;
-       if (FCheckPeekIfEvent(display, &e, _fev_pred_weed_if,
-                             (XPointer)&weed_args)) {
+       memset(&cpa, 0, sizeof(cpa));
+       cpa.predicate = weed_predicate;
+       cpa.arg = arg;
+       cpa.found = False;
+       do {
+               found = XCheckIfEvent(display, &e, _fev_pred_check_peek_one, (char *)&cpa);
+               if (!found) {
+                       break;
+               }
+               count ++;
                handler(display, &e, arg);
-       }
-       _fev_pred_weed_if_finish(&weed_args);
+               /* ... ?? cks */
+               fev_update_last_timestamp(&e);
+       } while(1);

-       return weed_args.count;
+       return count;
 }

 int FWeedIfWindowEvents(

[siebenmann]

Some comments. First, I have to correct myself about FCheckPeekIfEvent(); it always returns the first matching event, skipping all the rest of them. This means you could use it to implement my 'repeatedly call handler' approach to FWeedAndHandleIfEvents(), but you'd have to invalidate the event after calling the handler function, probably with FEV_INVALIDATE_EVENT(), because otherwise that first event would just get returned over and over. I'm not sure which approach would be better, my direct calls to XCheckIfEvent() (which will pull the event out of the queue), or a version with calls to FCheckPeekIfEvent() and leaving invalidated events in the queue.

[111LUX]

Starting with Debian 12, iconified applications icons disappear on FVWM Restart and fullscreen mode change with any application, when using prebuilt deb fvwm2 and fvwm3 packages from stable repository. After some deduction with that deb package maintainer, was found that the problem is with debian "xthread_fix.patch", that "keep fvwm from crashing with newer versions of xlib", as original fvwm source code may be built in Debian 12, but X will be crashed after some time, wile icons will be fine, with applying this patch (xthread_fix.patch), fvwm stops crashing, but icons become invisible on FVWM restart and applications fullscreen mode change. The opened bug report is existing in bugs.debian — https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1049863

[thanks4opensource]

I'm also experiencing the same/similar problems on the latest fvwm3, and other/previous fvwm3 and fvwm2 versions.

$ uname -sp
Linux x86_64
$ gcc --version
gcc (SUSE Linux) 13.2.1 20230803 [revision cc279d6c64562f05019e1d12d0d825f9391b5553]
$ git clone https://github.com/fvwmorg/fvwm3
...
$ cd fvwm3
$ git --no-pager show --no-patch --pretty="crnt: %h  prnt: %p"
crnt: 018bd066  prnt: 624887fe
$ ./autogen.sh 
$ ./configure
$ make
$ fvwm/fvwm3 --version
fvwm3 1.0.9 (1.0.8-2-g018bd066)
with support for:  ReadLine, XPM, PNG, Shape, XShm, SM, Bidi text, XRandR, XRender, XCursor, XFT, NLS

Unrelated: Thanks for fixing configure.ac (was broken in 1.0.8 with automake 1.16.5).

It is my belief that nothing in the following config file is required to demonstrate the problem. It was created to remove any potential side effects causes, to provide a clear visible demonstration, and for use in recreating the video demo if desired.

$ cat .fvwm/config
ImagePath /usr/share/pixmaps:+

colorset 1 fg LightSlateBlue, bg DarkSlateBlue

Style XTerm IconOverride, Icon xterm-color_48x48.xpm, StartIconic

AddToFunc InitFunction
+ I Exec exec xsetroot -solid red4
+ I Exec PS1='$ ' exec xterm -n ABCDEFGHIJKLMONOPQRSTUVWXYZ \
                     -geometry +128+64
+ I Exec PS1='$ ' exec xterm -n TUVWXYZ

Mouse 1     TISF    A   Move
Mouse 2     TISF    A   RaiseLower
Mouse 3     TISF    A   Iconify
Mouse 3     TISF    C   Close

The attached "icon_redraw.ogv" should be self-explanatory, but in an effort to err on the side of too much information rather than too little:

0:00 Immediately after starting FVWM, first icon's pixmap is missing and label is blank. 0:06 Hovering mouse over icon draws label. Not shown: Hovering over missing pixmap redraws label but not pixmap. (Note that the "trash"/cursor trails are artifacts of the recordmydesktop video capture.) 0:13 Window de-iconified. 0:15 Re-iconified, label and pixmap correctly drawn. 0:19 Icon moved. Pixmap is opaque-moved, label disappears (normal). 0:22 Icon label and pixmap correctly drawn in new location. 0:25 Icon moved. 0:32 Icon placed. Label obscures second icon's label. 0:35 Mouse moved off icon. Label clipped, no longer obscures second icon's label. Second icon label redraws correctly. 0:37 Mouse hovered over icon, displays full width label, obscures second icon's label. 0:39 Mouse moved off icon, restores all to correct 0:35 state. 0:40 Mouse hovered over icon, full width label obscures second icon's label. 0:41 Window de-iconified. Second icon's label does not redraw, remains blank. 0:46 Hovering mouse over second icon's label restores/redraws it (with hilight foreground/background colors). 0:47 Moving mouse correctly displays non-higlight colors. 0:49 Repeat hover/hilight. 0:51 Repeat move, non-hilight. 0:52 Move to non-iconified window (title and frame correct hilight colors). 0:54 Iconify window. 0:56 Move icon. 1:01 Move second icon. 1:05 Move first icon 1:10 Place so that full width label obscures first icon's pixmap. 1:11 Move mouse so returns to clipped width, not obscuring. Correct restore of first icon's pixmap. 1:12 Hover to obscure. 1:15 Move to un-obscure. Correct restore of first icon's pixmap. 1:17 Hover to obscure, de-iconify. Window completely covers first icon. 1:20 Iconify. Both icons (labels/pixmaps) redraw correctly. 1:22 Hover, full width label obscures. Move icon. 1:30 Un-iconify, fully obscures first icon. 1:31 Move un-iconified window. 1:36 Iconify. 1:37 Move so that full width label obscures first icon's pixmap. 1:44 Move mouse, second icon label returns to narrow width and non-hilight colors. 1:45 Hover and tweak position of icon. 1:47 Stop moving, full width label obscures first icon's pixmap. 1:48 Move mouse away and back, correct redraw of first icon. 1:51 De-iconify second icon, window does not cover first icon. First icon pixmap does not redraw. 1:55 Hovering over first icon (label) does not redraw pixmap. 1:56 Moving mouse draw first icon label in non-higlight colors. 1:58 Hovering mouse over label redraws in hilight colors, pixmap does not redraw. 2:00 Move mouse, label redraws non-highlight. 2:01 Not shown: Hovering over damaged pixmap does not redraw 2:03 Move icon. Label disappears (normal), pixmap moves opaque but damage not redrawn. 2:05 Place icon. 2:08 De-iconify. 2:09 Iconify. Pixmap correctly drawn.

I have tested on three separate systems, each with different graphics hardware and drivers (amdgui, nouvea, i915), with similar but not exactly the same results. For instance, on some the damaged pixmap does redraw, plus the missing initial pixmap and blank label happens on different icons with a real-world .fvwm/config file containing many initial windows/icons. Note that I ran for many years on the same hardware (but different kernels) with FVWM 2.6.7 without problem. In yet another mystery, building and running 2.6.7 now on the new kernels crashes (with a full .fvwm/config but not the simple example above) crashes immediately with:

fvwm: xcb_io.c:626: _XAllocID: Assertion `ret != inval_id' failed.

in .xsession-errors. Building/running 2.7.0+ works (but has the redraw problems).

I can do further testing and/or build new releases if desired. Unfortunately I don't have the time (nor likely the ability) to dive into the code and provide fixes/patches/pull-requests. I realize this is a fairly benign problem, but the visual distraction of the mis-drawn icons has me constantly moving the mouse and/or de-/re-iconifying windows to fix them. icon_redraw.webm

[111LUX]

icon_redraw.webm

This annoying issue is also present in new fvwm3 1.0.8 version too, and in all older fvwm2/3 versions, if fvwm is built on all new linux distros with newer version of xlib.

[ThomasAdam]

Appreciate the comments -- but this isn't helping me -- the information I have now isn't anything new.

[siebenmann]

My patch from January (in the comment above) continues to work for me without problems.

[ThomasAdam]

My patch from January (in the comment above) continues to work for me without problems.

Indeed -- I need to properly review that. It's on my (rather lengthy) TODO list.

[111LUX]

Here is Debian 12 "xthread_fix.patch". With this patch applied, FVWM stops crashing on systems with new version of xlib, without this patch applied FVWM is crashing with similar error:

fvwm: xcb_io.c:626: _XAllocID: Assertion `ret != inval_id' failed.

mentioned by @thanks4opensource

With this patch applied, FVWM stops crashing, but icons are starting to disappear on Restart and sometimes when switching any application fullscreen mode (like xterm, or firefox video, etc). To make it visible again, deiconify/iconify action is required or FVWM Recapture command.

Description: Fix a crash due to changes in thread locks in libX11 1.8.1
Author: Matthieu Herrb <matthieu@herrb.eu>
Forwarded: not-needed
Debian-Bug: https://bugs.debian.org/1034054
Last-Update: 2023-05-02
diff --git a/fvwm/events.c b/fvwm/events.c
index a2d024068..7a3d06c3b 100644
--- a/fvwm/events.c
+++ b/fvwm/events.c
@@ -258,6 +258,12 @@ static int _pred_weed_accumulate_expose(
    return 1;
 }

+static int _pred_weed_is_expose(
+   Display *display, XEvent *event, XPointer arg)
+{
+   return (event->type == Expose);
+}
+
 static int _pred_weed_handle_expose(
    Display *display, XEvent *event, XPointer arg)
 {
@@ -4542,7 +4548,8 @@ void handle_all_expose(void)

    saved_event = fev_save_event();
    FPending(dpy);
-   FWeedIfEvents(dpy, _pred_weed_handle_expose, NULL);
+   FWeedAndHandleIfEvents(dpy, _pred_weed_is_expose,
+                  _pred_weed_handle_expose, NULL);
    fev_restore_event(saved_event);

    return;
diff --git a/libs/FEvent.c b/libs/FEvent.c
index 24d019dd1..ec31728a9 100644
--- a/libs/FEvent.c
+++ b/libs/FEvent.c
@@ -532,6 +532,28 @@ int FWeedIfEvents(
    return weed_args.count;
 }

+int FWeedAndHandleIfEvents(
+   Display *display,
+   int (*weed_predicate) (Display *display, XEvent *event, XPointer arg),
+   int (*handler) (Display *display, XEvent *event, XPointer arg),
+   XPointer arg)
+{
+   _fev_weed_args weed_args;
+   XEvent e;
+
+   assert(fev_is_invalid_event_type_set);
+   memset(&weed_args, 0, sizeof(weed_args));
+   weed_args.weed_predicate = weed_predicate;
+   weed_args.arg = arg;
+   if (FCheckPeekIfEvent(display, &e, _fev_pred_weed_if,
+                 (XPointer)&weed_args)) {
+       handler(display, &e, arg);
+   }
+   _fev_pred_weed_if_finish(&weed_args);
+
+   return weed_args.count;
+}
+
 int FWeedIfWindowEvents(
    Display *display, Window window,
    int (*weed_predicate) (
diff --git a/libs/FEvent.h b/libs/FEvent.h
index 821aef51a..2622f4474 100644
--- a/libs/FEvent.h
+++ b/libs/FEvent.h
@@ -113,6 +113,14 @@ int FWeedIfEvents(
        Display *display, XEvent *current_event, XPointer arg),
    XPointer arg);

+/* Same as FWeedIfEvents but with a second callback out of XLockDisplay()
+ * to handle events in a lock-safe manner */
+int FWeedAndHandleIfEvents(
+   Display *display,
+   int (*weed_predicate) (Display *display, XEvent *event, XPointer arg),
+   int (*handler) (Display *display, XEvent *event, XPointer arg),
+   XPointer arg);
+
 /* Same as FWeedIfEvents but weeds only events for the given window.  The
  * weed_predicate is only called for events with a matching window.  */
 int FWeedIfWindowEvents(

[ThomasAdam]

@111LUX

I'm not following you -- this has been applied to fvwm3 for a while. What is it you're trying to say?

[111LUX]

Yes, I'm pretty sure that this was applied to fvwm3 too, as this issue exist in Debian 12 fvwm3 package too. So the problem is in this fix. My main intention is to make fvwm fully working in Debian 12. Maybe some help may be given to fvwm2 Debian package maintainer - jaimosskriletz @ gmail com With creating patch, to apply future fvwm3 fix for Debian 12 fvwm2 too, as this fix will be possible to use in all distros with newer version of xlib.

[ThomasAdam]

@111LUX This isn't the place to be discussing fvwm2. That has a separate issue tracker.

Please stop polluting this issue.

[thanks4opensource]

At the risk of this being considered redundant/spam, I'd like to report that I applied the patch to 018bd066 (got a .rej file, needed hand-tweaking) and initial testing on two different systems/GPUs/drivers shows the problems fixed. Thanks, @siebenmann.

Looking forward to seeing it or something similar in the main branch when scheduling and priorities allow. Also curious to know, when the dust settles, if this was:

1. An actual/latent bug in FVWM.
2. An edge case against some poorly defined and/or documented piece of the Xlib API which was validly changed/fixed.
3. Or the change is a bug in Xlib, either in its implementation or because it broke the API.

Reason: I'm hoping to avoid Wayland for the rest of my natural lifespan, but if X11 isn't being maintained (which I've read it isn't) and/or what little work it's getting is causing bugs and breaking applications, I'll have to rethink my position.

Thanks again for the responses here and for FVWM and its active ongoing development.

[ThomasAdam]

@thanks4opensource

It's a change which was made to Xlib.

[siebenmann]

To extend on @ThomasAdam 's answer, the trigger condition for this issue in fvwm3 was a change made in Xlib/libX11 1.8, where they decided to insist on thread safety even in single-threaded programs. Things promptly started crashing (for example) and code was updated to work around the problem, including in fvwm3. However, the fvwm3 code change had oversights of its own, such that sometimes it didn't properly recognize and react to all X events it got. This could leave you with, for example, un-refreshed icons under some circumstances, when fvwm3 received the 'refresh this' event but lost track of it internally. Had fvwm3 not have to rewrite and change code written under the previous implicit libX11 API, this problem wouldn't have arisen.

[111LUX]

This isn't the place to be discussing fvwm2. That has a separate issue tracker.

Where it is located? As it is impossible to create an issue in fvwmorg/fvwm for now.

From my perspective, something not very good and very inadequate is happening with whole FVWM project now, and it is very sad, as my main reasons, why I've chosen FVWM years ago and started to create my own config from scratch, were its stability and my confidence in its future, mostly because of its oldschool background. For now it's very difficult to say what kind of glitch will appear tomorrow, and also, who are the target fvwm3 audience, kids on drugs? When so many funny fvwm3 bugs appears in its latest releases. What is for sure and 100%, is that it is impossible to consider fvwm3 as a full value fvwm2 replacement for now, and at least, while it's not happened yet, fvwm2 should be actively supported and maintained.

---

P.S: When manually applied xthread_fix.patch https://github.com/fvwmorg/fvwm3/issues/818#issuecomment-1710549061 And also siebenmann's patch https://github.com/fvwmorg/fvwm3/issues/818#issuecomment-1401144381 To fvwm 2.7.0 source code, the issue with fvwm2 crashes and invisible icons disappeared for me. (I'm using Debian 12 AKA Devuan Daedalus).

[ThomasAdam]

From my perspective, something not very good and very inadequate is happening with whole FVWM project now, and it is very sad, as my main reasons, why I've chosen FVWM years ago and started to create my own config from scratch, were its stability and my confidence in its future, mostly because of its oldschool background. For now it's very difficult to say what kind of glitch will appear tomorrow, and also, who are the target fvwm3 audience, kids on drugs?

I think you're being rather melodramatic here, @111LUX -- and certainly this issue doesn't introduce anything near the same levels of instability I've seen in fvwm over the years -- and that's not just with the changes I've made to fvwm3.

All software has bugs, and so far, aside from various visual glitches this particular bug refers to, I've not heard of any instabilities associated with it.

You can either help by sending in additional bug reports here, for fvwm3, or if possible, PRs (Pull Requests) would be even more welcomed -- any other observations or concerns you're having with the stability of fvwm3 doesn't belong as additional comments here on this bug report.

I chose to let fvwm2 sit as-is because trying to introduce breaking changes to it was unfair in that state. You are, of course, free to continue to use fvwm2, but since it's been formally deprecated, you can either fork it and backport any changes you like (something which some distribution packagers are doing), or continue to use fvwm2 as-is.

But please don't tell me fvwm2 should be supported -- that's not your call, and it's not something that's going to happen either.

[111LUX]

Have been using fvwm3 since some time, and I can say, with @siebenmann's patch, it's working pretty well, including icons and stability. As interesting and good improvement — Unicode symbols (▼©®▲✨🌙☀️) are visible in titles now. Also, for some reason, "MenuStyle" "TitleColorset" started to be required, without it menu titles will be in black color.

[somiaj]

As interesting and good improvement — Unicode symbols (▼©®▲✨🌙☀️) are visible in titles now.

This was a fix in libxft, fvwm didn't really do anything to make that work.

Also, for some reason, "MenuStyle" "TitleColorset" started to be required, without it menu titles will be in black color.

Colorsets have been the preferred way of setting colors for a long time, and the old color methods have been removed.

[ThomasAdam]

To add what @somiaj has said, see: https://github.com/fvwmorg/fvwm3/discussions/878

[111LUX]

Unfortunately, this problem is still exist in 1.0.9 version. Just installed it. Icons becomes invisible after Restart.

[ThomasAdam]

Unfortunately, this problem is still exist in 1.0.9 version.

Just installed it. Icons becomes invisible after Restart.

That's right. I've not fixed it yet.

[cocolab8]

I am experiencing this issue as well with fvwm3 1.1.0.