Re: menu bug solved?

[mmc maruska dyndns org (Michal Maruška)]

John Harper <jsh unfactored org> writes:

> On Feb 6, 2005, at 3:57 PM, John Harper wrote:
>> On Feb 6, 2005, at 2:57 PM, Michal Maruska wrote:
>>> i think, that XFlush is not enough. XSync is needed, b/c X server could first
>>> serve the requests of the sawfish-menu client, and deny it the grab.

>> I don't think that Xsync will make any difference here, the flush ensures that
>> the wm process has ungrabbed by the time the menu process attempts to grab.
>
> on second thoughts, I take that back, it relies on the X server processing
> requests in the order they're flushed, which isn't necessarily true. Does this
> patch work?


hi John,
even though i don't use the SF menus, i took the time to look into the issue,
because i have the tools to do it, and the knowledge.

I would appreciate, if you mentioned the fact that I found this bug, which
dates back long, in the CVS Changelog.  Even if i didn't bother to provide a
formal patch.


 * sawfish/wm/menus.jl (popup-menu): synchronize with the server
    after ungrabbing, just to be sure, instead of flushing


and i disagree with "just to be sure" formulation. My email explains what can
(and does) happen without it. 



>>> what does (x-server-timestamp) do is a different issue....

>>the timestamp from the current event is passed through to gtk_menu_popup (),
>>it's used when trying to grab the keyboard and pointer to avoid cancelling a
>>later event

I know. But simple CurrentTime might do as well (unless we want to fail if some
client grabbed/ungrabbed in between). If called from sawfish-client,
last_event_time might be meaningless.