OK, that shouldn't have submitted, not sure why it did. Let me try again. Running the following Shiretoko:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090122 Shiretoko/3.1b3pre

When I enter the awesome bar, edits or cursor navigation sometimes don't provide speech feedback. Typing works fine, but arrowing back and forth or attempting to delete text doesn't speak.

I can't always replicate this. Sometimes it goes bad after a few hours of use. Sometimes, like just now, it fails as soon as I start the browser. Restarting Orca or FF doesn't seem to resolve this.

I reported a similar issue in betas of 3.0. That issue went away on final release, and I very rarely saw it in 3.0 (though I could be misremembering.) It has returned in 3.1.

Attached is a debug log wherein I try navigating an address bar, enter text into the google search and then try navigating/editing. The logs show receipt of keypresses but no speech feedback. Notice that there are indeed side effects, however. In the google search, "This is a test." is entered, some text is deleted, then when the search field is returned to, "This is a tes" is what is spoken.

Created attachment 127068 [details]
Log file of a failing session

(In reply to comment #1)

> Attached is a debug log wherein I try navigating an address bar, enter text
> into the google search and then try navigating/editing. The logs show receipt
> of keypresses but no speech feedback. 

Also note the complete lack of events. Resulting from your keypresses. We should be seeing a bunch of caret-moved events. We can't present stuff if we aren't told they have even taken place. :-(

This feels (to me) like the Preferences (and other dialogs) Mozilla bug. What happens after you do a bit of typing if you try to Alt+Tab into another window and then Alt+Tab back? Do the events show up (and get spoken, etc?)

Sorry, had to wait until this popped up again, but no. Switching away and back doesn't resolve it for me. IIRC, neither does restarting the browser, or indeed, restarting X. That, to me, is the strangest. I'll have to re-confirm that last bit, but I'm fairly certain of it.

In playing with this some more, I wonder if the autocomplete feature of the address bar and search box are causing caret movement events to go AWOL?

*** This bug has been marked as a duplicate of 404403 ***

I agree with Will--I think it is related to autocompletion. when I was playing with this a few days ago, I would occasionally hear fragments from the autocompletion list. Also, when I pressed the down arrow to get into the autocompletion list, then escape to return to the location edit box, I would get speech output events without delay.

I'll attach a debug log showing the behavior.

Created attachment 130372 [details]
Debug log showing impact of autocompletion list on speech 

Using Firefox (Minefield) 3.2a1pre.
Log starts with firefox open. Screen saver kicks in because I got a phone call as the log started. Open new tab and start typing a URL that I know is in the autocompletion list.  After typing enough to generate the correct autocomplete, press the down arrow, followed by the escape key. Press keypad-Enter to determine what I have in the edit box, then complete the URL with speech.

Thanks David. What your log indicates is that we're getting bombarded by events when you type. What Nolan's indicates is that he's pressing arrow keys and not getting any speech (because we're not getting any caret-moved events from Firefox).

So....

1. Unless I'm missing something, David's issue is not the same as Nolan's issue (aka it's a different bug).

2. I still cannot reproduce Nolan's bug. And once I get to the point that I can, all I will be able to do is file a bug against Firefox and block this one.

3. I'm not sure what to do about the issue David's reporting.

Sorry to be dense, but I could use some guidance from someone. Will suggestions?

I spoke with Will about this bug this afternoon.

David, as you've probably seen, I've opened bug 583289 for your observations.

Nolan (and David, and anyone else): I still cannot reproduce the bug in the opening report and reflected by Nolan's debug.out. That bug as I understand it, boils down to this:

--------
Steps to reproduce:

1. Type some stuff in the location bar

2. Use the arrow keys (in particular, Left and Right) to review the text.

Expected results: Orca would present the text (character) at the new location

Actual results: Orca fails to present the text (character) at the new location.

Reason why: Orca is not getting any caret-moved events from Firefox to let it know that the location has changed.

Action to be taken: File a bug against Firefox because there's nothing we can do on our end.
--------

Were I able to reproduce this bug, I would be happy to file the Firefox bug and block this bug against it (and then close it as NOTGNOME once the Firefox bug was fixed). Because I cannot reproduce this bug, I would ask that people who have experienced it in the past attempt to reproduce it in the latest release of Firefox. If it is reproducible, please give me the precise details that work every time so that I can attempt to recreate your environment and then file the bug -- alternatively, feel free to file the bug yourself. :-) If it is no longer reproducible, then this bug is no longer a bug. :-)

Thanks guys!

Just for the record, I did get Firefox/Orca into the state where I could not navigate by character in the location or Google search edit boxes (Firefox 3.6a1pre, Orca pulled yesterday from git). However, I have spent twenty minutes trying to figure out how to get back into that state and have failed. I'll try pounding on it some more tonight.

One issue, though: gnome 2.24.1 with Orca 2.27.2pre. I don't know if this has a role in it. And, yes, I'll upgrade to 2.26 sometime soon, as time permits... ;-)

Thanks for the confirmation David. It would be great if you could keep trying.

In the meantime, I'm retargeting this for FUTURE. I cannot do anything about it until I can reproduce it. Once I can reproduce it, all I will be able to do is file a bug against Gecko and block this one against it -- at which point this bug would get retargeted for FUTURE because we have no control over the bugs that are blocking us.

This might be a Firefox bug. I have found the following test case:

1. Open preferences and set your start page to blank. Don't use a start page.
In this case everytime we open Firefox it starts initially at the address or location text edit.
At this casse no problem, Firefox dispatches all text events to ATSPI.
Same occurs if you set E.G Google home as a start page, since the focus initially is in the search text field. 
Seems that Firefox needs a text widget focused when it start to activate the text event dispatcher. Very odd thing.

2. Set another page as start page to cause Firefox not to be in a text widget. E.G www.tiflolinux.org
Then go to location text or search text one, and try to move the cursor left/right.
Surprise!  No events comes from Firefox :-(

Just touching base:

I see this behavior all the time. In fact, it's rare that I *don't* see the behavior. This is under Ubuntu 9.04, though I saw it under 8.10 as well, with every version of Shiretoko I've tested.

While I don't understand either the Orca or Gecko internals well, it makes sense to me that this would be a Gecko bug. Should we file the Mozilla bugs as affected users and link to this one? Sorry if it's a silly question, just wanted to be clear on whether or not I should file the bug myself as to avoid dupes. :)

Thanks.

(In reply to comment #12)
> This might be a Firefox bug. I have found the following test case:

Javier, you sir are a genius. Nice work!!! Totally reproducible. Bug filed here: https://bugzilla.mozilla.org/show_bug.cgi?id=494802 Thank you, thank you, thank you. Blocking this bug.

(In reply to comment #13)

> I see this behavior all the time. In fact, it's rare that I *don't* see the
> behavior. 

Based on Javier's findings, that makes sense now. I always start out with my home page as a blank page. Many people start out with it being google.

> Should we file the Mozilla bugs as
> affected users and link to this one? Sorry if it's a silly question, just
> wanted to be clear on whether or not I should file the bug myself as to avoid
> dupes. :)

It's not a silly question at all. If you are sure that it's a Firefox/Mozilla bug and not an Orca bug, yeah, that would be great. The trick, I've found, is to present the bug as independent of Orca if you can, namely:

1. Don't file the bug as "Orca doesn't speak such and such". Instead indicate the events (or states or whatever) which are missing or otherwise bogus.

2. Becoming less necessary, but I try to provide instructions for how to reproduce the bug using Accerciser as the diagnostic tool.

Also, we've got habits: <smile>

1. File it against core rather than Firefox. Component, disability access APIs.

2. Block Mozilla bug 374212 (it's the Orca metabug in the Mozilla bugzilla).

3. Add browser-china-atf@sun.com to the CC field.

4. Add keyword "access"

It's all detailed here: http://live.gnome.org/Orca/MozillaBugs (It sounds like a lot to remember, but once you do it a few times, it becomes second nature. Trust me.)

All of this said, I don't mind being the one to file the bugs based on Orca bugs as was done here. But, as was the case here, I cannot always reproduce the problem, even with a full debug.out. :-( What Javier did in comment 12 made things super easy for me.

The blocking bug has been fixed by the Mozilla a11y guys. I can no longer reproduce the reported problem in Orca.