Occasional black Palettes

[carrott]

Occasionally I have I observed on my own loptop and on other laptops a right-click context menu which is entirely black with no writing. If a context menu showed up black, it would always be black, even after navigating to a completely different screen and back to the original screen. A restart would fix it.

I saw this on the neighbourhood view and the home view and probably other places.

[bernie]

Confirmed, I've seen this bug too, on different context menus.

Maybe a GTK theme bug? Assigning to sugar-artwork. Benjamin, what do you think?

[quozl]

Seen four months ago also ​http://dev.laptop.org/ticket/10131

[manuq]

This is still happening after the port to GTK+3, I have seen this occasionally. Was reported also at #4348.

[erikos]

Manuel, just found a way to force it and reproduce it: doing several left and right clicks on the XO menu can get us the black menu.

[erikos]

Same steps (quick left and right clicks) do work as well for the frame device icons. And extensive forcing can turn an AP Palette as well all black.

Works as well with a rapid sequence of touches.

[carrott]

I am able to reproduce this on XO-4 13.1.0 build 32 with touch screen interactions. In addition I managed to stop the touchscreen and mouse working while trying to reproduce this.

[manuq]

I'm adding logging, still couldn't find what's happening. Looks like an issue of palettes with an invoker that has toggle_palette property set to True.

I commented out the do_draw override method of _PaletteWindowWidget(Gtk.Window) but this doesn't solve the problem.

[manuq]

I have also checked the size of the widget that the _PaletteWindowWidget contains, in case it is getting a null size. But looks correct too:

@@ -687,6 +694,9 @@ class PaletteWindow(GObject.GObject):
             self.on_leave()
 
     def __show_cb(self, widget):
+        child = widget.get_children()[0]
+        alloc = child.get_allocation()
+        logging.debug("MANUQ PaletteWindow __show_cb %r", (alloc.width, alloc.height))
         if self._invoker is not None:
             self._invoker.notify_popup()

[erikos]

Replying to manuq:

I'm adding logging, still couldn't find what's happening. Looks like an issue of palettes with an invoker that has toggle_palette property set to True.

It is true that the toggle Palette is at least our path for triggering the issue with the high sequence of clicks to invoke the Palette, the Palette is then forced to popup/popdown and draw the Palette quickly.

If you check on 12.1.0, where the Palettes are not toggable, I can not use our test case to trigger the issue. (this does not mean the issue is not there on older builds, but can probably only triggered through other means and is likely more rare).

[manuq]

Patch: prevent fast popup popdown

[manuq]

I think the attached patch is the way to go. After palette popdown, we prevent popping it up again for a few milliseconds. The user interaction is not affected.

[erikos]

Replying to manuq:

I think the attached patch is the way to go. After palette popdown, we prevent popping it up again for a few milliseconds. The user interaction is not affected.

I can still see the issue with this patch applied (XO-4 os34).

[manuq]

Replying to erikos:

I can still see the issue with this patch applied (XO-4 os34).

Thanks, on that first patch I missed the CursorInvoker. Now it should work on all palettes. I improved the code names and comments too.

[manuq]

Forget the patch. It makes is more difficult to trigger the issue but is still easily reproduceable. We should see how to prevent the inconsistent state following the signals handling.

[manuq]

Adding logging we can see _PaletteWindowWidget method do_draw stops being called at the point the issue starts to happen. Also adding a callback to the 'draw' signal of the same window shows that the callback stops being called.

The issue goes away if we remove set_resizable(False) in the _PaletteWindowWidget constructor. This makes the palette resizable though. We can sort out the user resizing the palette adding set_has_resize_grip(False). But we'll still have to sort out how to go back to the size of the palette containing only the header. Patch attached for testing.

[manuq]

Remove resizable false, and add some logging

[manuq]

I tried to sort out the palette not shrinking to content of the previous patch, forcing a resize after the content hides. The issue appears again. So indeed the problem is in the resizing of the window.

[manuq]

Sort out palette shrink, the issue appears again

[dnarvaez]

Doesn't seem to have landed. Manuel what's the plan here?

[manuq]

Replying to dnarvaez:

Doesn't seem to have landed. Manuel what's the plan here?

The path doesn't solve it. This is a very odd bug. Might be at the GTK level. A workaround could be: prevent a palette pop-up for a fraction of second after a pop-down. But following the events in palettes is hard, the code is obscure.

[tch]

I was able to reproduce this issue in the favorites view buddy palette and in neighborhood view with AP palettes.

Something I noticed was that these black palettes only appears (or remains) with palettes that are cached.

ie., I worked around the issue in the favorites view by making the palette creation lazy. ​https://github.com/sugarlabs/sugar/commit/08b6edba380e8e6a93dde63666668d980f5e2873

[Martin Abente Lahaye]

Fix black palettes

Push the palette widget opening process to the latest
in order to avoid the race condition where the animation
takes of the place of the real palette.

Fixes #2184

Signed-off-by: Martin Abente Lahaye <tch@…>

Changeset: 2f19a41432fb85e49ded14131900377b1712593a