GNOME Bugzilla – Bug 527959
Incorrect caret movement in Firefox 3 on certain Web pages
Last modified: 2009-03-10 00:04:50 UTC
Please describe the problem: I'm running Firefox 3 beta 5, Orca 2.22 (the actual version of Firefox is called Iceweasel due to the trademark issues between Debian and Mozilla). On at least one known Web page, the focus abruptly and incorrectly changes when the down arrow key is pressed while reading through the document. Steps to reproduce: 1. Visit http://lwn.net/Articles/275182/ 2. Move down to the article entitled "A Creative Example of the Value of Free drivers". 3. Using the down arrow key, attempt to read the text of the article. Actual results: As one moves down into the "Creative Example" article, the focus abruptly changes to the previous article on the same page, namely the OOXML article. Expected results: Orca should read the text of the "Creative Example" article, and in the correct order. Does this happen every time? yes Other information: I notice the following in the HTML markup: <p> headline <div> Author/date </div> Text of article... Note that the body of the article is not inside a paragraph, a div or any other block-level element. Of course, there will be block elements open, e.g., the BODY eleemnt and possibly more, but the interesting phenomenon here is that there is no immediately enclosing block-level element. Relevant exerpts from the Orca debug log are as follows. ^^^^^ PROCESS KEY RELEASE EVENT Down ^^^^^ KEYEVENT: type=0 hw_code=104 modifiers=16400 event_string=(Down) is_text=True time=1207964490.131139 orca.keyEcho: string to echo: Down orca.isModifierKey: returning: False ----------> QUEUEING KEYPRESS 'Down' (104) DEQUEUED KEYPRESS 'Down' (104) <---------- vvvvv PROCESS KEY PRESS EVENT Down vvvvv Object deemed to be useless: [paragraph | ] Object deemed to be useless: [paragraph | ] LOCUS OF FOCUS: app='Iceweasel' name='' role='paragraph' event=None ---------> QUEUEING EVENT focus: ---------> QUEUEING EVENT object:state-changed:focused SPEECH OUTPUT: 'A creative example of the value of free drivers' BRAILLE LINE: 'A creative example of the value of free drivers' VISIBLE: 'A creative example of the value of free ', cursor=1 ^^^^^ PROCESS KEY PRESS EVENT Down ^^^^^ DEQUEUED EVENT focus: <---------- vvvvv PROCESS OBJECT EVENT focus: vvvvv OBJECT EVENT: focus: detail=(0,0) app.name='Iceweasel' name='LWN.net Weekly Edition for April 3, 2008 [LWN.net]' role='document frame' state='enabled focusable focused horizontal opaque sensitive showing visible' relations='node child of' LOCUS OF FOCUS: app='Iceweasel' name='LWN.net Weekly Edition for April 3, 2008 [LWN.net]' role='document frame' event='focus:' ^^^^^ PROCESS OBJECT EVENT focus: ^^^^^ DEQUEUED EVENT object:state-changed:focused <---------- vvvvv PROCESS OBJECT EVENT object:state-changed:focused vvvvv OBJECT EVENT: object:state-changed:focused detail=(1,0) app.name='Iceweasel' name='LWN.net Weekly Edition for April 3, 2008 [LWN.net]' role='document frame' state='enabled focusable focused horizontal opaque sensitive showing visible' relations='node child of' Finding top-level object for source.name=LWN.net Weekly Edition for April 3, 2008 [LWN.net] --> obj.name=Welcome to LWN.net [LWN.net] --> obj.name= --> obj.name= --> obj.name=Welcome to LWN.net [LWN.net] - Iceweasel 3 Beta 5 ^^^^^ PROCESS OBJECT EVENT object:state-changed:focused ^^^^^ KEYEVENT: type=1 hw_code=104 modifiers=16400 event_string=(Down) is_text=True time=1207964490.298633 orca.isModifierKey: returning: False ----------> QUEUEING KEYRELEASE 'Down' (104) DEQUEUED KEYRELEASE 'Down' (104) <---------- vvvvv PROCESS KEY RELEASE EVENT Down vvvvv ^^^^^ PROCESS KEY RELEASE EVENT Down ^^^^^ KEYEVENT: type=0 hw_code=104 modifiers=16400 event_string=(Down) is_text=True time=1207964492.339147 orca.keyEcho: string to echo: Down orca.isModifierKey: returning: False ----------> QUEUEING KEYPRESS 'Down' (104) DEQUEUED KEYPRESS 'Down' (104) <---------- vvvvv PROCESS KEY PRESS EVENT Down vvvvv LOCUS OF FOCUS: app='Iceweasel' name='' role='section' event=None SPEECH OUTPUT: 'By Jonathan Corbet ' BRAILLE LINE: 'By Jonathan Corbet' VISIBLE: 'By Jonathan Corbet', cursor=1 ^^^^^ PROCESS KEY PRESS EVENT Down ^^^^^ KEYEVENT: type=1 hw_code=104 modifiers=16400 event_string=(Down) is_text=True time=1207964492.451117 orca.isModifierKey: returning: False ----------> QUEUEING KEYRELEASE 'Down' (104) DEQUEUED KEYRELEASE 'Down' (104) <---------- vvvvv PROCESS KEY RELEASE EVENT Down vvvvv ^^^^^ PROCESS KEY RELEASE EVENT Down ^^^^^ KEYEVENT: type=0 hw_code=104 modifiers=16400 event_string=(Down) is_text=True time=1207964493.507147 orca.keyEcho: string to echo: Down orca.isModifierKey: returning: False ----------> QUEUEING KEYPRESS 'Down' (104) DEQUEUED KEYPRESS 'Down' (104) <---------- vvvvv PROCESS KEY PRESS EVENT Down vvvvv SPEECH OUTPUT: 'March 30, 2008' BRAILLE LINE: 'March 30, 2008' VISIBLE: 'March 30, 2008', cursor=1 ^^^^^ PROCESS KEY PRESS EVENT Down ^^^^^ KEYEVENT: type=1 hw_code=104 modifiers=16400 event_string=(Down) is_text=True time=1207964493.602688 orca.isModifierKey: returning: False ----------> QUEUEING KEYRELEASE 'Down' (104) DEQUEUED KEYRELEASE 'Down' (104) <---------- vvvvv PROCESS KEY RELEASE EVENT Down vvvvv ^^^^^ PROCESS KEY RELEASE EVENT Down ^^^^^ KEYEVENT: type=0 hw_code=104 modifiers=16400 event_string=(Down) is_text=True time=1207964494.994926 orca.keyEcho: string to echo: Down orca.isModifierKey: returning: False ----------> QUEUEING KEYPRESS 'Down' (104) DEQUEUED KEYPRESS 'Down' (104) <---------- vvvvv PROCESS KEY PRESS EVENT Down vvvvv LOCUS OF FOCUS: app='Iceweasel' name='' role='paragraph' event=None KEYEVENT: type=1 hw_code=104 modifiers=16400 event_string=(Down) is_text=True time=1207964495.194109 orca.isModifierKey: returning: False ----------> QUEUEING KEYRELEASE 'Down' (104) SPEECH OUTPUT: 'OOXML gets ISO approval' BRAILLE LINE: 'OOXML gets ISO approval' VISIBLE: 'OOXML gets ISO approval', cursor=1 ^^^^^ PROCESS KEY PRESS EVENT Down ^^^^^ DEQUEUED KEYRELEASE 'Down' (104) <---------- vvvvv PROCESS KEY RELEASE EVENT Down vvvvv ^^^^^ PROCESS KEY RELEASE EVENT Down ^^^^^ KEYEVENT: type=0 hw_code=104 modifiers=16400 event_string=(Down) is_text=True time=1207964497.183291 orca.keyEcho: string to echo: Down orca.isModifierKey: returning: False ----------> QUEUEING KEYPRESS 'Down' (104) DEQUEUED KEYPRESS 'Down' (104) <---------- vvvvv PROCESS KEY PRESS EVENT Down vvvvv LOCUS OF FOCUS: app='Iceweasel' name='' role='section' event=None SPEECH OUTPUT: 'By Jake Edge ' KEYEVENT: type=1 hw_code=104 modifiers=16400 event_string=(Down) is_text=True time=1207964497.263099 orca.isModifierKey: returning: False ----------> QUEUEING KEYRELEASE 'Down' (104) BRAILLE LINE: 'By Jake Edge' VISIBLE: 'By Jake Edge', cursor=1
In the DOM inspector I see the following hierarchy: -> Paragraph -> Text Leaf: A creative example of the value of free drivers -> Section -> Text Leaf: By -> Text Leaf: Jonathan Corbet -> Whitespace -> Text Leaf: March 30, 2008 -> Text Leaf: Free operating systems differ from the proprietary... -> Link: shut down -> Text Leaf: shut down -> Text Leaf: an outside developer who had been working to ... -> Paragraph: -> Text Leaf: Creative is, of course, a long-time manufacturer In Accerciser I see: -> Paragraph: A creative example of the value of free drivers -> Section: By Jonathan Corbet\nMarch 30, 2008 -> Link: shut down -> Paragraph: Creative is, of course, a long-time manufacturer i.e. We seem to be missing the whole first paragraph. It turns out that the missing paragraph is part of the parent section whose text begins with "Once upon a time, there were no usable free web browsers for the Linux environment; the binary-only" In other words, the text that comes after the byline is exposed to us as part of the article which precedes this article. *sigh* Now what I have to work out how is we are to detect this condition and deal with it.
Created attachment 111083 [details] [review] revision 1 According to the accessible text interface, the byline section is on the same line as the beginning of the article. I suppose one could argue either way about that one. Nonetheless, here's the deal: 1. getLineContentsAtOffset() is examining the start of the article (what we're currently missing), seeing that there's this section (the multi-line byline) at the beginning of the line, and trying to include that section as part of the current line contents. The rest of getLineContentsAtOffset() is smart enough to know that the byline section is not on the same line as the first line of the article, and returns the byline as the line contents. 2. findNextLine() gets these supposedly new contents, says "hey, this is the same line I was on before, I must be stuck." and goes looking for the next object which, thanks to the way the page is marked up, is in the previous article. Hence the looping. :-( This patch adds some smarts to the beginning of the getLineContentsAtOffset() to deal with sections. It solves the reported problem for me. And it pylints nicely. I'll run the regression tests now. Please test. Thanks!
Created attachment 111084 [details] [review] revision 2 Silly stylistic correction. I need a nap. <grin> Anyhoo, please test this one. Thanks!
This passes the regression tests as well.
This one seems to work nicely.
Thanks Mike. Patch committed to both trunk and the gnome-2-22 branch. Moving to pending.