Created attachment 112005 [details] [review]
Revision #1

Here's a first attempt at improving this. A few notes:

When you initially get the "window:activate" event for the spell
checking dialog, it'll be spoken as a dialog. This includes speaking
all the unattached labels. That's where we are getting all that 
verbose output from.

  SPEECH OUTPUT: 'Thunderbird application'
  SPEECH OUTPUT: 'Check Spelling Misspelled word: porly poly poorly 
                  portly Corly Personal Dictionary: Morly porgy porky'

What I've done is add in two chunks of code:

  a/ In the onFocus() method in the Thunderbird script:
     If we get a "focus:" event for the "Replace with:" entry in the
     spell checking dialog, then clear the current locus of focus so
     that this item will be spoken and brailled.

  b/ Add an onNameChanged() method to the Thunderbid script:
     If we get a "object:property-change:accessible-name" event for
     the first item in the Suggestions lists for the spell checking
     dialog, then speak the first two labels in that dialog. These
     will by the "Misspelled word:" label and the currently misspelled
     word.

This does seem to nicely improve things. When you've finished doing
the spell checking, focus will move to the Send button.

Like with spell checking for Open Office and gedit, we could do a lot
more, but this was a relatively straight forward simple fix that's good
bang for the buck.

This is working much better.  For the first misspelled word, the misspelled word is identified, followed by the first suggestion, then followed by all the verbose speech output in comment #1 (it would be nice if this verbose speech could go away). For all subsequent misspelled words, the misspelled word and the first suggestion are spoken, which is a wonderful improvement! So, it looks like your patch is working perfectly. 

Thanks!

Thanks David. I think I should be able to make the verbose speech
output go away (and leave the other bits). Hopefully I'll have a 
new patch for you to try tomorrow.

I've been thinking about what might be the most appropriate speech feedback when this dialog gets focus.  With Verbosity set to brief, I would suggest, if it is possible, to just say "Check Spelling misspelled word porly suggestion: polly". With Verbosity set to Verbose, it might be something like "check spelling using personal dictionary, language English misspelled word porly suggestion: polly". 

I don't know if these suggestions are feasible or even sound good to others, but I put them forward. Thanks.

It all depends on how far you want to go. OpenOffice and
gedit even give context for the misspelled word; give it 
a try to see what I mean. Well, with OOo you are going to have
to wait a little bit, because the OOo folks broke it again 
in OOo 2.4. Should nicely work for gedit though.

My intention tomorrow is to add another small chunk of code
to try to reduce the verbosity of the "window:activate"
event down to:

  SPEECH OUTPUT: 'Thunderbird application'
  SPEECH OUTPUT: 'Check Spelling'

The "Misspelled word ..." should still happen, plus the first
list item plus the "focus:" event for the "Replace with:".

One other possibility is to remove the announcement of the
list item.It's kind of bogus that it gets a "focus:" event
anyhow. Alternatively we could file a bug against Thunderbird 
so we don't get a focus event for that component, and then 
the problem would just go away.

I would prefer to press a hot keyto hear context, just to cut down on the verbosity.  Also, a hot key allows the user to hear the context multiple times, if the user misses the context the first time it is spoken.  Just my two cents...

Created attachment 112061 [details] [review]
Revision #2.

This patch also removes speaking the unassociated labels
for the spell checking dialog.

This is a definite improvement 

This is much better.  When I first press control-Enter, and activate the Send button, I hear "Check Spelling misspelled word porly poly replace with: text poly selected". Note that Thunderbird application is not spoken, which I am happy about. However, if I hit escape and go back to the message, then "send" it again, allowing all speech to complete within the "ready to send" dialog before activating send, the speech gets to be a little out of order.  What I hear is "misspelled word porly Thunderbird application check spelling poly replace with: text poly selected". (Note that, if I don't let speech complete in the ready to send dialog, I get the proper output.)

I would like to have the focus event in the suggestion list not spoken, for what it is worth.  Thanks!

Patch committed to SVN trunk. Moving to "[pending]".

W.r.t. to David's comments:

Orca will speak things depending upon the order in which 
it receives the events. Sometimes things are a bit out 
of order. 

After thinking about this, I'm not sure there is an easy way
to remove the speaking of the focus: event for the list item
in the Suggestions list. We need to be able to speak that if
the user navigates to that item. How do you easily differentiate
between the focus: event as a result of the navigation and the
bogus one that we get when the window is first activated.

If any body has a good suggestion on this, then I'll see if I can
create a patch for it.

Will had a good suggestion on this that I need to check.
Come the time that we process the focus: event for the list
item asynchronously, check to see if the list item has the
FOCUSED state. If it doesn't, then just ignore it.

More on this once I've tried it.

Should I file another bug report for Thunderbird not speaking the context of the misspelled word?

> Should I file another bug report for Thunderbird not speaking the context of
> the misspelled word?

Joanie mentioned that she was going to do that I think.

Created attachment 112096 [details]
Orca debug out generated whilst spell checking the given example.

David, with regards to the problem you mentioned on the Orca mailing list:

>However, in the process of testing Orca's support for the spell check 
> dialog, I found that the spell checker seems to skip obviously 
> misspelled words on occasion. 

I think it's getting all the misspelled words, but it's not always
generating the events for us to properly announce them. Attached is
an example where I did get all the events. 

If I select a given word from the "Replace with:" text 
entry field by pressing Return (rather than selecting from 
the list), there will be no new "focus:" event for the 
"Replace with:" text entry field (because we are
already there), so the next misspelled word won't get spoken. I
suspect this is what's happening to you. 

The attached example above is where I deliberately went 
down to the list each time to find a replacement word.

I'll take a look at the example and try to follow your process and see what happens.  However, I know that, if I always tab to the "Replace" button (moving focus out of the text box), the word message is still skipped.  I'm also puzzled by how, even if Orca doesn't receive an event, the spell check dialog skips the misspelled word ("messsage" shows up in the sent message).  I would expect Orca to go silent as a result of not receiving a focus event--the misspelled word, messsage, should still be there unless the spell check dialog receives some signal to ignore the misspelled word and move on to "itt". But, I'll take a look later on tonight. Thanks.

Hi, Rich, 

I did find that, if I selected something from the suggestion list for "spelt", I did receive the word "messsage" as a misspelled word.  However, if, instead of selecting "poorly" from the list, I just edited the "poly" in the change to text box to "poorly" and pressed Enter, "spelt came up as the next misspelled word.

I tested the possibility that the problem was brought about by there not being a option to choose in the suggestion list by using the text "This is a griteful prolbem to fisx."  The spell checker didn't provide "frightful" as a possibility for "griteful", so I typed it in and hit enter, but Thunderbird found "prolbem as the next misspelled word.  

Could you, or someone , test the original test sentence without Orca running and see if the spell checker picks up "messsage" after the user has typed in "spelled"?  That might be the best way to determine if Orca is, in someway, related to this problem.  Thanks!

Created attachment 112153 [details]
Orca debug showing that "messsages" is not picked up as a misspelled word.

Hi David. 

You are absolutely correct. If you type "spelled" into
the "Replace with:" field and press Return, Thunderbird 
skips "messsages" and goes straight to "itt".

I tried this both with and without Orca running. Same
result. I've attached an Orca debug.out log file showing 
this.

This has to be a Thunderbird problem. Could you file a bug please?

Thanks!

OK, I'll file a bug at Mozilla tonight or tomorrow.  Thanks! 

Created attachment 112157 [details] [review]
Patch to fix bogus suggestion list item utterances.

Suppress speech for bogus 'focus:' and 'object:state-changed:focused' 
events for the spell checking dialog suggestion list items. 

Patch committed to SVN trunk.

Please test further, but I think this on is close to being done. At
least from the Orca side.

unfortunately, I'm still getting the list focus event for the first misspelled word.  After that, however, that focus event is not spoken.

One other suggestion... I just noticed that, after the first misspelled word, the text box label "replace with" is not spoken before the contents of the text box.

What I'm currently getting is the following for the first misspelled word:

"check Spelling misspelled word porly poly replace with text poly selected"

After that, I am getting:

"misspelled word spelt slept"

In this second case, I would love to have:

"misspelled word spelt replace with slept selected"

I'm using trunk rev 3960.

Thanks!

Created attachment 112162 [details]
Orca debug log - revision 3960

I'm not seeing (or rather hearing) these problems David.
See attached log file.

Could you please attach a debug.out of your own so I can
see what's different in your case.

Thanks.

Created attachment 112165 [details]
debug output during spell check, trunk rev 3960

I found out why I wasn't getting more feedback on the misspelled words after the first one.  If you type the correct word in the text box and hit enter, the amount of speech output reduces.   For the first misspelled word, "porly",  I tabbed to the suggestions list for "poorly", and the second word had full feedback. However, typing spelled for the second misspelled word and hitting enter reduced the feedback for the word "itt".  Hope this helps.

> I found out why I wasn't getting more feedback on the misspelled words after
> the first one.  If you type the correct word in the text box and hit enter, the
> amount of speech output reduces.

Yup. I mentioned that in comment #14:

"If I select a given word from the "Replace with:" text 
entry field by pressing Return (rather than selecting from 
the list), there will be no new "focus:" event for the 
"Replace with:" text entry field (because we are
already there), so the next misspelled word won't get spoken."

Thanks for the debug.out. I'll have a look at it and comment 
back later.

Okay, so I've had a look at it. The reason why you are getting
those list items spoken is that at the time we process the event
that list item has focus (i.e. the object has a FOCUSED state). 

When I test this, I don't get them because there have been more 
events and the focus has moved on (presumably to the 
"Replace with:" text entry).

I'm not sure there is much I can do about this. 

As a side note, Joanie just tried this on Ubuntu Intrepid (EA)
and she doesn't see any "focus:" or "object:state-changed:focused"
events at all for the list items (unless you navigate there).
Which is a great improvement if this is always the case.

We live in interesting times.

OK, this is a slow old machine--it was top of the heap when bought ?? years ago with a 1.4 GHz processor.  So, events get more time to get noticed... c'est la vie.  I may have to buy a new machine... ;-)

It looks like this bug is done.  Thanks for all the work!

If david is happy with this one after more testing I am as well.  

> As a side note, Joanie just tried this on Ubuntu Intrepid (EA)
> and she doesn't see any "focus:" or "object:state-changed:focused"
> events at all for the list items 

Rich, I'm afraid I misunderstood what "this" was.  I was looking for bogus events that were being emitted upon the appearance of the dialog.  Sorry about that!!

Based on your clarification (from email), I am seeing the events.  But I would argue that, while they are not ideal, they are also not bogus.  Assuming I am now performing the steps correctly, here's what I'm doing and seeing:

1. Type "this is a porly spelt message, isn't itt?"

2. Press Control+Enter to send the message (forcing the spell check to be executed because I had altered my preferences to spell check before send).

3. The first problematic word is 'porly.'  I want 'poorly' so I tab twice to get to the Suggestions: list and press Down Arrow to select "poorly."

4. Having made my selection, press Return for the default button Replace.

Now here's where, as I understand it, things start looking bogus.  What's taking place?

A. **Focus remains inside the Suggestions: list**, BUT the list items related to 'porly' are no longer relevant and hence removed from the list. 

B. The list is repopulated with the items relevant to the new problematic word, 'spelt'. Because focus has never left the list, but the contents of the list have been removed and repopulated, focus is on a brand-new list item namely the first item in the Suggestions list.  We get a focus: event followed by an object:state-changed:focused event to inform of us that this change has taken place.  (IMHO, were those events missing, I would consider it a bug.  Focus has definitely changed and the first item in the reconstructed list seems to be what's focused.)

C. The Replace With: entry takes as its initial value the first item in the Suggestions: list.  i.e. we can't update the entry until we know what's going in the list.  Thanks to B, we now know what value needs to go into the entry, so insert that text.

D. Now that the entry has the updated value we need to address 'spelt', we're ready to go.  Therefore, put focus in the Replace With: entry.  This results another focus: object:state-changed:focused pair for the entry.

The end. :-)

Like I said, not ideal from our point of view, but is it a bug?  And, if so, what's the fix?

As I mentioned above, if these list item focus/focused events were removed by the Mozilla guys, I'd consider it a bug.  Those events seem appropriate. Granted we want to ignore them, but I think that decision is best left to us (i.e. the AT side).  

I assume that we don't want to get the focus: object:state-changed:focused events for the Replace With: entry *until that entry's value has been updated.* Otherwise we'll speak the old text first.  Plus, doing a check to see if it still had STATE_FOCUSED (and ignoring it if it did not) wouldn't work because ultimately it winds up being the object that gains focus. So changing the order in which the entry gains focus doesn't seem like a good idea to me.

Maybe we could file an RFE asking for focus to be removed from the list prior to repopulating it.  And maybe that would work.  I dunno XUL.  However, based on what takes place with web content:  If focus is removed from the currently focused item via javascript and not given to some other focusable object, focus apparently still has to land *somewhere* and it lands on the document frame.  This causes all sorts of inconvenient things (from our perspective) to occur. :-(  If XUL works the same way, i.e. *something* must always have focus, such an RFE might make things worse -- or at least different, but no better: after all, what should get focus in this case?  As I mentioned in my previous paragraph, I don't think at this point we're ready for it to be the entry.  If it's the frame, we don't want to speak that again so we'll have to identify and weed that out.  *shrugs*

So.... At team meeting we agreed that I would file the appropriate bug against Thunderbird in Mozilla's bugzilla.  In light of the above, and Rich's ability (as I understand it) to handle these two unwanted events gracefully on our end, is there still a bug to be filed?  If so, let me know what it is and I'll be happy to do so.

Thanks! (And, again, Rich sorry for the earlier mixup.)

> In light of the above, and Rich's ability
> (as I understand it) to handle these two unwanted events gracefully on our end,
> is there still a bug to be filed?

No. It's not needed. Thanks for diving deeper.

Closing as FIXED based on Mike's verification which somehow got lost.

(In reply to comment #13)
> > Should I file another bug report for Thunderbird not speaking the context of
> > the misspelled word?
> 
> Joanie mentioned that she was going to do that I think.
> 

This is I think something else.  If I'm understanding Dave correctly, what he wants to hear somewhere in all of the information (or be able to quickly obtain via a keystroke) is the sentence (or line) in which the error occurred.  

Example:  

Intended message body:  "Uncle Dave is feeling poorly.  Sadly, he'd probably be doing better were he not so portly." 

Actual message body: "Uncle Dave is feeling porly.  Sadly, he'd probably be doing better were he not so porly."

Assumption: The user knows how to spell and got distracted while typing, hence the spelling errors are news to her.

Orca says that the misspelled word is 'porly'.  Do I choose 'poorly' or 'portly'?  Who the heck knows?  I know that it's probably one of those two because I know what I meant to write.  But since I didn't realize I made the error, I need to hear the sentence (aka the context) of the error before choosing from among the selections or typing the correct spelling.

Dave, does this accurately describe what you're asking?  If so.... I'm not Rich, but that is an RFE that falls beyond the scope of this bug I think.  So, yes, if you would be so good as to file a new RFE spelling out what the desired behavior is (always speak the context, only speak it at the verbose level, only speak it when you press a certain keystroke, etc.) that would be great.  Thanks!

And if I'm still confused about what people mean, then never mind and I'll go take a nap. <smile>

(In reply to comment #28)
> Closing as FIXED based on Mike's verification which somehow got lost.

Seems that mid-air collisions stomp on summary changes.  Removing the pending that I bet I caused to reappear.  Sorry! 

>>> Should I file another bug report for Thunderbird not speaking the context of
>>> the misspelled word?
>>
>> Joanie mentioned that she was going to do that I think.
>
> This is I think something else.

Yes, you are right. David, I suggest you file this as an Orca
enhancement request, to save Joanie having to do a Vulcan mind meld.

Thanks.

Sure, I'll file an RFE this weekend.  I'll also put it out on the list so that anyone who is interested can comment.