Closed Bug 743568 Opened 12 years ago Closed 10 years ago

Thunderbird message list tree emitting incorrect focus signals after message deleted

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla30

People

(Reporter: jdiggs, Assigned: jwei)

References

(Blocks 2 open bugs)

Details

(Keywords: access)

Attachments

(4 files)

event listener
628 bytes, text/x-python
Details
logs with A11yLOG=focus
7.48 KB, application/octet-stream
Details
Fire name change events when a row's name updates
4.33 KB, patch
tbsaunde
: review+
Details | Diff | Splinter Review
Fire name change events when a row's name updates - alternate
4.22 KB, patch
surkov
: review+
Details | Diff | Splinter Review
Attached file event listener — 
Originally filed against Orca:

> When scrolling in the message list of thunderbird, sometimes orca reads wrong
> subject and sender about the current message.
> 
> To reproduce try the following steps:
> 1. Send to yourself four messages. Each message must have a different subject.
> I'll use:
> test 1
> test 2
> test 3
> test 4
> 
> 2. After the messages were received, localize the first message sent. In my
> case the message with the subject test 1.
> 
> 3. Press the delete key.
> The message will be deleted and orca will read informations about the next
> message sent, in my case test 2.
> 
> 4. Press the down arrow.
> Orca will read informations about the message with the subject test 3, as
> expected.
> 
> 5. Press down arrow again.
> Orca should read informations about the message with subject test 4, but in my
> environment orca reads informations of the message with subject test 2,
> although the message with the focus is the message with subject test 4.
> 
> In my opinion this is critical because sometimes I delete wrong messages.
> I am running ubuntu 112.04 with all updates and latest orca built from master.

I have attached a simple event listener which illustrates the problem. Here is the output captured when performing the steps described above:

  object:state-changed:focused(1, 0, 0)
        source: [list item | test 1 Joanmarie Diggs 10:47 AM]
        host_application: [application | Thunderbird]
  >>> KEY PRESSED: Delete
  <<< KEY RELEASED: Delete
  object:state-changed:focused(1, 0, 0)
        source: [list item | Unread test 2 Joanmarie Diggs 10:48 AM]
        host_application: [application | Thunderbird]
  >>> KEY PRESSED: Down
  object:state-changed:focused(1, 0, 0)
        source: [list item | Unread test 2 Joanmarie Diggs 10:48 AM]
        host_application: [application | Thunderbird]
  <<< KEY RELEASED: Down

The first two events (initial focus and focus after pressing Delete) are correct. The third event should be for Unread test 3; not Unread test 2.

Note that on occasion the bug did not occur for me, but if I start the listener and then start Thunderbird, it's pretty reliable.
Trevor, get a minute to take a look?
Blocks: focuseventa11y
Hey all, any news about this bug?
confirmed as described.
Any news here?
Flags: needinfo?(trev.saunders)
It seems that the problem is still present in version 24 of TB.
I can't reproduce on windows. Trev, did you have a chance to give it a try?
Can I help in some way?
I can for example run a special version of TB with some debug or test a new version to check if the problem persists.
Could you set A11YLOG=focus; environment variable, run debug build and then put the log here please (whole output)?
Forgive my ignorance, but when you say run debug build you mean running a version of TB compiled with debug options?

If yes, are there some place from where I can download a compiled version or do I need compile such one? 
Thanks.
(In reply to José Vilmar Estácio de Souza from comment #8)
> Forgive my ignorance, but when you say run debug build you mean running a
> version of TB compiled with debug options?

right

> If yes, are there some place from where I can download a compiled version or
> do I need compile such one? 
> Thanks.

probably not, it's worth to ask tb guys but you should try to get a nightly build and see if it logs anything (ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/)
yeah, sorry I haven't had time to set up thunderibrd and try it, it would be great if someone who actually uses it could work on this stuff!

You should be able to get a debug at for example ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/tinderbox-builds/comm-central-linux64-debug/1380026708 there's a file thunderbird-blah.tar.bz2 in there, and you can replace linux64 with linux32 if you need that.
To reproduce the problem, I've 4  messages in my inbox with the following subjects:
test 1
test 2
test 3
test 4

After I delete the test 1 message, orca reads the test 2 message as expected.

If I press the down arrow key, orca should reads the test 3, the next message. However orca reads test 2 again.
Pressing down arrow again, orca reads test 3 insteade of test 4.
(In reply to alexander :surkov from comment #7)
> Could you set A11YLOG=focus; environment variable, run debug build and then
> put the log here please (whole output)?

Done, I hope that in the correct way.
May I ask you to do the logging for steps to reproduce like: open thunderbird, focus 1 message, delete it, ..., close thunderbird. Otherwise it's really noisy.
(In reply to alexander :surkov from comment #13)
> May I ask you to do the logging for steps to reproduce like: open
> thunderbird, focus 1 message, delete it, ..., close thunderbird. Otherwise
> it's really noisy.

To reproduce try the following steps:
0. launch orca.
1. Open TB.
2. Send to yourself 4 messages, each one with a different subject.
I will use "test 1", "test 2", "test 3" and "test 4".
3. Make sure that messages are not groupped by thread.
4. Go to the message list.
5. Focus the message with the subject "test 1" pressing the up/down arrows and make sure that the 4 messages are one imediatelly after the other.
6. Press the delete key.
Orca will announce that the message was deleted and then reads test 2 as expected.
7. Press down arrow.
Orca should read test 3 but reads test 2 instead.
8. Press down arrow again.
Orca should read test 4 but reads test 3 instead.
Jose, I hoped you can provide me a shorten log as I asked in comment #13. I tried to reproduce it myself but no luck as far.
Hello,
I am afraid I have found another test case illustrating issue which might be easier to reproduce.
The same is happening while using lightning
Steps:
0) Make sure thunderbird and orca both are running
1) Go to the menu and activate the calendar.
2) Set the day view, choose yesterday's date and in the events filter choose selected day events.
3) Enter a few events into the calendar with yesterday's date.
4) Notice only these 2 events are displayed in the events list.
5) Focus the event filter combobox where you have chosen selected day events in step 2 and change it to all future events by pressing up arrow key.
6) examine the events list. Visually it really displays future events. But while using orca arrowing up and down using the arrow keys I can also hear yesterdays event being presented to me.

On Windows this is not happening. However on Linux this is really really critical. I was using thunderbird with message threading disabled. Now I have tried to also start using calendar on linux and this became apparent and critical to me.
(In reply to alexander :surkov from comment #15)
> Jose, I hoped you can provide me a shorten log as I asked in comment #13. I
> tried to reproduce it myself but no luck as far.

I am afraid it is verry difficult if not inpossible to produce a shorter log. The issue appears as if accessibility info is not always recalculated when something changes in a list. However when closing and opening the window, moving into another folder or doing something else what also affects other parts of the UI this issue does not happen. If you can please try to reproduce my use case with lightning installed.
Hello,
I think I have new easier steps on how to reproduce this. Unfortunatelly it affects lists in general not just deleting entries.
0) Make sure Firefox and Orca both are running
1) open the page :about:config and locate a boolean option e.g. accessibility.typeaheadfind.enablesound
2) Observe how it's reported to the user using Orca and make sure you can remember its value. By default it is set to true and on my install it's also being reported as such.
3) Press the applications key to bring up the context menu and hit the enter key on the item saying change.
4) Now the value of that option in the list should have changed. It's being changed and shown on the screen like so but orca still reports the original value when arrowing in the list.
5) After closing the about:config window and opening it again you can notice the correct value.

Can you please try to reproduce this and work out if this is the same issue?
Hello,
Unfortunatelly I have another easy place to see this issue in action.
This can also be seen in the Tools -> Downloads. While a file is downloading it is usually displayed as the first item in a list. Transfer speed and how much has already been transferred are constantly updating. This is not updating while using with Orca on linux.
Hi Peter,

In Orca master branch and gnome-3-12 branch this issue partialy fixed with Firefox related.
Oldest time if you opened the downloads directory for example with CTRL+SHIFT+Y key combination if you downloading a large file, Firefox producing very chattiness output for Orca. Orca always spokened numbers until the download process is running (you hear always 1, 2, 3, 4, 5, 6, etc) numbers until the download process is not finished after downloads directory opened, both in Firefox main window and Downloads directory window.
Joanie fixed this partialy issue with live regions related I think, now only the progress bar levels are updating Orca when announcing the change (until entire download process you hear only the progress bar level changes).
You are true with other informations related, transwer rates is not updating automaticaly Orca side. So, the two issues I think separate issues (very chattiness output related issue and other informations related update issue).
Trevor, you confirming this with Firefox and Orca side?

Attila
Well now we are tallking really about two unrelated issues. The over verbosity you have mentioned fixed in orca 3.12 is presence of legacy code which tried to identify so called live regions in places where there are no live regions declared by the app developers. Without realizing these numbers are part of a list item orca was presenting them as a live region updates and you would hear it being spoken even if you were browsing a site in another firefox tab or even inside another firefox window.
Lists and list items are being made accessible through standard accessibility API's at Firefox side that's its ATK implementation and at orca's side that's dependency on py-at-spi2 I believe. Through this channel orca is getting no updates when something changes in these lists including thunderbird message list, list of files in firefox download window and also list of settings at the about:config page and also list of events or list of tasks in lightning. I assume all XUL lists might be affected but I have not enough expertise to prove that with an experimental output.

Greetings

Peter
If a row's name changes (due to insertion/deletion of other rows or cell contents), then notify ATK so it's updated.
Assignee: nobody → jwei
Attachment #8389401 - Flags: review?(trev.saunders)
Comment on attachment 8389401 [details] [diff] [review]
Fire name change events when a row's name updates

bleh
Attachment #8389401 - Flags: review?(trev.saunders) → review+
Flags: needinfo?(trev.saunders)
https://hg.mozilla.org/mozilla-central/rev/a26842289599
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
A grid row name is composition of cell names. Don't we have a better approach than to double cache this info? Isn't it heavy to recalculate names for each invalidated row? How the fix would look like if bug 664384 has been ever fixed?
(In reply to alexander :surkov from comment #26)
> A grid row name is composition of cell names. Don't we have a better
> approach than to double cache this info? Isn't it heavy to recalculate names
> for each invalidated row? How the fix would look like if bug 664384 has been

I guess we could actually use the cache when getting the name which would make this a bit faster, but that seems riskier and I don't really care to fix regressions from that.

> ever fixed?

I guess we wouldn't have this bug then, but given people care about the bug I guess we can't really fix it.
Fire name change event if any child cells have changed, skipping the name recalculation per row invalidation.
Attachment #8390676 - Flags: review?(surkov.alexander)
Comment on attachment 8390676 [details] [diff] [review]
Fire name change events when a row's name  updates - alternate

Review of attachment 8390676 [details] [diff] [review]:
-----------------------------------------------------------------

nice, thanks, r=me

::: accessible/src/xul/XULTreeGridAccessible.cpp
@@ +410,5 @@
>        }
>      }
>    }
>  
> +  if (nameChanged) {

nit: you don't really need {} around single if in a11y module

::: accessible/src/xul/XULTreeGridAccessible.h
@@ +177,5 @@
>    NS_DECLARE_STATIC_IID_ACCESSOR(XULTREEGRIDCELLACCESSIBLE_IMPL_CID)
>  
>    /**
>     * Fire name or state change event if the accessible text or value has been
> +   * changed.  Return true if name has changed, and false otherwise.

nit: extra space before 'Return'

usually we follow the pattern

@return  true if name has ...
Attachment #8390676 - Flags: review?(surkov.alexander) → review+
Hello,
I think this is partially fixed.
When an item is removed the content is correctly reordered. E.G. in the list of files in the download window. However while download is inprogress the size and percentage are constantly being updated. While arrowing up and down in the list I think the info should be updated if arrowing more than once over the item where the values are updating.
Also the name is correctly recalculated e.g. on the about:config page when changing item's value.
I haven't yet tested thunderbird and lightning. Test performed so far was done with Firefox 30 17 mar nightly.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: