Ping. (The focus stealing behavior continues to crop up in various and sundry situations -- and does so to the extent that Evolution is difficult for people who are blind to use.)

Created attachment 146270 [details]
gtkhtml debug change

for gtkhtml;

I'm wondering how much this can be evolution's (or gtkhtml's) issue. I wasn't able to configure orca to show me that information, but I looked into gtkhtml code and this patch is adding some debug prints on focus in and focus out events. I didn't see any focus out/in on a new mail arrival.

If you can, please compile your own gtkhtml and check what's going on there (whether it behaves same for you as for me). Thanks in advance.

Thanks for looking into this!

I get:

  focus_in_event: html->iframe_parent:0

When focus is given to the body of the message. When a new message comes in, I do not get the focus_out_event debug line. (I do get this line if I move focus elsewhere.)

To verify that this issue wasn't fixed in the meantime, I re-ran the test using Orca. When the new message came in, Orca read the info for the message which was selected in the message list.

> events. I didn't see any focus out/in on a new mail arrival.

I'm afraid I don't have time to build Evo from source and become familiar with its code (sorry!!), but were it me, I'd be looking at what happens in the tree of messages when a new item gets added. It might turn out to be a Gtk+ bug rather than an Evolution bug, but *something* seems to going on with that tree.

Thanks again for investigating!!

(In reply to comment #3)
> When focus is given to the body of the message. When a new message comes in, I
> do not get the focus_out_event debug line. (I do get this line if I move focus
> elsewhere.)

So it's same for you and for me. That's good, I believe.

(In reply to comment #3)
> I'm afraid I don't have time to build Evo from source and become familiar with
> its code (sorry!!)

That's OK, it's not so simple, thus I understand completely. My problem is that I do not know Orca and how to setup it to test your steps precisely. Some help is needed.

The other thing is that I do not know how the new incoming mail can influence a focus flag in the composer. I believe the output from the Orca, on Ins+F7 press, shows the current focused widget information, which might be the GtkHTML component inside a composer, and when you do not alt+tab or something while the message arrived, then it should stay as such. As you said, maybe something else changed the focus flag on the component.

(In reply to comment #4)
> That's OK, it's not so simple, thus I understand completely. My problem is that
> I do not know Orca and how to setup it to test your steps precisely. Some help
> is needed.

I'm working on my DayJob at the moment, but I'll try to write up some more info this evening or tomorrow. Or maybe this can be reproduced using Accerciser. Two years ago, when I filed this bug, I wasn't the Accerciser pro that I am today. :-) Anyhoo, I'll look into finding you *a* testing solution/more information.
 
> The other thing is that I do not know how the new incoming mail can influence a
> focus flag in the composer.

Here's my (totally unproven) theory:

1. Focus is in the GtkHTML widget.

2. A new message arrives.

3. The new message gets added as a new child to the tree which contains all of the messages in the inbox.

4. ***The act of adding a new child to a tree (or to this tree at least) causes the tree to claim focus***

5. Some Gtk+ (or Gail) goodness then kicks in which says "Well, if the tree has focus, focus certainly cannot be in that GtkHTML widget any more" and Gail unsets the state.

Again, totally unproven theory, but functionally this sure looks like what is going on.

Just had another idea: Dtrace might come in real handy with diagnosing exactly what is causing this problem. I'll see about writing a dtrace script later today as well. (I didn't know about Dtrace two years ago either. :-) )

> component inside a composer, and when you do not alt+tab or something while the
> message arrived, then it should stay as such.

You'd think, wouldn't you? ;-)

Note that it's just a11y-wize that focus changes. I can keep typing my new message after the bug has occurred. The problem is Orca stops presenting what I'm writing. And the reason it does that is because it doesn't think focus is in the message any longer.

Created attachment 146538 [details]
A picture's worth a thousand words. I hope. :-)

Steps to reproduce (See screenshot, augmented with numbers corresponding to the steps below.)

0. Prep: Install Accerciser (http://live.gnome.org/Accerciser) if you don't already have it. Enable AT support for the GNOME desktop. Log out, back in.

1. In Evolution's list of folders, choose a folder to which a message will likely be delivered in the near future. Then move to the list of messages for that folder and select a message.

2. Create a new message in Evolution. Type some text for good measure.

3. In Accerciser, select Evolution in the tree of accessibles.

4. In Accerciser's Event Monitor:
   a. Check the 'focus' checkbox
   b. Select the Selected Application radio button
   (The Monitor Events button's state should toggle automatically.)
   
5. Return focus to the body of the message. Arrow around if you want. Type something. Whistle a happy tune. But stay put.

6. When a new message arrives, a cell in the row of the message which you selected in Step 1 will emit a focus event which you can see in Accerciser's Event Monitor.

I'll still try to get you more definitive debugging info. But from where I stand, this confirms my unproven theory from earlier: Something in the tree of messages (turns out it's one of the table cells) is claiming to have focus. The claim, I would argue, is bogus because the body of the message is the focused widget, both before and after the message arrives. Bogus or not, the focus event is in turn causing something, presumably in Gtk+/Gail, to conclude that the cell's claim to have focus necessarily means that the message body no longer has ATK_STATE_FOCUSED and it's state is being unset.

Hope this makes sense and helps.

I spent some time using Dtrace to see if I could help you narrow things down.

The following is the result of a script which I repeatedly tweaked to remove what seemed to be completely irrelevant calls. As such, this is not a 100% complete picture. That said, I think it gives a good indication of what is going on.

Hope it helps. Please let me know if you need more detail.

~~~~~~~~~~~~~
-> libevolution-mail-shared.so.0.0.0 mail_receive_uri

  -> libevolution-mail-shared.so.0.0.0 get_receive_type

  <- libevolution-mail-shared.so.0.0.0 get_receive_type

<- libevolution-mail-shared.so.0.0.0 mail_receive_uri

-> libevolution-mail-shared.so.0.0.0 receive_update_got_store

<- libevolution-mail-shared.so.0.0.0 receive_update_got_store

-> libevolution-mail-shared.so.0.0.0 receive_update_got_folderinfo

<- libevolution-mail-shared.so.0.0.0 receive_update_got_folderinfo

-> libemiscwidgets.so.0.0.0 e_selection_model_selection_changed

  -> libevolution-mail.so on_selection_changed_cmd

  <- libevolution-mail.so on_selection_changed_cmd

  -> libevolution-a11y.so.0.0.0 eti_a11y_selection_changed_cb

  <- libevolution-a11y.so.0.0.0 eti_a11y_selection_changed_cb

<- libemiscwidgets.so.0.0.0 e_selection_model_selection_changed

-> libemiscwidgets.so.0.0.0 e_canvas_item_grab_focus

<- libemiscwidgets.so.0.0.0 e_canvas_item_grab_focus

-> libevolution-a11y.so.0.0.0 eti_a11y_reset_focus_object

  -> libevolution-a11y.so.0.0.0 gal_a11y_e_cell_remove_state

  <- libevolution-a11y.so.0.0.0 gal_a11y_e_cell_remove_state

  -> libevolution-a11y.so.0.0.0 gal_a11y_e_cell_remove_state

  <- libevolution-a11y.so.0.0.0 gal_a11y_e_cell_remove_state

  -> libevolution-a11y.so.0.0.0 gal_a11y_e_cell_add_state

  <- libevolution-a11y.so.0.0.0 gal_a11y_e_cell_add_state

  -> libevolution-a11y.so.0.0.0 gal_a11y_e_cell_add_state

  <- libevolution-a11y.so.0.0.0 gal_a11y_e_cell_add_state

  -> libatk-1.0.so.0.2809.1 atk_focus_tracker_notify


                     --- Begin Stack ---

      libatk-1.0.so.0.2809.1`atk_focus_tracker_notify

      libevolution-a11y.so.0.0.0`eti_a11y_reset_focus_object+0x209

      libevolution-a11y.so.0.0.0`eti_a11y_cursor_changed_cb+0xb4

      libeutil.so.0.0.0`e_marshal_VOID__INT_INT+0x65

      libgobject-2.0.so.0.2200.0`g_closure_invoke+0xd6

      libgobject-2.0.so.0.2200.0`signal_emit_unlocked_R+0xd94

      libgobject-2.0.so.0.2200.0`g_signal_emit_valist+0x9c8

      libgobject-2.0.so.0.2200.0`g_signal_emit+0x25

      libemiscwidgets.so.0.0.0`e_selection_model_cursor_changed+0x2c

      libetable.so.0.0.0`restore_cursor+0xcf

      libetable.so.0.0.0`etsm_node_changed+0x11

      libgobject-2.0.so.0.2200.0`g_cclosure_marshal_VOID__POINTER+0x65

      libgobject-2.0.so.0.2200.0`g_closure_invoke+0xd6

      libgobject-2.0.so.0.2200.0`signal_emit_unlocked_R+0x1920

      libgobject-2.0.so.0.2200.0`g_signal_emit_valist+0x9c8

      libgobject-2.0.so.0.2200.0`g_signal_emit+0x25

      libetable.so.0.0.0`e_tree_model_node_changed+0x4f

      libetable.so.0.0.0`e_tree_memory_thaw+0x44

      libevolution-mail.so`regen_list_done+0x150

      libevolution-mail-shared.so.0.0.0`mail_msg_idle_cb+0x188
                     --- End Stack ---



      -> libgail.so gail_focus_tracker

          -> libgail.so gail_set_focus_object

          <- libgail.so gail_set_focus_object

      <- libgail.so gail_focus_tracker

      -> libatk-bridge.so spi_atk_bridge_focus_tracker

      <- libatk-bridge.so spi_atk_bridge_focus_tracker

  <- libatk-1.0.so.0.2809.1 atk_focus_tracker_notify

<- libevolution-a11y.so.0.0.0 eti_a11y_reset_focus_object

-> libemiscwidgets.so.0.0.0 e_selection_model_selection_changed

  -> libevolution-mail.so on_selection_changed_cmd

  <- libevolution-mail.so on_selection_changed_cmd

  -> libevolution-a11y.so.0.0.0 eti_a11y_selection_changed_cb

  <- libevolution-a11y.so.0.0.0 eti_a11y_selection_changed_cb

<- libemiscwidgets.so.0.0.0 e_selection_model_selection_changed

-> libevolution-mail-shared.so.0.0.0 receive_done

<- libevolution-mail-shared.so.0.0.0 receive_done

Thanks. The steps and trace are great. I tried to disable a call of atk_focus_tracker_notify
in widgets/table/gal-a11y-e-table-item.c:eti_a11y_reset_focus_object
it's at the end. (the file is located in a11y/table... in 2.28 sources). With it removed the focus event isn't emitted. I do not know whether one should also skip calls of setting the "gail-focus-object", somehow.

But the most issue is that I do not see any way how to check whether table itself has a focus or not, as I have access only to an ETableItem/ECell and such, which doesn't seem to have a connection to the table they are used in (which I would like to use to check whether table has a focus, and only if so, emit the focus changed signal to atk).

Do you have any idea what to do now?

(In reply to comment #9)
> Do you have any idea what to do now?

Is this question intended for me, or an Evolution developer who is familiar with Evolution's a11y implementation?

Hmm, good question. To be honest I'm not sure whom I was asking more than three months ago. If you know the answer for the first paragraph of comment #8, what to do with the gail-focus-object", and the best whether the second paragraph is an issue or not, if it is supposed to emit the signal in some cases, and whether the proposed change from the that comment forbids it or not, then even better, because I'm pretty bad in properly testing a11y bugs myself.

I'm not 100% sure. From your description, I'd not set the gail-focus-object.

But rather than guess, I should probably set aside some time to build Evolution so that I could test any proposed patches that you have.

Hi!

I know that last comment has more than a year, but I want to know if this bug still make sense.

First of all, I'm using:

Ubuntu 9.10, codename Karmic
Orca 3.1.2pre
Evolution 2.28.1 (I'm cloning from git for to give a try with latest evolution's code)

I was trying to reproduce it, but notifications aren't show up if you're in a compositing window, when mail arrives, I get a 'DEBUG: Evolution is focused' in evolution's debug lines.

So, don't know if this behaviour is expected or it's a new bug from evolution. But, from the pov of accessibility, do this bug still make sense?

Regards!

(In reply to comment #13)
> Evolution 2.28.1 (I'm cloning from git for to give a try with latest
> evolution's code)

Good, because 2.28.1 is too old, latest stable is 3.0.2. This bug got stuck due to lack of reproducibility on my side, and partly on a poor understanding of a11y internals, also on my side.

Still 100% reproducible as described. I am using GNOME 3 and Evolution 3.0.2. Try the steps I listed in comment #6.

On a related note, I was chatting with Javier about this issue in IRC, and he said:

< jhernandez> if you are in a "new message window", I realized that dialog doesn't lose focus

To be clear, if you are not using ATs and just interacting with Evolution like a typical, sighted user, you should not see any problem.  I'm updating the summary to (hopefully) better reflect what the issue is.

Thanks!

Ok, 

lot of thanks! ;)

Created attachment 189320 [details] [review]
proposed evo patch

for evolution;

I think I got a way check whether the table is focused or not. Please give it a try.

One thing I'm not sure about, how do I disable a11y in Gnome 3? There used to be an option in Gnome 2, but the "simplified" settings in Gnome 3 seems to me too much simplified. I enabled a11y by running Orca, but I do not know where to disable it.

(In reply to comment #18)
> One thing I'm not sure about, how do I disable a11y in Gnome 3? There used to
> be an option in Gnome 2, but the "simplified" settings in Gnome 3 seems to me
> too much simplified. I enabled a11y by running Orca, but I do not know where to
> disable it.

You can disable it using gsettings by using the commandline like this:

gsettings set org.gnome.desktop.interface toolkit-accessibility false

Then, you must to log-out and log-in to take effect.

Regards!

Javier, is this obsolete with 3.4.x or 3.5.x, please? I'm not much good in testing a11y bugs, that's why I asked you for testing the patch here.

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

Comment on attachment 189320 [details] [review]
proposed evo patch

$:andre\> git apply --check 483452.patch
error: widgets/table/gal-a11y-e-table-item.c: No such file or directory
error: widgets/table/gal-a11y-e-table.c: No such file or directory
error: widgets/table/gal-a11y-e-tree.c: No such file or directory

GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. 
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org (resources are unfortunately quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
and create a new bug report ticket at
  https://gitlab.gnome.org/GNOME/evolution/-/issues/

Thank you for your understanding and your help.