Thanks for filing this Hermann!  You know, looking at the code (I wasn't the one who implemented large object navigation), I'm wondering if we can bend O/Shift+O to your will via some settings.  I'm game if you are. :-)

One setting is already in place but not currently exposed (via the preferences dialog) to the user, namely the length of the text block.  Currently that length is 75 (i.e. pretty large).  As I recall, in JAWS it defaults to 25 (??).  You can tweak this value by placing the following in your orca-customizations.py:

import orca.Gecko
orca.Gecko.largeObjectTextLength = 25

I don't think that change alone is going to quite do it for you, but I'd ask you to give it a try and give some feedback, along the lines of "I set the length to x and went to this site, and landed on this thing which I should not have landed on because it's a foo."  Then I'll take a look and see how to eliminate landing on foos.  :-) If we can get the behavior your looking for in this fashion, then we can look at exposing settings.  If we can't then I'll go back to the proverbial drawing board.

Just inserted the lines in my orca-customizations.py, and a few tests 
indicate that it seems to serve its purpose.
However: When assinged the text length to 25, Orca shouldn't read the 
whole paragraph belonging to that text block.
For example go to the list archive, open any mail and press "o". The 
first object is the headline of that mail, which is, BTW., a heading too. 
But the second hit is the text of the mail. The whole mail is spoken 
instead of the first line.
To complicate the issue a little bit more: This does not happen in any 
case. For example: On any article of the famous Frankfurter Rundschau it 
does not happen; Orca finds the beginning of the article and reads the 
first line. I suspect that this has to do with the HTML code on the 
different pages.

Marking this as a depends of the Structural Navigation refactor.  The changes there limit the number of places in which we define how an object gets presented.  Once those changes are completed and in place, it will be very easy to add another setting (i.e. one customizable via orca-customizations.py similar to largeObjectTextLength) in which we can specify if the first line or the entire object is read.

Okay, the Structural Navigation refactor has been checked into trunk.  Back to this RFE.

Hermann, I saw your note on the list last week about large object navigation seeming to land on things it wasn't before.  That could be the result of a change/fix we made a couple of weeks ago:  Mike Pedersen reported that we were skipping over things we shouldn't be.  Perhaps we were skipping over things you wanted us to be skipping over, but that we shouldn't have been skipping over in terms of their content. <shrugs>

Therefore, I'm thinking it would be worth revisiting your original request.  It would be helpful if you could give me a couple of sample pages where the content is relatively static.  And for each of those pages, imagine that you had the command you're requesting, started from the top of the page, and kept using it until you reached the bottom of the page and wrapped back to the top.  Then please indicate where exactly Orca should stop for each press of the hypothetical command and what it should say upon landing there.

Thanks!

I think we can this make easy by taking Jaws' behavior as example: You can adjust the length of the text block you want to be read,  standard is 25. When pressing "n" and "shift+n" (Jaws' standard commands), you land on  any non-link and non-form that matches this condition. I think you got a machine with Jaws, so you can check out its behavior.  You will find, that you quicly land on the first line of a greater bunch  of text on a website, for example in newspapers (provided they don't  mark the beginning of articles by headins, which is not always the  case). Another nice effect of this is the fact that you can quicly skip  navigation areas. 

In case you dont have access to windows/jaws, maybe this sheds some light:

I took this bugzilla page as an example

from the top, we have:
<link "bugzilla.gnome.org">
<text "Bugzilla">
<link "new bug">
<text ".">
<link "browse">
<text ".">
....
<link "help">
<text "Logged In j.orcauser@gmail.com | ">
<link "log out">
<heading "Bug 520530 – Orca should search for textblocks >=N chars in order to skip large amounts of links in FF3.">
<link "View Bug Activity">
...
<text "Product:  ">
<link "orca   ">
<text "Component:  general   
Version:  unspecified   
Status:  NEW   
Priority:  Normal   
Severity:  enhancement   
Target:  2.24.0 ">


<text "Opened by">
<link "Hermann">
<text "(reporter, ">
<link "points: 5) ">
<text "2008-03-05 15:48 UTC ">
<link "[reply]">
<text "On many webpages, there are navigation areas that contain a lot of
links, forms etc., that should be skipped quickly in order to find text "... >

<text "Comment">
<link "#1">
<text "rom">
<link "Joanmarie Diggs">
<text "(orca developer,">
<link "points: 20)">
<text "2008-03-05 19:45 UTC">
<link "[reply] ">
<text "Thanks for filing this Hermann!  You know, looking at the code (I wasn't the
one who implemented large object navigation), I'm wondering if we can bend"... >

When i am at the first object of the page, (the link), pressing "n" takes me to the logged in text.
i.e, we are simply searching for non-activatable text, of minimal length 25
pressing n, we land on the heading, (yes, it is non-active text so reasonable to land on it).
pressing Once more, we land on 
"Component:", again, this text block is longer than 25
"n" once more:
we land on the first line of the bug report, and that line is spoken.
"n" once more:
we land on the first text line of the comment, and that line is spoken.


Hope this helps.

Thanks

Sorry, something that my previous comment didnt make explicit:
if we have blocks of 
<p> .. </p>
we only read the first line of the first one, and we only consider a next hit to be valid if it lies after some active object.

Thanks Jon.  I actually do have a Windows installation and a JAWS license. And I've just set up a virtual box so that I can at once compare Windows/JAWS with Linux/Orca on a single machine. <geeky grin>  Anyhoo, here's my analysis and some questions:

----------------
From the top of the Orca wiki, using JAWS 9.0 and IE7. Pressing N repeatedly.  Here's where I landed:

1. "live.gnome.org".  This heading does not have 25 characters.  What follow is an entry with the text "Search" in it.  The two combined brings us to 20 characters.  After that are a couple of greyed out buttons. I'm not sure if they are included in the character count. After that is more links.

2. "Contents". Again, this string does not contain 25 characters and is immediately followed by an ordered list where each list item is a link.

3. "About Orca". This heading doesn't have 25 characters in it, but there's not another link for more than 25 characters, so I'm good with that being treated as a block.

4. "Orca helps provide access to".  The JAWS algorithm seems to be this: First find a link, then look past that link, if you have 25 or more non-linked characters, stop on the first character after the link. 

5. "And toolkits that support the AT-SPI (e.g., the GNOME desktop). The development of Orca has been led by the".  It's that "find a link and look beyond it algorithm". All it did in this instance is skip over the link "Applications".  Is the text after that, and in the same paragraph, a valid block? (Technically, yeah, it's 25 characters of non-linked text.  The question is, is that the desired functionality?)

[Skipping a few presses because we don't need a full play-by-play. Then I landed on:]

6. "your input is greatly appreciated!" (this is just before the heading "Does Orca work with Skype?").  To me, the next block of non-linked text is the heading "Does Orca work with Skype?" because it's 25 characters of non-linked text -- and the start of a new section/block because it's a heading.  But if I press 'n' again:

7. Audio Guides.  In other words, a couple of things have happened: For one thing we skipped over a 25-character long block of non-linked text.  For another, we landed on a block of text that's not 25 characters long: "Audio Guides". If Audio Guides were followed by more non-linked text, landing here would make a certain amount of sense in light of the apparent algorithm being used (find a link first, then find some text).  However, Audio Guides is immediately followed by a link so we don't have 25 characters of non-linked text.

So that's what I'm seeing. Here are my questions:

1. Is this the behavior you would like to see in Orca? Or can we improve upon it? If we can, I need to know how. Mind you I have my ideas, but what's important are yours.  We're building this skip-link feature from scratch and can do whatever we want to make it as useful as it can possibly be.  On the other hand:

2. If you want this exact behavior, namely something that first finds a link and then leap frogs over it assuming it finds 25 characters on the other side, I can certainly do my best to implement that. But in order to do so, I need to know exactly what I should base the character count on.  Did I land on "Audio Guides" because that text plus "Heading Level 1" from the virtual buffer is at least 25 characters long? Or is something else being used to make the determination that it should stop on that heading?  Why did we land on "Contents"?  That doesn't have any "Heading Level x" in the virtual buffer and it's immediately followed by a list of links.  Does the fact that the links are in an ordered list mean that they should not be included as "linked text"? Or is something else going on?

Yes, I could make a bunch of variations to the Orca wiki content to try to sort out the patterns. But to be perfectly honest, I've got plenty of other bugs on my plate. You guys are the users. If you spec out exactly what you want and need, I will do my darnedest to implement it. If what you want me to do is try to figure out exactly why JAWS is doing what it does and replicate that, I will do that as well -- but only after I get caught up on all of my other bugs. Alternatively, Jon, if you would like to give this a shot, I'd be happy to reassign it to you.

Lemme know.

Because I've originally brought this up, I think I should add some  explanation: I use Jaws for years and worked with that feature without thinking about it  too closely: "It" works, and because "it" works, I suggested adding this to  Orca's features. I'm neither a programer, nor am I a scripter, so cannot  comment much on the algorithm. However I've observed too, that Jaws sometimes seems to act strange in  this feature, since I've tested several screen readers and webtools that  also use this feature. And as you might expect, they use different  algorithms. They do an exact search of text = or >=x, where "x" is the defined  text length.  Of course they provide different results. Joanie, I don't want to waste your time by demanding you to test all the  different screen readers and webtools, so I suggest to go on like this: What about creating a patch that do the simplest, a search for a  nonlink string >=x, without care of environment variables. After a testing period, we rediscuss this, depending on the experience we  made. If this serves our needs, OK, let's check it into Orca. If we think it  should be redesigned, we can go on discussing waht has to be done and if  it's possible. I hope this suggestion brings us closer to a quick and pragmatical  solution,  since, in my view, it does not make much sense to speculate what the FS  folks might have done. 

(In reply to comment #8)

Using Jaws 8, and ie7, i get the same results as you do, ie6 is slightly diffrent though, their detection has changed for the two versions of browser, i assume that a lot was re-written since ie7 was virtually unworkable when it first came out.
anyway ...

> From the top of the Orca wiki, using JAWS 9.0 and IE7. Pressing N repeatedly. 
> Here's where I landed:
> 1. "live.gnome.org".  This heading does not have 25 characters.  What follow is
> an entry with the text "Search" in it.  The two combined brings us to 20
> characters.  After that are a couple of greyed out buttons. 

If they are, then i dont think they should be.

> I'm not sure if
> they are included in the character count. After that is more links.
> 2. "Contents". Again, this string does not contain 25 characters and is
> immediately followed by an ordered list where each list item is a link.
> 3. "About Orca". This heading doesn't have 25 characters in it, but there's not
> another link for more than 25 characters, so I'm good with that being treated
> as a block.
> 4. "Orca helps provide access to".  The JAWS algorithm seems to be this: First
> find a link, then look past that link, if you have 25 or more non-linked
> characters, stop on the first character after the link. 
> 5. "And toolkits that support the AT-SPI (e.g., the GNOME desktop). The
> development of Orca has been led by the".  It's that "find a link and look
> beyond it algorithm". All it did in this instance is skip over the link
> "Applications".  Is the text after that, and in the same paragraph, a valid
> block? (Technically, yeah, it's 25 characters of non-linked text.  The question
> is, is that the desired functionality?)

Yes please, this way we can read through the text quite quickly without getting annoyed by "link" ever so often.

> [Skipping a few presses because we don't need a full play-by-play. Then I
> landed on:]
> 6. "your input is greatly appreciated!" (this is just before the heading "Does
> Orca work with Skype?").  To me, the next block of non-linked text is the
> heading "Does Orca work with Skype?" because it's 25 characters of non-linked
> text -- and the start of a new section/block because it's a heading. 

agree with you on that one, jaws doesnt seem to do it quite right, there.

> But if I press 'n' again:
> 7. Audio Guides.  In other words, a couple of things have happened: For one
> thing we skipped over a 25-character long block of non-linked text.  For
> another, we landed on a block of text that's not 25 characters long: "Audio
> Guides". If Audio Guides were followed by more non-linked text, landing here
> would make a certain amount of sense in light of the apparent algorithm being
> used (find a link first, then find some text).  However, Audio Guides is
> immediately followed by a link so we don't have 25 characters of non-linked
> text.

yep, dont know what is going on there, nor is it what i would have liked to have seen.

> So that's what I'm seeing. Here are my questions:
> 1. Is this the behavior you would like to see in Orca? Or can we improve upon
> it? 

we can definately improve on that

> If we can, I need to know how. Mind you I have my ideas, 

it would be enlightening to hear them

> but what's
> important are yours.  We're building this skip-link feature from scratch and
> can do whatever we want to make it as useful as it can possibly be.

please see next comment.


> On the other hand:
> 2. If you want this exact behavior, namely something that first finds a link
> and then leap frogs over it assuming it finds 25 characters on the other side,
> I can certainly do my best to implement that. But in order to do so, I need to
> know exactly what I should base the character count on.  Did I land on "Audio
> Guides" because that text plus "Heading Level 1" from the virtual buffer is at
> least 25 characters long? Or is something else being used to make the
> determination that it should stop on that heading?

I think character count should be purely based on what is visible on screen, and not information that was added such as "heading level x"

> Why did we land on
> "Contents"?  That doesn't have any "Heading Level x" in the virtual buffer and
> it's immediately followed by a list of links.  Does the fact that the links are
> in an ordered list mean that they should not be included as "linked text"? Or
> is something else going on?

I think we landed on "contents" because it considered "list of 8 items" (the text underneath) to be actual text, which it isnt, and therefore we shouldnt be landing on it.

> Yes, I could make a bunch of variations to the Orca wiki content to try to sort
> out the patterns. But to be perfectly honest, I've got plenty of other bugs on
> my plate. 

yeah, was sorry to see all those thunderbird bugs.

> You guys are the users. If you spec out exactly what you want and
> need, I will do my darnedest to implement it. If what you want me to do is try
> to figure out exactly why JAWS is doing what it does and replicate that, I will
> do that as well -- but only after I get caught up on all of my other bugs.

no, no need to spend time trying to figure out the reasons behind the jaws matching algorithm, i'm sure we can be more consistent ourselves.

> Alternatively, Jon, if you would like to give this a shot, I'd be happy to
> reassign it to you.
> Lemme know.

:) scared but yes, could have a go,
But unfortunately im being taken out of the country for a birthday treat, leaving 15th evening, coming back on the 25th.

But i'll have a go when i get back.

--start--
Spec for large object navigation:

A valid hit for large object navigation is one of these:

1. if a line or part of a paragraph contains text equal or greater than the required length then this text is a hit.
2. Next/previous hit is either:
2.1. find link in given direction, which is followed by text of at least required length, give focus to the start of this text, and read the text on that line. (Currently we read the whole paragraph.)
2.2. if a heading contains text of required length then it is a hit. (we already do this)
--end--

the reason why people may think it is quite diffrent from the jaws (dont know about window-eyes) version of this, is that we do not separate links that are on the same line as text, therefore currently when we arrive on some text, we might un-intentially read a link that happens to be on the same line.

Thank you Hermann for your suggestion in comment #5, i totally agree with you.

So Joanie, dont worry about this one for now unless you see it as a distraction from all the fun. :)

Thanks guys.

Hermann, that sounds quite reasonable.

Jon, for the sake of clarity, I was looking at this as a new/separate feature from large object navigation. Large object/Chunk navigation will stay as it is; this will be a skip-links-ish feature. I'm not sure if that's also what you were thinking.  Anyhoo, I may give this an initial go while you're away, so for now I'll leave it assigned to me. But let's talk further upon your return, okay?  And happy birthday!

In answer to Jon:
I changed the length of LargeObject to 25, and I get sometimes read a line 
that indeed contains 25 characters, but on the other hand I often get read 
the whole paragraph that follows this line. So here we are facing a 
consistancy problem too.
If somebody here is a testing junky, he/she might test Window Eyes and 
Audiodata's Webformator to figure out how the "search for text block" 
feature is working there. You will find different behaviors. For 
Webformator check:
http://www.webformator.com/
There's a flag for English speaking countries, so click on this for an 
English version.
And BTW: Can someone explain me how to reply to comments including quotes?
Can't find such a button.

Hi Hermann, the reply button that inserts the comment as a quote is just after the comment date.

Yes i know what you mean about sometimes getting a whole paragraph and sometimes only a line.
In fact i belive we are reading the whole paragraph always, 
but sometimes it happens to be that the paragraph is one line long. or its a heading.

(In reply to comment #12)
> Thanks guys.
> Hermann, that sounds quite reasonable.
> Jon, for the sake of clarity, I was looking at this as a new/separate feature
> from large object navigation. Large object/Chunk navigation will stay as it is;

I didnt want to have too many variations on this, thats why i was thinking maybe the largeObjectNavigation could be changed, otherwise people might get confused on what to use when.

> this will be a skip-links-ish feature.

I thought that was the intention of largeObjectNavigation?

> I'm not sure if that's also what you
> were thinking.  Anyhoo, I may give this an initial go while you're away, so for
> now I'll leave it assigned to me. But let's talk further upon your return,
> okay?

sounds good

> And happy birthday!

Thank you :)

When my brother found out, he wondered how i could cope being away from orca for that long :)
btw, i dont seem to have permissions to change the title on bug 523693 to testing required, could you please change that?

Jon, as is sadly often the case, new bugs came up (e.g. gmail issues) and I haven't had the opportunity to tackle this one yet. :-( As you had indicated an interest in this RFE, I'm wondering if you'd still be interested. :-)

Hi Joanie,

I know 2.24.0 gui deadline is 18 Aug, how much more time to we get before code freeze?
The firefox code is something i havent looked at yet, so cant promis how soon i'll get this done.
If this is acceptable, do reassign it to me, and I'll get to it.

Thank you

> I know 2.24.0 gui deadline is 18 Aug, how much more time to we get before code
> freeze?

According to this: http://live.gnome.org/TwoPointTwentythree
String freeze is 1 Sept; Code freeze is 15 Sept through 22 Sept (i.e. it could get in for 2.24.1).

> The firefox code is something i havent looked at yet, 

But you *have* looked at the structural navigation code. :-)  This is largely a structural navigation issue.

> If this is acceptable, do reassign it to me, and I'll get to it.

Cool beans!  Thanks and done!

Marking this for 2.26.0.  Jon - do you think you will be able to get to it?

Sorry, might still revert it back to future, there are more intresting bugs to work on at the moment :)

Planning spam. Sorry!

Given everything else on the to-do list, non-critical Gecko-related bugs are
going to have to wait until after 3.0, unless someone volunteers to do them.

(Ale, even though this is an Andalucia blocker, I really think this is low priority compared to the other blockers. But if you disagree, please set whiteboard to 3.0! and assign it to yourself. Thanks!)