Re: Events delivered to not-viewable windows

[Tim Janik <timj gtk org>]

On 6 Jun 2003, Owen Taylor wrote:

> http://bugzilla.gnome.org/show_bug.cgi?id=105642 points out
> a very long-standing problem in GTK+ - you can get events
> delivered to windows that are no longer viewable. (Viewable
> means that the window and all it's parents are mapped.)
>
> The case in the bug report is:
>
>  Application hides window after gtk_dialog_run(), but
>  Escape keypress is queued up and causes the dialog
>  to be destroyed
>
> But you can easily construct other examples as well, for
> example:
>
>  User clicks on a notebook tab the dialog, then quickly
>   clicks on a window-widget in the dialog before the
>   page changes.
>
> The attach patch is an attempt to solve the problem;
> what it does is is that before emitting ::event,
> ::<foo>-event ::event-after check that the window is
               ^
your missing an "or" or "and" here. i assumed "and", but your
code looks like it does "or".

> viewable.
>
> I think this patch considerably improves the current situation;
> though I have two small concerns about the re-checking between
> the 3 signals:

>  - The repeated checks don't catch the case where one handler
>    for the signal unmaps the window or a parent, so they
>    are still imperfect. (The point could be made about
>    the current WIDGET_REALIZED_FOR_EVENT() check)

such handlers should in general return TRUE, and thus stop the
emission.

>
>  - It's slightly conceivable that an app might rely on
>    still receiving an event in ::event-after even if the
>    main handlers resulted in the widget being hidden.

::event-after is supposed to be emitted after an event if the
widget got hidden even now. handlers that don't account for this
are basically buggy.

> It's possible that considering these points, it would be
> simpler o just check once at the top of the function, and
> ignore the possibility of handlers in the course of
> gtk_widget_event() making the widget not-viewable.

jup, i was just going to point this out to be better.

basically, people hiding a widget in ::event but returning
FALSE get what they deserve (i.e. for ::<foo>-event being run on
a non-viewable widget, the actual bug is the non-TRUE return
from ::event here). ::event-after does need to be emitted though,
people already have to take care of widgets being unmapped within
it, think of connect("clicked", {widget_hide(self);return TRUE;}).

there's one last thing i'm worried about wrg your patch. that's
delivery of "paired" events like button releases or focus-out.
with your patch, a second such event that might be connected to a
handler which "cleans up" stuff will be ignored.
i guess for most cases you'll want to tell people to guard their
code against not getting the second event (though that is really
mnasty to take care of in times). i'm not so sure about ::focus-out
though, doesn't gtkwindow and lots of widget code rely on delivery
of that event even for non-viewable widgets?

>
> Regards,
> 				Owen
>

---
ciaoTJ