Steps to reproduce: 1. Open the test case 2. Launch Accerciser, locate one of the list items from the test case, and examine its text in the interface viewer Expected results: The text of that list item would be present. Actual results: The text of that list item is not present. This seems to have been introduced in the 2007080404 trunk build; 2007080308 and earlier are fine.

The checkins for the given period are: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-08-03+00%3A00&maxdate=2007-08-04+09%3A00&cvsroot=%2Fcvsroot A possible candidate could be fix to bug 348901.

Updating the summary ever so slightly. Turns out the text is not completely missing: It's simply not showing up in Accerciser -- presumably because other things are broken. From the iPython Console when "item 1" from the test case was selected: In [1]: text = acc.queryText() In [2]: text.getText(0,-1) Out[2]: 'tem 1' In [3]: text.characterCount Out[3]: 0 In other words, the first two characters have gone AWOL and the characterCount is bogus. But most of the text is there.

(In reply to comment #0) > Steps to reproduce: > > 1. Open the test case > 2. Launch Accerciser, locate one of the list items from the test case, and > examine its text in the interface viewer sorry, from what testcase?

Surkov, simply use any site that contains an unordered list. The Minefield start page, for example. Joanmarie was referring to a specific test case that was reported by an Orca user. Sorry about the confusion!

Marco, Joanie, thanks for nailing down the day and actual patch that caused the regression. That made it easier to figure out.

Comment on attachment 278878 [details] [diff] [review] There's an nsIContent* for a list bullet, it's just not text content. Change the fall-through test to success check for AppendTextTo(). okay, looks a bit hacky but r=me.

Yes it's hacky but remember after Firefox 3 dbaron says they're going to make list bullets less hacky in general -- it will have a real text node. So at that point our code will not need this special case. One hack deserves another :)

Unfortunately this hack causes a crash in Firefox when arrowing onto these--now again complete--list items that are not links. Just tested this on the Minefield Start Page: - If the patch is there, and I press L twice to go to the second list on the page (the first one with 5 links is OK), Firefox crashes on me. - If I remove this patch, the crash does not happen. Again, the items are now complete, but something is still wrong.

Comment on attachment 278878 [details] [diff] [review] There's an nsIContent* for a list bullet, it's just not text content. Change the fall-through test to success check for AppendTextTo(). Thanks Marco, I'll figure out why that is.

Marco, I go to http://www.mozilla.org/projects/minefield/ with JAWS and hit L twice with this patch, and get no crash.

Aaron, I believe I was at the Gran Paradiso Alpha 8 start page when it happened. It's the start page besides the Minefield start page that sometimes gets opened as well. It crashed in the list of changes in this alpha version.

(In reply to comment #12) > Marco, I go to http://www.mozilla.org/projects/minefield/ with JAWS and hit L > twice with this patch, and get no crash. Erm, I should read these when I'm more awake. :-) This bug was filed against Linux, so I was testing the patch with Orca. And there, on the Minefield start page, hitting L twice, results in a crash in Firefox, Orca continues running. JAWS is, indeed, fine on Windows. Sorry for the confusion!

I get a lockup -- not a crash (small but significant diference)

Nope, definitely a crash here. I get thrown back to the Terminal window I started this self-compiled Firefox from, with a "segmentation fault - Core dumped" message.

You're right, actually, as usual :)

This addresses the crash, although I get lots of beeps when I try Orca with Firefox. Possibly operator error? I believe this patch fixes this bug.

I just tried the patch and noticed a couple of things: 1. In your test case, the list item text seems to begin with an embedded object character. (e.g. Oranges), but the list item doesn't indicate any children that correspond to that embedded object. 2. Potentially bogus extents on list items. If I look at the first list using Accerciser's Interface viewer, I see that its size is 1664 x 132 (Maximized window 1680 pixels wide). If I then look at the first child of that list, I see that its size is 3248 x 22. This may be a side effect of my multi-head system, however I would think that the extents of a list item would not be permitted to exceed that of the parent list.

Can you figure rule when to use the check: frame->GetType() == nsAccessibilityAtoms::textFrame

Joanie, the list item bounds are a different bug. I don't know about the embedded object issue -- that might have been an issue before this bug as well. Probably another separate issue. Surkov, I didn't understand your last comment.

(In reply to comment #22) > Surkov, I didn't understand your last comment. > I'm just not sure why do you use that check.

Because we want to make sure we only use rendered text (e.g. use gfxSkipChars etc.) on text frames.

Comment on attachment 279690 [details] [diff] [review] More careful when to use text frame only methods >Index: accessible/src/base/nsAccessible.cpp >=================================================================== > nsresult rv = nsHyperTextAccessible::ContentToRenderedOffset(frame, content->TextLength(), &length); >- return NS_SUCCEEDED(rv) ? length : -1; >+ return NS_SUCCEEDED(rv) ? NS_STATIC_CAST(PRInt32, length) : -1; use static_cast<> what about GetBoundsForString()?

We still have open bugs on bounds for list bullets etc. and I don't want to try and fix that here.

> Joanie, the list item bounds are a different bug. Okie dokie. > I don't know about the embedded object issue -- > that might have been an issue before this bug as well. On that one I would beg to differ. ;-) Before we were getting numbers (e.g. 1. Oranges). And with the latest version of your patch it seems that we are once again getting the numbers. (Yea!) With your previous version of the patch, that was not the case. Bogus bounds are not good, but Orca seems to be reading list items correctly with your latest patch. Thanks!!!

By "latest patch" I mean the one from Comment #25.

Comment on attachment 279695 [details] [diff] [review] Surkov's comments r=me