Opened 14 years ago

Closed 10 years ago

#2184 closed defect (fixed)

Occasional black Palettes

Reported by: carrott Owned by: manuq
Priority: Normal Milestone: Unspecified
Component: Sugar Version: 0.98.x
Severity: Major Keywords: dextrose
Cc: bernie Distribution/OS: Fedora
Bug Status: New

Description

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.

Attachments (5)

logging.patch (5.9 KB) - added by manuq 11 years ago.
delayed_popup.patch (1.9 KB) - added by manuq 11 years ago.
Patch: prevent fast popup popdown
0001-Palettes-prevent-popup-after-popdown-for-a-few-milli.patch (3.3 KB) - added by manuq 11 years ago.
remove_resizable_false.patch (1.9 KB) - added by manuq 11 years ago.
Remove resizable false, and add some logging
remove_resizable_false-shrink.patch (1.6 KB) - added by manuq 11 years ago.
Sort out palette shrink, the issue appears again

Download all attachments as: .zip

Change History (32)

comment:1 Changed 14 years ago by bernie

  • Bug Status changed from Unconfirmed to New
  • Cc bernie added
  • Component changed from untriaged to sugar-artwork
  • Owner set to benzea
  • Status changed from new to assigned

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?

comment:2 Changed 14 years ago by quozl

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

comment:3 Changed 11 years ago by manuq

  • Component changed from sugar-artwork to sugar
  • Owner changed from benzea to manuq
  • Priority changed from Unspecified by Maintainer to High
  • Severity changed from Minor to Major
  • Version changed from 0.88.x to 0.98.x

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

comment:4 Changed 11 years ago by manuq

  • Milestone changed from Unspecified by Release Team to 1.0

comment:5 Changed 11 years ago by 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.

comment:6 Changed 11 years ago by 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.

comment:7 Changed 11 years ago by erikos

  • Summary changed from Occasional black context menus on os300py on XO-1 to Occasional black Palettes

comment:8 Changed 11 years ago by 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.

comment:9 follow-up: Changed 11 years ago by 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.

Changed 11 years ago by manuq

comment:10 Changed 11 years ago by 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()

comment:11 in reply to: ↑ 9 Changed 11 years ago by 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).

Changed 11 years ago by manuq

Patch: prevent fast popup popdown

comment:12 follow-up: Changed 11 years ago by 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.

comment:13 in reply to: ↑ 12 ; follow-up: Changed 11 years ago by 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).

comment:14 in reply to: ↑ 13 Changed 11 years ago by 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.

comment:15 Changed 11 years ago by 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.

comment:16 Changed 11 years ago by 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.

Changed 11 years ago by manuq

Remove resizable false, and add some logging

comment:17 Changed 11 years ago by 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.

Changed 11 years ago by manuq

Sort out palette shrink, the issue appears again

comment:18 follow-up: Changed 11 years ago by dnarvaez

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

comment:19 in reply to: ↑ 18 Changed 11 years ago by 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.

comment:20 Changed 11 years ago by dnarvaez

  • Milestone changed from 1.0 to Unspecified

comment:21 Changed 11 years ago by dnarvaez

  • Bug Status changed from New to Unconfirmed

comment:22 Changed 11 years ago by dnarvaez

  • Bug Status changed from Unconfirmed to New

comment:23 Changed 10 years ago by godiard

  • Priority changed from High to Normal

comment:24 Changed 10 years ago by godiard

  • Priority changed from Normal to High

comment:25 Changed 10 years ago by 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

comment:26 Changed 10 years ago by tch

  • Priority changed from High to Normal

comment:27 Changed 10 years ago by Martin Abente Lahaye

  • Resolution set to fixed
  • Status changed from assigned to closed

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

Note: See TracTickets for help on using tickets.