The web pages in question work fine for me on OpenSolaris b131 with Orca from git master and Firefox 3.5.6 (the default that comes with OpenSolaris b131).

Please post a debug file that demonstrates the problem.  Thanks!

Created attachment 152315 [details]
Possible this debug.out file shows what the problem.

Will, possible my original debug.out file is not sent when I write this bugreport, but I am attached. :-):-)
Not matter, I sending another file.
I goed for example the www.ubuntu.hu webpage, and try navigating with headings.

I see following traceback message with debug.out file, possible important:
Traceback (most recent call last):

+ Trace 220265

LookupError above while processing event: object:state-changed:active

Attila

Created attachment 152317 [details]
This screenshot shows www.ubuntu.hu design when I logged in.

I change this bug with critical status, because impossible using with Firefox 3.6 webbrowser if this bug is present.

Attila

Related to this, when using down arrow to read a page and reach an h2 heading, Orca jump back to the top and start at beginning.
See at www.tiflolinux.org, I have first a h1, then there is an h2 using down arrow to read the page Orca cycles between the page top, and the h2 heading.

I also experienced many problems with the cursor jumping all over the place.  I mean it would skip back up to the top quite often and often would skip over parts of the page, namely form elements.  The pages I was trying to do this on did not have any actual heading markups.  I can't remember the exact URL just now but it was at archlinux.org in the AUR which is an area for package build scripts.

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

The issue was introduced by this revision of Firefox/Gecko:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2b1pre) Gecko/20090930 Namoroka/3.6b1pre

What seems to have changed is that doing a grabFocus on the component -- something we used to have to do -- is now causing caret-moved events to be emitted. While I'm not jazzed about this change, I'm not yet convinced it's unreasonable. In which case we need to figure out something....

I can stop the problem simply by not doing the grabFocus we were doing before. But I don't yet know what the consequences of that will be across the board (i.e. all content, all versions of firefox, etc.). I will need to re-set up the regression tests, get current results for multiple versions of firefox, regression test possible solutions across multiple versions of firefox, etc., etc., etc., etc. 

All of this would, of course, be a non-issue if we didn't have to implement our own caret navigation for Gecko content....

On the bright note, I no longer have to worry about what I'll be doing for the next several days. ;-)

Created attachment 153241 [details] [review]
Fix for the jumping around issues

This implements a new setting, which is enabled by default: Grab focus on
objects when navigating. This setting, when enabled, causes Orca to work
like it always has been. If this setting is disabled, it will address
the primary problem reported in this bug. This means if you're using firefox 3.5.x or 3.6.x prior to 30th Sept, you don't do anything. But if you are using firefox 3.6.x between 30th Sept and now, you would want to disable this setting in the Orca preferences dialog for Firefox).

In working on this bug, I discovered another issue which I am nearly positive is not this bug: If you are navigating with Orca controlling the caret and/or using structural navigation, and you press Tab, you will likely not land on the focusable object which comes next as far as you are concerned. You will land on the next focusable object as far as Firefox/Gecko is concerned. This is almost certainly a(nother) Mozilla a11y regression which I will investigate next.

Will, please review. Thanks!

Created attachment 153250 [details]
I sending another debug.out after I applyed the new patch

Joanmarie, I tryed your patch.
For example, I opened a simple news portal webpage with following address:
http://vakbarat.index.hu/belfold/2010/02/07/a_kovetkezo_napokban_mar_nem_varhato_sok_ho/
This is a news. When I pressing two time the h key, Orca spokening to time the first heading level (szerdától megint havazás várható) and not jumping the next heading.
Anybody confirm this with Firefox 3.6?

Attila

Review of attachment 153241 [details] [review]:

I think this is a decent compatible fix and I say commit to 2.29.30.  Thanks!

Phew!

(In reply to comment #9)
> In working on this bug, I discovered another issue which I am nearly positive
> is not this bug: If you are navigating with Orca controlling the caret and/or
> using structural navigation, and you press Tab, you will likely not land on the
> focusable object which comes next as far as you are concerned. You will land on
> the next focusable object as far as Firefox/Gecko is concerned. This is almost
> certainly a(nother) Mozilla a11y regression which I will investigate next.
> 

Please file on BMO and cc me :)

(In reply to comment #8)
> But I don't yet know what the consequences of that will be across the board
> (i.e. all content, all versions of firefox, etc.). I will need to re-set up the
> regression tests,

Hmmm is there some way we can have these run hourly/daily/weekly?

(In reply to comment #14)
> (In reply to comment #8)
> > But I don't yet know what the consequences of that will be across the board
> > (i.e. all content, all versions of firefox, etc.). I will need to re-set up the
> > regression tests,
> 
> Hmmm is there some way we can have these run hourly/daily/weekly?

You certainly can!  I would love it if Mozilla were able to do this -- I believe the last time we proposed this, Mozilla was not staffed appropriately to do so.  But, if you are now, we would love to help you get started.  Who's the right person to work with?

(In reply to comment #15)
> (In reply to comment #14)
> > (In reply to comment #8)
> > > But I don't yet know what the consequences of that will be across the board
> > > (i.e. all content, all versions of firefox, etc.). I will need to re-set up the
> > > regression tests,
> > 
> > Hmmm is there some way we can have these run hourly/daily/weekly?
> 
> You certainly can!  I would love it if Mozilla were able to do this -- I
> believe the last time we proposed this, Mozilla was not staffed appropriately
> to do so.  But, if you are now, we would love to help you get started.  Who's
> the right person to work with?

Cheeky :) Well we'll see...

Are these Firefox specific tests or all of GNOME?

We can discuss in spin off BMO https://bugzilla.mozilla.org/show_bug.cgi?id=544868

Comment on attachment 153241 [details] [review]
Fix for the jumping around issues

Committed to master, string change announced, Orca list notified.

I just updated to latest git (20100208) and tried the new option.  I unchecked it and page navigation seems to be working reliably with Firefox (Namaroka) version 3.6.2.  However, the bookmark stuff is still broken.  See bug 609045.  I guess the problems are not related.  I had hoped they would be but whatever...

(In reply to comment #18)
> I just updated to latest git (20100208) and tried the new option.  I unchecked
> it and page navigation seems to be working reliably with Firefox (Namaroka)
> version 3.6.2.  However, the bookmark stuff is still broken.  See bug 609045. 
> I guess the problems are not related.  I had hoped they would be but
> whatever...

Thanks so much for testing Steve! Yeah, as I just commented on that bug, the issues are almost certainly separate.

If you're able to continue testing.... Things I am aware of:

1. What Attila reports in comment #10 of this bug.
2. Unexpected items gaining focus when you Tab/Shift+Tab while navigating.

Anything else that occurs *when navigating within document content* (i.e. menus, bookmarks, etc. don't count) is news to me and would be helpful to have reported as a comment on this bug.

Joanmarie, I forgot uncheck the new preference when yesterday I tryed your patch.
After I uncheck the new doed setting with Orca application preferences/firefox page, I see following when I try short navigating some webpages:
1. When I going for example the www.belin.hu webpage, jumps for example 3 heading with h key, jumps one heading back with Shift+h key and pressing a Shift+tab key combination, Orca does'nt spokening the correct prewious link with heading.
When I pressed three time the h key, Orca correct spokening the "A rendszer első elindítása" text. When I press Shift+tab key, the correct need jumping link is "A mostani BeLin verzió újdonságai", but Orca spokening another link.

Another interesting problem:
For example I go to home with this webpage, and after this I switch another application window and switch back with Firefox with Alt+Tab key. The caret is changed. For example, when I pressing where am I command, I hear following link: "Tudnivaló néhány akadálymentes alkalmazás használatáról".

Anybody confirm this problems with Firefox 3.6?

Attila

Joanmarie, I see an interesting problem with new committed fix when I using Thunderbird 3.0.
I unchecked with the grab focus on objects when navigating with Orca applications preferences/firefox page.
This is no matter.
But, now I get an e-mail with related an Openoffice.org issue bug, and I would like read this e-mail in arrow keys in Thunderbird.
The e-mail content is following:
"To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=102694


User mt changed the following:

                What    |Old value                 |New value
================================================================================
                  Status|NEW                       |RESOLVED
--------------------------------------------------------------------------------
              Resolution|                          |FIXED
--------------------------------------------------------------------------------




------- Additional comments from mt@openoffice.org Wed Feb 10 11:30:43 +0000 2010 -------
Fixed in cws mtaccfixes

---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification"

When the cursor jumps the first http link and I press the down  arrow key, Orca always repeating the http link text, not read another lines.

I looking the Orca application preferences /thunderbird page. The grab objects focus when navigating check box is unchecked by default. When I checked the check box, this problem is not present.
I see this problem with normal Bugzilla e-mails if this check box is unchecked. Anybody confirm this?

Attila

I use Evolution normally, but just thinking about your description Attila, I can mentally confirm that this would happen. I'll add it to my list. Thanks!

Created attachment 153726 [details] [review]
Give thunderbird its own grabFocusOnAncestor setting

This should solve the problem reported in comment #21. It has already been committed to master.

Attila, I don't *think* it will be necessary, but you might want to delete the Thunderbird.py and Thunderbird.pyc files which can be found in ~/.orca/app-settings and then set your preferences. You should find that the Firefox/Namoroka setting for grabbing focus is independent from the Thunderbird setting for grabbing focus and i.e. you should be able to change one without it changing the other.

(It dawns on me that this will also need to be done for Yelp -- at least for Yelp which uses Gecko. Yelp which uses WebKitGtk is an entirely different matter and bug.)

Created attachment 153732 [details] [review]
Give yelp its own grabFocusOnAncestor setting

Second verse, same as the first.

Unfortunately, unlike Thunderbird, the script for yelp needed to be moved from yelp.py into yelp/script.py because we now need a script_settings.py file specific to yelp. This constitutes a flag day because Orca will (I believe) find the original yelp.py if users don't remove it. I'll notify the orca list.

I also noticed YAI (yet another issue) while working on this. While this change makes it possible to arrow amongst content properly, there are links that are list items that we are not grabbing focus on. It could be that these items are preceded by whitespace and that we always had this behavior, but I need to investigate further.

Wheeeeee!

By the way, this patch has been pylinted, tested, and committed to master.

Don't know if this is related or not but, as requested on the orca-list, I'm putting it here. Occasionally, when loading a new web page in ff 3.6, Orca doesn't seem to realize a new page is loaded. While Firefox is on the new page, Orca's caret navigation and structural navigation are still reading the previous page's content. It seems somewhat random, and I can't consistently reproduce it. When it does happen, even reloading the page with ctrl-r doesn't help. Also, when this occurs, tabbing will speak the correct links (because tab itself is a Firefox keystroke, I'm assuming) and yet even while tab is correctly reporting the links, caret and structural are still on the wrong page.

(In reply to comment #13)
> (In reply to comment #9)
> > In working on this bug, I discovered another issue which I am nearly positive
> > is not this bug: If you are navigating with Orca controlling the caret and/or
> > using structural navigation, and you press Tab, you will likely not land on the
> > focusable object which comes next as far as you are concerned. You will land on
> > the next focusable object as far as Firefox/Gecko is concerned. This is almost
> > certainly a(nother) Mozilla a11y regression which I will investigate next.
> > 
> 
> Please file on BMO and cc me :)

Done. https://bugzilla.mozilla.org/show_bug.cgi?id=546068

For BGO, because this turned out to be a totally separate issue with a different date (11th June), I've opened a new bug for tracking purposes: https://bugzilla.gnome.org/show_bug.cgi?id=609890

In terms of triaging items on this bug, I believe that leaves Attila's other issue, Jacob's, and what I saw in Yelp....

(In reply to comment #4)
> I change this bug with critical status, because impossible using with Firefox
> 3.6 webbrowser if this bug is present.
> 
> Attila

A 'critical' bug is defined as 'Crashes, causes loss of data, or is a severe memory leak'. That is not the case here. A 'major' bug is defined as 'Major loss of functionality - menu item broken, data output extremely incorrect, or otherwise difficult/useless to use.' I think we can all agree on the 'otherwise difficult/useless to use'. Therefore I'm lowering the severity of this bug to major.

(In reply to comment #20)

> 1. When I going for example the www.belin.hu webpage, jumps for example 3
> heading with h key, jumps one heading back with Shift+h key and pressing a
> Shift+tab key combination, Orca does'nt spokening the correct prewious link
> with heading.
> When I pressed three time the h key, Orca correct spokening the "A rendszer
> első elindítása" text. When I press Shift+tab key, the correct need jumping
> link is "A mostani BeLin verzió újdonságai", but Orca spokening another link.

I believe that would be this Mozilla regression:
https://bugzilla.mozilla.org/show_bug.cgi?id=546068

Which we are now tracking with the following bug:
https://bugzilla.gnome.org/show_bug.cgi?id=609890

The Alt+Tabbing issue sounds different. Still investigating....

(In reply to comment #20)
> Another interesting problem:
> For example I go to home with this webpage, and after this I switch another
> application window and switch back with Firefox with Alt+Tab key. The caret is
> changed. For example, when I pressing where am I command, I hear following
> link: "Tudnivaló néhány akadálymentes alkalmazás használatáról".

Actually, this also looks like the same issue. I was able to reproduce it on a Google search results page. I used 'h' to move from result to result. Then when I found a result whose description I wanted to read, I pressed Down Arrow a few times. Orca spoke the right information (i.e. the text below the heading/link) and moved the caret. But because the caret was moved by setCaretOffset() and because Gecko is no longer updating the position in that case, that heading/link retained focus; it should not have done so.

The rest of the behavior is correct/as expected: When you Alt+Tab out of Firefox and back into it, if there is a focused object, it should claim focus. And it is doing so. This is causing Orca to update your position in a way that seems incorrect. Once the Mozilla bug in question is fixed, this problem should go away.

Moving on to the next issues...

So the issue I was seeing in Yelp is that we are arrow to links but the links are not gaining focus like we'd expect. As a result, you cannot press Enter on them. That is filed in bgo as 524115.

The problem is a Mozilla bug, however: https://bugzilla.mozilla.org/show_bug.cgi?id=524115. We wound up discussing somewhat broader issues and then nothing wound up being done it seems. :-(

Anyhoo, nothing I can do there. We're blocked.

I believe that means Jacob's bug is the only issue listed here that is not either fixed or being handled in another bug. I will see if I can reproduce this issue tomorrow.

Jacob: I cannot reproduce the issue you're reporting. Is there a specific test case and/or can you get me a debug.out taken when this problem manifests itself? Thanks!

A test case would make things a lot easier, but there isn't one I've been able to find. It either happens or it doesn't. I'll do my best to get you a debug.out file though.

Created attachment 154031 [details]
This debug.out possible showing another Firefox 3.6 issue

Joanmarie, when I run for example the firefox www.belin.hu command and first try navigating with arrow keys, Orca is not talking. Only solving this problem if I press a Tab key.
Possible not focused the webpage or the caret with first time? If Firefox already running, this problem is not present when I opening another webpages.
When I not press a Tab key, but refreshing the webpage with F5 key, the problem is not present after the refresh operation is happened.
I try firefox www.belin.hu command with gnome-terminal.

Jose confirmed this problem with Orca Mailing list.
I hope this debug.out file help you to solving this problem.

Attila

Created attachment 156052 [details]
Another debug.out with show a possible interesting problem

Joanmarie, if you have a little time, please analyze this debug.out file.

I see an interesting problem with Rich Caloggero Navigation Bundle Firefox extension (1.4 version) on the headings list function.
The problem is the headings list extension if I using Firefox 3.6 version.
When I ask a headings list with a webpage with Ctrl+Alt+h key combination, choose any heading with the list and press enter key, the focus does'nt jump the choosed heading.
Interesting, but links list extension is OK, correct working.

I don't no this is an Orca related bug, or a bug with extension because this extension is not compatible now Firefox 3.6.
The extension download link is following:
http://www.mit.edu/~rjc/navigationBundle-1.4.xpi

Oldest Firefox versions before 3.6 version this extension is working absolute right.
The grab focus on objects when navigating of course is unchecked, but not help if I checking this check box.

Attila

Attila, what you're describing above sounds like it might instead be a different Firefox regression: https://bugzilla.gnome.org/show_bug.cgi?id=609890

Regardless, I'm afraid these days I need to focus on WebKitGtk accessibility and will not have time to look at your latest report for a while. Sorry! The good news, however, is that pinning this problem down seems like something you could do if you have the time and interest to do so. Here's what I would do if I had the time:

Go to the Mozilla ftp site where the nightly Firefox builds live. You can find them arranged by year, for instance:

* 2009's: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009
* 2010's: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010

Then pick a month from inside the directory for the year. If you think your problem with the extension might be this bug, you'd want the directory for September 2009:

* http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/09/

In each monthly directory, there are a lot of builds, but the name starts with the date, ends with the version, and has a number in between. Mozilla 1.9.2. is Firefox 3.6 and mozilla-central is (currently) Firefox 3.7. As for the number in between, as best as I can tell, it tends to correspond with the platform. '03' more often than not seems to be linux. So if you think the problem you're reporting is due to this bug, you'd want the 29 Sept build (i.e. the build right before the break) and the 30th Sept build (i.e. the build where the break is first seen), so follow the links for:

* 2009-09-29-03-mozilla-1.9.2
* 2009-09-30-03-mozilla-1.9.2

In each of those directories, you'll find the available builds. Download the bz2 file for your environment and extract it. The resulting folder will be named 'firefox' so I typically rename it to something that contains the date (e.g. 'firefox-2009-09-29' and 'firefox-2009-09-30').

What's cool is that you do not need to install anything. You can run each nightly version you download just by executing 'firefox' from within the directory you download.

Important: Be sure that you have quit Firefox completely -- including any open 'Download' window -- before trying one of the nightly firefox builds. If you don't, you will wind up opening a new browser window for the version of Firefox that is already running, rather than testing the nightly build you think you are testing.

Reminder: You can verify that you are running the build you think you are by looking in the Firefox 'about' dialog.

So putting all of this together Attila, you could:

1. Get the nightly builds from the 29th and 30th September

2. Try to reproduce your problem in each build

3. If you cannot reproduce the problem in the 29th build, but can in the 30th build, then it's part of this bug and you're done.

4. If you can reproduce the problem in the 29th build, see if it is bug 609890. As you will read in that bug, the problem was introduced in the 11th June build, so you'd want to look in this directory:

* http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/06/

There you won't find '1.9.2'. Back in June, 'mozilla-central' was still 1.9.2/Firefox 3.6, so you'd want these builds:

* 2009-06-10-03-mozilla-central
* 2009-06-11-03-mozilla-central

Again, if what you report is the bug I think it is, you won't be able to reproduce it using the 10th June build, but will be able to reproduce it on the 11th June build. In which case, please copy your comment/report to bug 609890.

5. If neither of the above are the case, it would be extremely helpful if you could use the above procedures to pin down exactly when things broke. I usually start by month, downloading the build from the 1st of each month until I find the month which is broken. Then I'll download the build from the middle of that month (e.g. the 15th), etc., etc. until I have the last build which is working and the first build which is not. Then I capture a debug.out from the working build and the non-working build and compare the two to see what might have changed.

If you are able and interested in doing the above, it would be extremely helpful. Otherwise, I will add your report to my to-do list, but can make no promises about when I'll be able to actually look at it. Again, my apologies. And thanks in advance for any triaging you can do on your problem!

Joanmarie, I wroted two possible useful comment with bug 609890.
I copyed my prewious comment report and wrong working debug.out file, and attach a good working demonstrate debug.out file with another Firefox 3.6 version, with headings list works right.

I found a Firefox 3.6 version with the headings list extension is working right. The about dialog data is following:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090601 Minefield/3.6a1pre

After following version not working right this extension:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090610 Minefield/3.6a1pre

Thank you your useful suggestions. I hope my informations is helpful you.

Attila

I'm pretty sure that for the issues reported in this bug for which there is a reliably reproduced test case, we already have another bug filed in GNOME's bugzilla which is tracking Mozilla bug filed in Mozilla's bugzilla. As a result, I don't believe there's any more work for the Orca team to do in response to this bug. Therefore, I'm closing it as FIXED for the grabFocusOnAncestor setting/workaround.

Should new/additional Mozilla issues be discovered, let's open new bugs for them.