GNOME Bugzilla – Bug 154918
panel menu window cant be Menu or UI Grab actioned
Last modified: 2004-12-22 21:47:04 UTC
using GOK (non corepointer mode), activate a panel and invoke the 'click' action on the main menu button (as shown in UI Grab). As a new window pops up, GOK branches to Main and doesn't display active Menus or UI Grab buttons. This used to work, but to be honest I don't know how it did, since GOK is getting a window:deactivate event from the bottom panel, but no window:activate event from the popped-up menu.
I understand that this may end up bounced to gail, or perhaps less likely, to GOK, if we find a reliable workaround. I'd like Padraig's opinion on when to expect 'activate' from popup menus, and why we're not getting a matched set of activate/deactivate events here.
When the menu is popped up you should get a window:deactivate event for the panel and a focus event for the menu. You do not get activate event from the popup menu.
Bill, is there a bug logged in Bugster for this ?
see bugster bug : 6177484 - panel menu window cant be Menu or UI Grab actioned
moving back to gok for more evaluation, on basis of padraig's comments.
this is reportedly a regression, but I don't understand quite why the behavior changed.
Just an FYI, I'll be looking into this bug tomorrow morning.
I am seeing something possibly related: using non-core pointer (direct selection) launch gok launch gedit uigrab open click uigrab Gok should now show all the open dialog gui but doesn't. Instead focus seems to end up back on gedit's main window. Trying to activate the Open dialog and uigrabbing again fails in the same way. Appears to be weird focus issues using non-core pointer. Still investigating...
Hmmm... Because it is so important that GOK is not occluded by other windows, gok frequently calls gdk_window_raise to raise itself (e.g. on device events). It appears that when gok makes this call, the window manager (or other?) raises GOK (not noticable unless GOK was occluded), but then gives focus to the window under the core pointer (where ever it may be)! This doesn't appear to happen when using the core pointer to operate GOK. I'm not sure when this focus under the core pointer behaviour was introduced. I'd like some help triaging this one... The only thing I can see we can do on the GOK side is remove the raise window calls, but then we'll very likely see cases of GOK being occluded - which is very bad.
I tried what you described in comment #8 and found it did not work when using gok 0.11.10 but does work when I build gok from CVS HEAD. I am using a non-core pointer in dwell mode. With both versions of gok the originally reported problem still appears.
Padraig, I'm using gok from CVS HEAD. Did you note comment #9 when you tested?
Yes but as I could not reproduce the problem when using CVS HEAD I could not evaluate the comment.
Understood. I was just wondering if by chance the core pointer happened to be in the 'right place' during your gok cvs head test.
Where should I put the core pointer to see the abherrant behavior?
In my comment #8 case, move the core pointer off the open dialog.
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
David: please split out the (independent) issue in comment #8. I am not sure it's related, and the behaviors seem to occur independently of one another (see Padraig's comments). Meanwhile, bumping up severity because this is an efficiency problem and high-visibility.
Created attachment 33200 [details] [review] patch fixes for popup menus such as panel menu and context menus.