Re: Events delivered to not-viewable windows

[Owen Taylor <otaylor redhat com>]

On Fri, 2003-06-06 at 12:03, Tim Janik wrote:
> 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".

I think "and" would still be ambiguous :-) I meant
before emitting ::event and before emitting ::<foo-event>
and before emitting ::event-after.

> > 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.

Any ::event-after handler is likely part of an enormous hack
in any case. My guess is that they *don't* check for the window
being hidden by the event handler, but then again, if you write
an ::event-after handler, you better understand pretty well
the what the main handler is doing.

> > 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). 

Ugh, you are right - the second event really should be delivered
because it is conceptually tied to the first event, which was
delivered. Widgets that depend on paired button-press/leave already
do need to do some special handling - they have to stop expecting
the second event when the widget:

 - becomes insensitive
 - becomes grab-shadowed
 - becomes unrealized

But I don't like adding yet another condition to track (and one
which is actually almost impossible to track currently, since there
is no notification on the idea of viewability we are using.)

Simplest hack - simply omit the check for BUTTON_RELEASE,
KEY_RELEASE (not guaranteed to be paired, but probably nicer
to preserve when possible), LEAVE_NOTIFY, PROXIMITY_OUT.

That would be my preferred solution, I think, rather than anything
more complicated.

> 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?

If you look at the details of my patch, it only does anything
for a subset of events ... basically, mouse/key/expose events.

Regards,
					Owen