Created attachment 83855 [details]
Another test case

Try the following:

1. Tab to the first link
2. Press Down Arrow (you'll move to the next row in the table)
3. Press Down/Up Arrow (you won't move:  You're stuck)

Delete this line:

    html, body {overflow-x: hidden;}

Try the above steps again.  (You won't be stuck)

Will, I'm not sure if this is just another instance of the bug you filled against Firefox or a different case.  If it's a different case and you want me to file a new bug, let me know.  (BTW, I believe this is what is responsible for Orca getting stuck on  http://www.net2world.se as reported by Krister)

Another interesting find w.r.t. the above test case.  If you leave in the line that says:

    html, body {overflow-x: hidden;}

And instead remove this line:

    .absolute {position: absolute;}

When you do step 3 above, you'll jump back to the "Results" heading.  Will I think/assume this is what you were seeing when you tried to reproduce Krister's problem and said:

>  It looks like you can get to one result, but then Orca jumps 
>  back somewhere else.

Still investigating....

The behavior I'm seeing with http://www.net2world.se/ is this:

1) Press Insert+F12 until Orca's caret navigation mode is enabled
2) Load http://www.net2world.se/ in Firefox
3) Tab to the text area that allows you to search - visually this is on the upper right of the window, next to the "Go" button
4) Type in "linux" and press Return
5) Tab your heart out until you get to the link in the first search result
6) Press the Down key.  You will end up on the beginning of the next line with the caret at the beginning of the word "Minneskortläsare"
7) Press the Down key again.  The caret doesn't move.  The braille display doesn't change and nothing is spoken.
8) Press the Right key.  The caret pops to the beginning of the "Produktträd" word at the top of the list on the left hand side of the page.

At step 7, the caret should move to the beginning of the next line.

Right.

I *think* the reason you are getting stuck is because of the presence of the following in the style sheet:

    html, body {overflow-x: hidden;}

When that's not in there, you don't get stuck.  Also when it's not in there, you don't jump to the top of the page.  If it is in there, but you're not setting the position, you get a spurious focus event that messes us up:

vvvvv PROCESS KEY PRESS EVENT Down vvvvv
LOCUS OF FOCUS: app='Minefield' name='' role='table cell'
                event=None
---------> QUEUEING EVENT focus:
---------> QUEUEING EVENT object:property-change:accessible-name
---------> QUEUEING EVENT object:property-change:accessible-name
BRAILLE LINE:  'Minneskortläsare Minneskortläsare Intern 3.5" Black (Apacer) Link 156 kr'
     VISIBLE:  'Minneskortläsare Minneskortläs', cursor=1
SPEECH OUTPUT: 'Minneskortläsare'
SPEECH OUTPUT: 'Minneskortläsare Intern 3.5" Black (Apacer) link'
SPEECH OUTPUT: '156 kr'

^^^^^ PROCESS KEY PRESS EVENT Down ^^^^^
DEQUEUED KEYRELEASE 'Down' (104) <----------

vvvvv PROCESS KEY RELEASE EVENT Down vvvvv

^^^^^ PROCESS KEY RELEASE EVENT Down ^^^^^
DEQUEUED EVENT focus: <----------

vvvvv PROCESS OBJECT EVENT focus: vvvvv
OBJECT EVENT: focus:                                   detail=(0,0)
    app.name='Minefield'          name=None role='unknown' state='ENABLED FOCUSABLE FOCUSED HORIZONTAL SENSITIVE SHOWING' relations=''
LOCUS OF FOCUS: app='Minefield' name='' role='unknown'
                event='focus:'
default.findCommonAncestor...
...default.findCommonAncestor
GENERATOR: _getDefaultSpeech
           obj             = 
           role            = unknown
           already_focused = False
           utterances:
SPEECH OUTPUT: ''
SPEECH OUTPUT: ''
^^^^^ PROCESS OBJECT EVENT focus: ^^^^^

At this point, we're in the document frame but no longer (not quite?) in the actual content, so findNextCaretInOrder() essentially starts over from the top.

This spurious event may be the result of Orca doing a grabFocus on the document frame.

In Firefox, you cannot always give focus to the thing that has the caret.  For example, static text is not allowed to take focus.  But, static text can have the caret.  In Firefox, for the caret to appear in an object, you need give focus to the object or its nearest ancestor that is FOCUSABLE.  You then position the caret offset in the object where you want the caret to appear.  It's kind of asymmetric and confusing.  :-(

This design choice often results in the document frame itself being the thing that needs to have focus, but then the caret context in Orca is [some child, some character offset in the child].  So...the thing to debug here is not necessarily what has focus, but what the caret context of Orca is.

Will, I tried as you suggest here and through follow-up via IM, in particular doing some before-and-after-grabFocus() examination.  I didn't see any changes.  Both before and after: obj is a table cell, objectForFocus is unknown, the former has (the same) text and the latter has no text.  AND this seemed to be consistent with and without the offending styles.

What is interesting in the above test case and on net2world.se is that when we get stuck, the width and height of the current character is 0.  if we change the patch from bug #414360 so that we are checking for *positive* width and height rather than *non-negative* width and height, we don't get stuck.  We still fly off to the beginning of the page, which is a bad thing, but that may be a different issue(??)

So, Will, when (if ever) is 0 a valid value for the width and/or height of a character?

> What is interesting in the above test case and on net2world.se is that when we
> get stuck, the width and height of the current character is 0.  if we change
> the patch from bug #414360 so that we are checking for *positive* width and
> height rather than *non-negative* width and height, we don't get stuck.  We
> still fly off to the beginning of the page, which is a bad thing, but that may
> be a different issue(??)
> 
> So, Will, when (if ever) is 0 a valid value for the width and/or height of a
> character?

I'm not sure of the answer.  My assumption would have been that something like \n would have 0 width and possibly 0 height.  But, Gecko seems to be giving us some non-zero values for \n, right?

> But, Gecko seems to be giving us some non-zero values for \n, right?

I think so.  In testing thus far (mostly from the tiny text issue)  \n *seems* to be a 1x1 char regardless of the size of the surrounding text.  I would want to do some more thorough testing before I placed any bets to that effect, however. :-)

position: absolute seems to cause significant problems with Firefox navigation (see bug # 414762).  Perhaps that has something to do with the weird jumping problem we're seeing in this bug??

According to Aaron, simply asking a Gecko component to grab focus can make it disappear and Gecko will create a whole brand new object for it.  This is really undesirable behavior in my opinion, but it appears as though the Gecko team won't fix this.  So...we need to:

1) Verify that this is indeed what is happening to us 
2) Figure out some other way to handle this

If this indeed is what is happening to us, the 'figuring out some other way' part isn't going to be simple, and we'll probably need to create some state in Orca to handle this in an asynchronous manner.  For example, we may need to set some state in setCaretPosition before calling grabFocus, and then check for this state in the onFocus method and then set the caret offset.  Yech.  Alternatively, we might just try setting the caret offset first and then calling grabFocus second.  My guess is that Gecko won't like this, but it might surprise me.

I started looking at the test cases for this again with Feisty and FF3 up-to-date from this week.  I cannot seem to reproduce the problems.  Joanie - do you still see the stickage?

Using the latest everything, I'm afraid I do.  :-( If I use the test case from comment #1 and Orca is controlling the caret, I get stuck at the beginning of the second table row.  I wonder what you and I are doing differently?

Created attachment 87571 [details] [review]
Possible patch to workaround the problem

With some debugging, it seems as though Gecko will issue focus events for an object of role unknown.  I'm guessing it is doing this in response to destroying an object after we call grabFocus on it.  So...this patch merely ignores focus events on those kinds of objects.  It seems to resolve the stickage for me.  Joanie, how about you? (Will predicts the answer is no and he'll be beating his head against the wall some more on this one.)

Actually..... It seems to!  Today, without the patch, I am seeing a slightly new behavior: Rather than getting stuck, focus would jump back to the heading at the top.  With the patch things are working as expected.  Nice!

Created attachment 88045 [details] [review]
Same patch, just diffed with newer Gecko.py sources

Go figure -- the patch no longer seems to work.  Sigh.

Created attachment 88095 [details] [review]
alternative version of Will's patch

Will it looks like you also need to ignore a caret-moved event.  That's what's jumping us to the top of the document frame.  Please give this patch a try and let me know if it solves things for you.  Thanks!

Woo woo!  Works much better.  Thanks for sleuthing this one out.  Please check it in!

Done.  Updating status to pending.

Closing as FIXED.  Thanks!