Created attachment 342846 [details] [review]
0001-Try-and-make-MATE-Alt-F1-less-noisy.patch

This patch isn't too great, but works.  The idea is to ignore window activation/deactivation-like events when a menu is open, as as menus have grabs, such events shouldn't affect the actual focus.

There are rare cases where the menu isn't presented at all, but this already happens with master.

On Debian unstable with MATE 1.16/GTK3 there is a spurious (I think) additional "object:property-change:accessible-name" event on the panel frame (leading to "presenting" it again after the menu -- but only once, as focus is still believed), which the patch here doesn't eliminate.

(In reply to Colomban Wendling from comment #1)
> Created attachment 342846 [details] [review] [review]
> 0001-Try-and-make-MATE-Alt-F1-less-noisy.patch
> 
> This patch isn't too great, but works.  The idea is to ignore window
> activation/deactivation-like events when a menu is open, as as menus have
> grabs, such events shouldn't affect the actual focus.

Incorrectly ignoring a window activation/deactivation can cause much breakage in Orca because one of the things Orca uses as a means to determine if events should be presented are whether or not they come from the active window.

Can this not be fixed in MATE?
 
> There are rare cases where the menu isn't presented at all, but this already
> happens with master.

Could you give me a concrete example? If it's an Orca bug, I would like to fix it.

(In reply to Joanmarie Diggs (IRC: joanie) from comment #2)
> Incorrectly ignoring a window activation/deactivation can cause much
> breakage in Orca because one of the things Orca uses as a means to determine
> if events should be presented are whether or not they come from the active
> window.

Hum… maybe it could be possible to check the other way around, whether the current locusOfFocus is inside the window to be presented, and abort only in that case?  I'm not sure it'd work, but if it does it would seem fairly safe to me, wouldn't it?

(In reply to Joanmarie Diggs (IRC: joanie) from comment #2)
> Can this not be fixed in MATE?

Unfortunately I don't think so, no.  MATE doesn't seem to be doing much here actually: the panel merely opens a menu in response to a special (non-input) X event, it never gets focused explicitly.

And the panel can't really get input focus first: it's the WM that chooses not to give focus to it, because it's a dock, and the focus must not stay inside the panel after the menu popped down unless it was already there.  All that is handled fairly transparently by the WM by simply not giving focus to the window IIUC.

The issue is probably the same if any non-current application opens a menu I guess.  Maybe the WM prevents that from happening though, not sure.

> (In reply to Joanmarie Diggs (IRC: joanie) from comment #2)
> > There are rare cases where the menu isn't presented at all, but this already
> > happens with master.
> 
> Could you give me a concrete example? If it's an Orca bug, I would like to
> fix it.

Unfortunately no, if I could have found a proper way to reproduce I'd have mentioned it.  I fee like it's fairly random, maybe happens more under higher stress, not sure.

(In reply to Joanmarie Diggs (IRC: joanie) from comment #2)
> Incorrectly ignoring a window activation/deactivation can cause much
> breakage in Orca because one of the things Orca uses as a means to determine
> if events should be presented are whether or not they come from the active
> window.

Actually I discovered that it's already possible to mess up the state with current master: when triggering the MATE main menu with Alt+F1 and quickly using movement keys when having Firefox focused, the Orca focus will go back to Firefox despite the menu still being open.

To reproduce, on Debian Jessie with Orca Master, MATE desktop and Firefox 45.6:

1. Open Firefox
2. Hit Alt+F1
3. *quickly* hit down arrow

Expected result: select the first item from the Application menu that is displayed on the top left.

Actual result: reads out the next line of the currently open page in Firefox.

> > There are rare cases where the menu isn't presented at all, but this already
> > happens with master.
> 
> Could you give me a concrete example? If it's an Orca bug, I would like to
> fix it.

I still don't have a proper solution to reproduce that, but it happens sometimes when triggering the MATE menu when having Firefox focused.

(In reply to Joanmarie Diggs (IRC: joanie) from comment #2)
> Can this not be fixed in MATE?

I investigated further, and the events are sent by GAIL/GTK, and all because of grabs triggered by global shortcuts.  These extra events are annoying, but I'm not sure if ignoring those at the GAIL/GTK level would cause other issues, e.g. if it would miss legitimate events.  https://mail.gnome.org/archives/wm-spec-list/2007-May/msg00000.html suggests this whole situation is very tricky.  First hacky tries (ignoring grab-related events when generating window-relate AT events) don't seem to show problems, but there are other issues around that Alt+F1 thing to really tell for sure, and I probably didn't test all possibilities.

OTOH, *maybe* MATE could emit an extra activate AT event on its own hoping to get last, but:

* that likely wouldn't remove the current noise
* I'm afraid it would depend on MATE somehow sending the event last

And I guess it'd be the same as not ignoring ":showing" on windows that are menus (which for some reason don't get a :activate event).  And it probably wouldn't resolve the current noise, unless it made Orca cancel everything before -- and quickly enough.

Another problem would probably be to get back to the correct window afterward, as MATE couldn't fake the activate event for the previous window when the menu pops down.

Created attachment 345042 [details] [review]
Drop events for deactivated windows

(In reply to Colomban Wendling from comment #5)
> First hacky tries (ignoring
> grab-related events when generating window-relate AT events) don't seem to
> show problems, but there are other issues around that Alt+F1 thing to really
> tell for sure, and I probably didn't test all possibilities.

While it improved the situation with GTK2, it didn't with Firefox actually.  And if it would mean patching each and every "toolkit", although they are all doing the same, doesn't seem very realistic unfortunately.  Not to mention I'm totally not sure this would be a valid change.

(In reply to Colomban Wendling from comment #5)
> OTOH, *maybe* MATE could emit an extra activate AT event on its own hoping
> to get last, but:
> 
> * that likely wouldn't remove the current noise
> * I'm afraid it would depend on MATE somehow sending the event last

I tried emitting state-changed:active explicitly when poping up the menu, and that doesn't help.  It doesn't prevent the next one from happening, thus not removing the noise, and happens before the other one so doesn't help with the focus "stealing" that cuts off speech.

(In reply to Colomban Wendling from comment #4)
> (In reply to Joanmarie Diggs (IRC: joanie) from comment #2)
> > Could you give me a concrete example? If it's an Orca bug, I would like to
> > fix it.
> 
> I still don't have a proper solution to reproduce that, but it happens
> sometimes when triggering the MATE menu when having Firefox focused.

I spent more time on this, and actually it seems that Firefox is emitting the activate/deactivate events as mentioned in https://bugzilla.gnome.org/show_bug.cgi?id=776854 later than other apps, which happens to be *after* the menu has been open.  Hence, it pretends to get focus, cutting off the menu speech, and then lose it.

As said above, I still couldn't fine a solution outside of Orca despite spending a lot of time on it (and getting a few headaches).  Nothing seems to actually be at fault here, just that in this case it's causing troubles for us.

A "solution" for most of this could be to filter events in the queue not to keep dispatching events we know are meaningless now: e.g. when receiving window:deactivate, drop all events related to that window that are still queued -- or at least those that would lead to Orca cutting off speech, so the ones changing the active window.
Attached patch does this.  It works so long as the offending events aren't dequeued faster than they are received, but in practice it seems just fine.
It doesn't fix "B" in comment #1, but fixes Firefox cutting off the menu speech.


What can I do further?  As said I really still don't see a solution outside Orca, so what would prefer?

We actually want to process window:deactivate events (e.g. to update state, clear cache, etc.). How can you be sure the events you are filtering out are indeed meaningless?

As for what you can do further, I'm sorry, but for now I'll have to request your patience. The solutions you have proposed so far have struck me as potentially problematic. And I have no plans to commit anything that strikes me as potentially problematic without fully looking into the matter myself. And when I fully look into the matter myself, I might be able to come up with a safe hack that I can live with. ;) So rather than ask you to play "fetch me a rock," I'm going to go with "thanks for your investigations into this matter, please stay tuned."

That said, if you feel this must be resolved now, you could certainly add your solution to the Hypra project's downstream Orca version.

(In reply to Joanmarie Diggs (IRC: joanie) from comment #7)
> We actually want to process window:deactivate events (e.g. to update state,
> clear cache, etc.).

I'm not dropping window:deactivate: I'm only keeping that one event when I see it.  That is, before putting window:deactivate in the queue, I clear any event in it that match host_application.

> How can you be sure the events you are filtering out are indeed meaningless?

Well, that's a good question, but IIUC Orca clears everything related to the application when the window gets deactivated, so it seemed safe enough not to process some events if I knew a window:deactivate one followed. But I may be wrong indeed, you surely would know better that I do :)

> As for what you can do further, I'm sorry, but for now I'll have to request
> your patience. The solutions you have proposed so far have struck me as
> potentially problematic. And I have no plans to commit anything that strikes
> me as potentially problematic without fully looking into the matter myself.
> And when I fully look into the matter myself, I might be able to come up
> with a safe hack that I can live with. ;) So rather than ask you to play
> "fetch me a rock," I'm going to go with "thanks for your investigations into
> this matter, please stay tuned."

Fair enough, thanks :)  And don't hesitate to ask if you need testing, details on what I tried and the result, etc.; if the time I spent scratching my head around this can be of any use.

(In reply to Colomban Wendling from comment #8)
> I'm not dropping window:deactivate: I'm only keeping that one event when I
> see it.  That is, before putting window:deactivate in the queue, I clear any
> event in it that match host_application.

So skipping other events that we might want to process, if, say a dialog box goes away? What if we get a bogus window:deactivate event?

And apologies. I glanced only briefly at your patch because it seemed a rather extreme solution to a chattiness problem.

I just committed a two-line fix to master which solves the problem for me (Fedora 25). Could you please test and let me know if it solves it for you? If so, please obsolete your patches and close this bug.

(In reply to Joanmarie Diggs (IRC: joanie) from comment #9)
> So skipping other events that we might want to process, if, say a dialog box
> goes away?

Yeah I'm not sure what `host_application` is exactly, but indeed it should really be "comes from the same window" in the logic I tried to have.

> What if we get a bogus window:deactivate event?

Wouldn't that cause the very same issue anyway when it gets processed?

> I just committed a two-line fix to master which solves the problem for me
> (Fedora 25). Could you please test and let me know if it solves it for you?

I'm sorry but no, it doesn't really fix it here.  I think it helps, but the behavior still seems a bit random:

* Sometimes, I get no context announce at all, and only "Applications menu" (that I don't really mind), and indeed nothing afterward.
* Sometimes, I only get "Top Expanded Edge Panel frame" without the menu announce at all
* Sometime I get the whole speech, with the extra announce ("B" from #1).  It happens most of the time after I switch to Firefox, and click on the applications menu, but not always.

Also, I can reproduce mostly reliably using Alt+F1 to open the menu.

I tested with MATE 1.16/GTK3 under Debian Sid, and MATE 1.8/GTK2 under Debian Jessie.

---

Also, although it's not exactly what the original report, the problems specific to using Alt+F1 to open the menu are still there.  I can open a separate report instead of mixing it here if you want; originally I hoped it could be fixed outside Orca, but as said earlier I lost that hope :(

Anyway, thanks for looking into this!

(In reply to Colomban Wendling from comment #10)
 
> > What if we get a bogus window:deactivate event?
> 
> Wouldn't that cause the very same issue anyway when it gets processed?

I'm worried about failure to process the other events because we assumed the window:deactivate event was valid. Given I have finite spare time, let's tackle the issues/behavior you are reporting.

The situation I attempted to (and at least in my environment did) fix is the behavior when the keyboard is used to access the menus. Before there was the chatter you described. Now there is not. Steps with results I get:

1. Press Alt+F1. Orca says "Applications menu"
2. Press Right Arrow. Orca says "Places menu"
3. Press Down Arrow. Orca says "Home Folder"

The above is intentional and I would argue correct. So when you say:

> Also, I can reproduce mostly reliably using Alt+F1 to open the menu.

Are you saying you are not getting the behavior I described above? Or are you getting it but think it is wrong?

(In reply to Joanmarie Diggs (IRC: joanie) from comment #11)
> The situation I attempted to (and at least in my environment did) fix is the
> behavior when the keyboard is used to access the menus. Before there was the
> chatter you described. Now there is not. Steps with results I get:
> 
> 1. Press Alt+F1. Orca says "Applications menu"
> 2. Press Right Arrow. Orca says "Places menu"
> 3. Press Down Arrow. Orca says "Home Folder"
> 
> The above is intentional and I would argue correct. So when you say:
> 
> > Also, I can reproduce mostly reliably using Alt+F1 to open the menu.
> 
> Are you saying you are not getting the behavior I described above? Or are
> you getting it but think it is wrong?

I'm saying I don't get this behavior.  But I agree the behavior you describe is great.

Under Debian Sid, MATE 1.16/GTK3 (bare metal): If I have e.g. mate-terminal focused:

1. Press Alt+F1.  Orca says "Applications menu.  Top Expanded Edge Panel frame"
2. Press Right Arrow.  Orca says "Places menu"

So indeed if fixes the announce on Right Arrow, that's good.  But it doesn't fix the announce of the frame after the menu.

Also, when triggering Alt+F1 from inside Firefox, the menu is still not announced.


Under Debian Jessie MATE 1.8/GTK2 (VM) it's oddly very different, and a lot worse and a lot more random.  The current application is spoken again upon Alt+F1 most of the time, generally before but sometimes after the menu; and the menu is announced as in #1.  However, I can't yet tell when, but sometimes it works just fine as you describe, no extra noise.

I just committed a series of small, sane fixes that address some more issues. Could you please pull master and re-test and let me know what you find?

Those fix the menu announcement from being cutoff by Firefox like 99% of the time, that's great!  I still had the problem once or twice when stressing it, but it's still so much better :)

However, it doesn't fix the other ones for me.

Possibly the same thing you did to ignore non-active window events from Gecko might help also for the chattiness I get on MATE 1.8/GTK2 from other apps, not sure.  I'll see if I can try this.

(In reply to Colomban Wendling from comment #14)
> Possibly the same thing you did to ignore non-active window events from
> Gecko might help also for the chattiness I get on MATE 1.8/GTK2 from other
> apps, not sure.  I'll see if I can try this.

I tried and it doesn't seem to change anything.  So if I did that properly, it's not a solution.


So currently for me Firefox is fixed, but otherwise it's the same as I reported in comment #12.

Could you please attach a debug.out showing the chattiness you are still seeing? (ideally one file per chattiness issue). If I spot it, I might be able to fix it quickly. And I'd really like to get this situation crossed off my list.

I've added still more hacks for mate-panel issues. Hopefully it's good enough now.

I'm closing this as FIXED on the grounds that Orca is going far above and beyond the call of duty to eliminate some "chattiness."