GNOME Bugzilla – Bug 414738
Flat review in Firefox doesn't start at caret position
Last modified: 2007-06-08 15:06:30 UTC
When flat reviewing content in Firefox, the flat review context always starts at the top. I did some debugging of this, and we seem to be using two different Python Accessible instances for the same object from Firefox. This might be an Orca bug where it is not ref'ing accessibles appropriately. Here's a sample debug output from looking at this problem using flat review on the content at http://bugzilla.gnome.org/attachment.cgi?id=83911&action=view. The caret was positioned on the line "This sentence is italicized." What we see at the LOF line is what Orca thinks the locus of focus is along with the ID of the Python accessible object. The remainder is a dump of the flat review context. We see the "This sentence is italicized" line, but it has a different accessible ID. Bummer. LOF frame <orca.atspi.Accessible instance at 0x872b60c> LOF paragraph <orca.atspi.Accessible instance at 0x875cfcc> This sentence is italicized. 'tool tip' [tool tip <orca.atspi.Accessible instance at 0x8756f6c>] 'tool tip' [tool tip <orca.atspi.Accessible instance at 0x8756eec>] 'File' [menu <orca.atspi.Accessible instance at 0x8761a0c>] 'Edit' [menu <orca.atspi.Accessible instance at 0x8761a6c>] 'View' [menu <orca.atspi.Accessible instance at 0x8761b0c>] 'History' [menu <orca.atspi.Accessible instance at 0x8761b8c>] 'Bookmarks' [menu <orca.atspi.Accessible instance at 0x8761c0c>] 'Tools' [menu <orca.atspi.Accessible instance at 0x8761c8c>] 'Help' [menu <orca.atspi.Accessible instance at 0x8761cec>] 'tool bar' [tool bar <orca.atspi.Accessible instance at 0x87619ec>] 'Activity Indicator' [push button <orca.atspi.Accessible instance at 0x8761d8c>] 'Back' [push button <orca.atspi.Accessible instance at 0x8761f0c>] 'Forward' [push button <orca.atspi.Accessible instance at 0x8761f4c>] 'Reload' [push button <orca.atspi.Accessible instance at 0x8761f2c>] 'Stop' [push button <orca.atspi.Accessible instance at 0x8761fac>] 'Home' [push button <orca.atspi.Accessible instance at 0x8761fcc>] 'image' [image <orca.atspi.Accessible instance at 0x88b718c>] 'image' [image <orca.atspi.Accessible instance at 0x88b71ec>] 'file:///home/wwalker/orca/trunk/test/html/foo.html' [entry <orca.atspi.Accessible instance at 0x88b716c>] 'Page has no feeds' [push button <orca.atspi.Accessible instance at 0x88b728c>] 'Location' [push button <orca.atspi.Accessible instance at 0x88b72cc>] 'Go' [push button <orca.atspi.Accessible instance at 0x88b70ec>] 'Google' [entry <orca.atspi.Accessible instance at 0x88b740c>] 'Search' [push button <orca.atspi.Accessible instance at 0x88b736c>] 'Getting Started' [push button <orca.atspi.Accessible instance at 0x88b754c>] 'Latest BBC Headlines' [push button <orca.atspi.Accessible instance at 0x88b756c>] 'Test Formats' [link <orca.atspi.Accessible instance at 0x88b770c>] 'separator' [separator <orca.atspi.Accessible instance at 0x88b772c>] 'This sentence is italicized.' [paragraph <orca.atspi.Accessible instance at 0x88b776c>] 'Done' [label <orca.atspi.Accessible instance at 0x88b762c>] I'll post a dump that shows the CORBA IDs next. Seems as though I might need to restart Firefox, though, because it is in an unhappy state.
Created attachment 83936 [details] [review] Hack to get this working somewhat OK. Bizarre. I tested some more. We end up with two Python Accessible instances for the same CORBA object. This isn't ever supposed to be the case. Here's a silly hack to work around the problem. It seems to get the flat review position started at least somewhere near the right spot (though not reliably at the right spot). This is just for thought. Not for GNOME 2.18.
> It seems to get the flat review position started at least somewhere near > the right spot Yup! Nice!!
BTW, on the test case in your initial report, wrap the text in <p></p> and you land in the right place pretty reliably. Without the <p></p>, you don't.
Looking over this and some other bugs.... Observations: 1. When the text is wrapped in <p></p> and is thus a child of an object within the document frame rather than part of the document frame text, your patch works. 2. The text "skipped over" by flat review in Tim's test case bug #355525 is text that is part of the document frame rather than a child of an object within the document frame. So.... Is it possible that your patch is the fix for this bug, and that the case which it is not handling is merely another example of bug #355525?
(In reply to comment #1) > Created an attachment (id=83936) [edit] > Hack to get this working somewhat > > OK. Bizarre. I tested some more. We end up with two Python Accessible > instances for the same CORBA object. This isn't ever supposed to be the case. > Here's a silly hack to work around the problem. It seems to get the flat > review position started at least somewhere near the right spot (though not > reliably at the right spot). This is just for thought. Not for GNOME 2.18. > With some testing, I think the fix for bug 443012 has helped this bug and has eliminated the need for the gross hack in the patch I was so reluctant to check in. :-)
> Is it possible that your patch is the fix for this bug, and that the case which > it is not handling is merely another example of bug #355525? I did some investigating and I think you are correct Joanie! It looks as though if your caret happens to be in text that is skipped over by flat review, flat review will not start at the caret position. If the caret is in text that is not skipped over, however, flat review now starts at the right spot. So...I'm going to close this bug a duplicate of bug 443012, and the remaining work will happen in bug 355525. *** This bug has been marked as a duplicate of 443012 ***