Created attachment 46067 [details] [review]
Make window always pop up on top of the window stack

Hi,

This patch should make the accessiblity dialogs always pop up on top even with
focus stealing prevention turned on.

Thanks for the bug and the patch.

Elijah, do you have any opinion on this patch. Is that the correct way to fix that?

Overriding focus stealing prevention isn't the right way to go about this.

The right way to fix this is to not turn on sticky keys or slow keys until the
user confirms they want it in the dialog.

To that proposal, billh will respond that the target audience may need the
keyboard a11y features to be able to use the dialog...

So sticky keys is only important when you have key combinations that need to be
chorded together, I think.  The user shouldn't need sticky keys to select one of
the options in the dialog, right?

I guess when slow keys are turned on unexpectedly it's not as bad for
users--they can still alt-tab and navigate with the keyboard.

So maybe the solution is:

1) Sticky keys shouldn't be on by default when the shortcut is triggered
2) Slow keys should be on by default
3) Focus stealing prevention shouldn't be circumvention, the dialog should flash
like any other window wanting attention.

Sound reasonable?

Slow keys is also very problematic, since it makes Alt-TAB appear broken too

For some reason I can't trigger the dialogs at all right now (and yes, I'm
looking behind windows just in case)--they won't launch for me.  Anyone have any
ideas why that might happen?  I'd like to test...

Anyway opinions, ideas, and facts that may be useful:

 - We could avoid obscuring such windows

   We have code in Metacity to make windows that don't get focus be placed so
   as to not be obscured by the focus window.  Until yesterday, we had only
   used this code for normal windows (didn't want to break the
   dialogs-go-on-center-of-parent rule).  We could also apply it in other
   places, such as for this bug.

 - The patch isn't a robust way for getting notice

   - If users are fast enough to focus another window before these dialogs
     appear, they are probably fast enough to focus another window just after
     these dialogs appear but before they have noticed that they appeared.
     (Though slightly unlikely and probably would only happen with large
     windows)

   - Similar to above, but much more likely: the user could switch workspaces
     just after the window appears

   - I don't think it actually ensures the window gets on top with focus.
     Between the time that gnome-settings-daemon sends the activation message
     and metacity receives it, the user could click on another app and
     metacity could process that click first.  (Matthias: please correct me if
     I'm wrong on this; I'm fuzzy on order of messages with asynchronousness
     of X)

  - The patch could cause new problems

    Part of the reason for focus stealing prevention is so that if we detect
    the user has begun using another app that we don't steal focus and make
    them initiate an action they didn't intend.  There's a very real possiblity
    that by stealing focus, the user chooses one of the actions in these
    dialogs that they didn't want.

  - The problem is deeper than just whether the window got activated

    You guys have been discussing this, but basically, the dialogs need to
    screw up the user's environment (affecting their usage of all other
    windows) in order for the feature to be useful to accessiblity users.  That
    is a fundamentally different kind of window, in my book.  Possible ways of
    handling this:

    - Make the dialogs system modal (like the logout dialog[1]).  It would
      work, but be excessive and annoying.

    - Add a special window type for these.  Then WMs could do smart things like
      stacking them higher than other stuff, make sure they are sticky (in both
      the workspace and viewport sense for those WMs that support both), etc.

[1] I hate how the logout dialog is system modal.  I often launch it, realize
there was one thing I forgot to do that would take me half a second, have to
wait 5-10 seconds for the dialog to appear (stupid, stupid stupid...), cancel
the dialog when it finally does appear, do my thing, then relaunch the logout
dialog and wait again.

Oh, I should have tried to summarize: I like the new window type idea best,
though I'd need help coming up with a good name so we can make an EWMH
suggestion.  Any thoughts or ideas on that or with alternative fixes?

I'm a little afraid the new type would be open to abuse by other apps that don't
need it, but if we do something sufficiently strong handed (e.g. don't focus or
restack other windows when clicked on, disable alt-tabbing, set the
demands-attention hint for such windows and don't allow it to be turned off, or
some other idea though definitely not all of these) then I think it could work
well for dialogs like these and only be used as appropriate.

Hi Elijah,

You probably have accessibility disabled.

Go to Desktop > Preferences > Accessibility > Keyboard > Enable keyboard
accessibility features

I'm not sure on what to do about this bug. According to Elijah's comment this
should probably we worked with window manager changes but now is feature freeze
so that's probably not for now. 

Guys:  It isn't technically feasible to "not turn sticky keys on until after the
user has confirmed, etc.".  Nor is it correct from an accessibility point of
view.  The point of the dialog is to alert the user to WHAT HAS ALREADY HAPPENED.

I think the patch already submitted should be applied ASAP, then we should fix
the strings after the string freeze gate opens again, to make the description a
little better.

regards

Bill

Bill: Um, yeah, Matthias already said as much (comment 4).  ;-)

But no, the patch already submitted isn't right and should not be committed. 
See comment 7.  It doesn't guarantee that the window is seen, and it could
easily result in accidental dismissal of the dialog which would be _much_ worse
(even if the dialog isn't seen initially, so long as it isn't accidentally
dismissed then the user should eventually see it after minimizing some apps or
notice it in the taskbar and figure out what happened).

Now, there is a bug in metacity.  If a window is denied focus, we try to place
it so that it isn't obscured by the focus window.  We missed doing that on
dialogs like this that have no parent, but it's just a one-line fix (I just
tested it and it works great).

There is also a bug in the dialog--the user_time is not being updated for the
window due to the pressing of shift.

Fixing these two things should handle most of what's needed.  But we should also
do something better, as I mentioned in comment 7.  If we really need something
more like this in time for 2.12 but can't get the feature addition approved, we
could also add some hacks as a short term fix (state_above, sticky, maybe others...)

thanks Elijah for your clarification.  

Your comment #7 is very useful.  I wonder, will the 'URGENT' etc. stuff being
discussed elsewhere help solve the problem of dialogs like this getting the
user's attention in the edge and corner cases?

Bill

The Urgent/demands-attention stuff elsewhere should help improve the situation
for the normal needs-attention case, yes.  Currently, we do that poorly across
workspaces (though I think we could fix that by having urgent/demands-attention
windows always appear in the taskbar, just as windows-being-started always
appear in the taskbar)

However, I think this particular case is special and different.  As you and
Matthias pointed out, the user's environment needs to be modified for these
things to be useful.  For users that don't know about these accessibility
features, that can be harmful.  To mitigate that, it'd be helpful to have
something more than "this is an important window" (e.g. your friend just IM'd
you again for the 100th time today or you got a new email or something like
that), it is a "you may not be able to sanely interact with anything on your
desktop until you handle this".

So, I already posted the metacity patch for the
avoid-being-obscured-if-denied-focus in bug 313234.  Regarding the bug in
gnome-settings-daemon not updating the user_time of these dialogs:

From gnome-settings-accessibility-keyboard.c, in set_gconf_from_server():

	/* 
	 * sticky or slowkeys has changed, singly, without our intervention.
	 * 99% chance this is due to a keyboard shortcut being used.
	 * we need to detect via this hack until we get 
	 *  XkbAXN_AXKWarning notifications working (probable XKB bug),
	 *  at which time we can directly intercept such shortcuts instead.
	 * See cb_xkb_event_filter () below.
	 */

and in cb_xkb_event_filter():

	/* 
	 * TODO: when XkbAXN_AXKWarnings start working, we need to 
	 * invoke ax_keys_warning_dialog_run here instead of in
	 * set_gconf_from_server().
	 */

So, is XkbAXN_AXKWarnings working these days?  Because that's where we have the
timestamp and need to update it.  And how does one debug gnome-settings-daemon
(is there a document similar to metacity/HACKING with a debugging section that
says how this can be done)?

AFAIK AkbAXN_AXKWarnings is still not working.  

*** Bug 160576 has been marked as a duplicate of this bug. ***

So, now that bug 313234 fixed, I don't think this bug is quite as urgent.  It
still sucks, but problem (1) brought up by Matthias always existed for these
dialogs and the number of cases where (2) will make it worse has been reduced
from nearly always down to somewhat infrequent (e.g. maximized windows, though a
single click with the right timing in that case could still cause issues before
focus stealing prevention and in with focus stealing prevention at least we have
a glowing taskbar).  So, I'm going to kick off the 2.12.x milestone.  (I'll also
mark the patch as commented-on as Ray stated that it wasn't the right fix)

It'd still be nice to (a) have XkbAXN_AXKWarnings fixed so that we could fix the
issues mentioned in comment 15 (which is what causes these windows to almost
always be denied focus when they should almost always get it), and (b) introduce
a special window type for these windows so we can provide extra hinting to the
user that we busted their environment.

Fixing Matthias' comment #1 breaks string freeze, so it should probably wait.  I
don't think that #2 is a stopper for 2.12.

Getting AkbAXN_AXKWarnings fixed will require fixes to XKb on multiple
platforms; and of course new xserver releases.

Ubuntu bug about that: https://launchpad.net/distros/ubuntu/+source/control-center/+bug/31720

Apologies for spam-- marking AP2 to reflect accessibility impact.

Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.

This bug has been open for two years, three months, with high priority and major severity.  It's still a problem.  Is there any information I can provide that would help to get it fixed?

Additional hours in the day are more needed than additional information.

Once things get behind, they just get more and more behind...

*** Bug 536270 has been marked as a duplicate of this bug. ***

Also see http://blogs.gnome.org/mccann/2008/05/19/ease-of-access/ and bug #526070.

We should close this one out.  The dialog is a notification bubble now.