I've been hunting this for weeks and now think I have reliable steps to reproduce. Start JAWS, then run this series of steps: 1. Start Firefox with an about:blank document. 2. Open Tools/ChatZilla. 3. Type /sslserver irc.mozilla.org 6697 4. Once the "connect" screen settles, type /nickserv identify <yourpassword> 5. Type /join #accessibility 6. Once the channel window settles, press F6. Result: JAWS will load the full page, up to the "+o MarcoZ" (for my nick at least). 7. Press Shift+F6 to return to the textbox, then type: /server irc.gimp.org. 8. Once the screen settles, press F6 again. Result: JAWS will render everything up to the "user mode for MarcoZ is +i". 9. Shift+F6 again, then type: /join #orca 10. Once the screen settles, press F6. Result: JaWS will not render the full document. It will stop at the first table that contains the channel and topic. No output that comes in will ever be rendered. The a11y content for this document is frozen and will only repair itself if I type /leave, then rejoin the #orca channel.

Marco: should I be able to use accexplorer to test this myself? I only have a demo version of JAWS 7.10. If you think that'll "work", I can try that too.

Gijs, I don't know if it'll work without JAWS, since obviously I can't try it. See if you can get it to happen. If all goes well and you can reproduce it, the last of the documents, the #orca channel, should be incomplete. But again, I do not actually ask Firefox to render all the previous ones to JAWS. I skip the initial ChatZilla window and the connection window of irc.mozilla.org. I only ask for the content of the #accessibility channel, irc.gimp.org, and #orca.

OK, I'm not going to be able to look at this before my exam week is over (friday). Surkov, could you please try to find the time to look at this? It's a pretty severe bug. I'm guessing that Marco's settings mean that the entire #orca tab will go away once he /leaves, which means that apparently a11y is broken for the tab, until it is entirely replaced - Marco, could you confirm that? (check "/channel-pref deleteOnPart" for the #orca tab)

OK, so I'm not having any luck reproducing with accExplorer. Note that the channel #orca does not actually have a topic. However, after sending a message, and refreshing the view in accexplorer, I see the new message fine... I'll try jaws 7.10 in a bit, but I'm not sure if that's useful at all. :-(

So I've managed to reproduce this, though I got the #accessibility window to somehow not be accessible rather than the #orca one. Drove me nuts. Anyhow, I also have no idea how it happened... However, I can now see that there is nothing being presented to AccExplorer, either. Actually, that's not entirely true. When I drag the crosshair over the window, it seems to be focusing all kinds of things in the text table (ie, chat), but when I drop the crosshair there, it ends up just displaying the toplevel window hierarchy in accexplore, and, exploring it, it only finds the table with the topic and mode and so on (the same bits that JAWS *does* manage to speak). Aaron, Surkov, does that ring any bells? In the meantime I'll poke DOMI to see if I can see any internal problems as far as a11y stuff is concerned...

So, DOMI isn't seeing these accessibles either. The two divs that are used in your standard CZ output window both end up as sections in the accessible tree in DOMI, if it's working. For this view, however, only the section for the topic shows up (so the document node has only one child). I don't even know where to begin for this one. Marco, I don't suppose you know if this is a regression? I guess that's hard to test... :-(

Hi Gijs, First, I apologize for not saying it clearer that it can happen with any channel or "greeting" window of a server. These were just steps that regularly, though not 100%, reproduce the problem for me. Second, as for the regression, it has happened to me for as long as I've tried ChatZilla, so this is not a recent regression. It's just that ChatZilla only recently become so accessible that I started using it and started noticing this problem regularly.

OK, I can get this in a debug build on windows. However, I need some help doing the actual debugging, because the a11y implementation both scares and confuses me. Basically, what seems to happen, as I described in comment #6, at least as far as I can tell from DOMI, that one section (ie <div> node) in the document simply doesn't get an accessible. What we're trying to figure out is *why*. Can someone give some pointers as to how to start debugging this? I tried breaking in GetAccessibleFor, but it gets called way too often, and I can't figure out how to make VS tell me what nodes it gets called for (even just a localName would be helpful, really). Surkov, Aaron? Would be great if you could help out. Thanks!

Gijs. That's very ugly and hard-to-debug stuffs when something isn't created sometimes. I didn't try to reproduce it still. Probably one way you can follow is to add some debug code to interested methods, for example, you can add the check of needed tagname to stop debugger like if (tagname.EqualsLiteral("div")) { // break point }

So I did some testing and got these stack traces. I'm utterly lost on how they are so different - there are fewer stacks in the working case (which is weird) and none of the working stacks show up in the broken case, AFAICT, which is also weird.

OK. So I did some more digging. You can essentially ignore the stack traces, I believe. This is the code path I traced to the failure: http://mxr.mozilla.org/seamonkey/source/accessible/src/base/nsAccessible.cpp#714 nsAccessible::GetChildren http://mxr.mozilla.org/seamonkey/source/accessible/src/base/nsAccessible.cpp#730 nsAccessible::NextChild After finding the first div, it tries to use aAccessible->GetNextSibling(getter_AddRefs(nextChild)); to find the next accessible: http://mxr.mozilla.org/seamonkey/source/accessible/src/base/nsAccessible.cpp#593 nsAccessible::GetNextSibling 608 if (mNextSibling || !mParent) { 609 // If no parent, don't try to calculate a new sibling 610 // It either means we're at the root or shutting down the parent 611 if (mNextSibling != DEAD_END_ACCESSIBLE) this check fails, that is, mNextSibling == DEAD_END_ACCESSIBLE at this point. This is where debugging got me. Now, if I read the code correctly, mNextSibling is only going to be null if http://mxr.mozilla.org/seamonkey/source/accessible/src/base/nsAccessible.cpp#484 nsAccessible::SetNextSibling gets called with |null| as the parameter. This can only happen from http://mxr.mozilla.org/seamonkey/source/accessible/src/base/nsAccessible.cpp#742 nsAccessible::CacheChildren which in turn only does this if walker.GetNextSibling(); does not find a new accessible item. Still not sure why that happens, though. If anyone already spots a problem, let me know...

It sounds correct and wrong stack traces aren't related. Wrong stack trace is happen when nodes are appended or removed. But I don't see any incorrectness there.

Gijs, do you have strong steps to reproduce the bug? It's preferable by DOMi since it will show only cross-platform (Gecko's) problems.

(In reply to comment #16) > Gijs, do you have strong steps to reproduce the bug? It's preferable by DOMi > since it will show only cross-platform (Gecko's) problems. > No. I wish I did. Even for me it's just trying again and again until things break. I do use DOMI to check if things broke, but I haven't tried reproducing on anything but Windows. :-( Basically, what I do is: 1. Start Firefox. 2. Open ChatZilla. 3. Open DOM Inspector 4. Type /sslserver irc.mozilla.org 6697 5. Type /join #accessibility 6. Once the channel window settles, press F6. 7. In DOM Inspector, select the window (inspect content window, ircs://irc.mozilla.org:6697/accessibility) 8. In DOM Inspector, select the accessible tree from the dropdown 8a. Expand the document node. If it shows two sections, this view is fine. If it shows just one, it broke. 9. In ChatZilla, type /query firebot, and after the new view is done, hit F6 10. In DOM Inspector, select the window and expand the document, and check if the view broke. 11. In ChatZilla, type /server irc.gimp.org, and after the new view is done, hit F6. 12. Repeat step 10. 13. In ChatZilla, type /join #orca, and after the new view is done, hit F6. 14. Repeat step 10. 15. In ChatZilla, type /query YourOwnNickName, and after the new view is done, hit F6. 16. Repeat step 10. if by now I still haven't seen any broken views, I quit ChatZilla and start over.

So this patch for ChatZilla fixes the issue apparently 100%. However, it *should* in theory work without the fix, too. I'm guessing the culprit is that we unhide this stuff using JS in a setTimeout after load (!). However, we unhide one of the 7 or so headers the same way, and those always show up, even in "broken" views. Code for unhiding: Timeout: http://mxr.mozilla.org/seamonkey/source/extensions/irc/xul/content/output-window.js#159 unhiding: http://mxr.mozilla.org/seamonkey/source/extensions/irc/xul/content/output-window.js#97 CSS for hiding is just display: none at the very top of the html file: http://mxr.mozilla.org/seamonkey/source/extensions/irc/xul/content/output-window.html (keep in mind MXR will not show you source by default for html files, use ctrl+u :-) ) Does this help in figuring out what's going on?

This is still tentative, but it appears that bug 434002 also fixes this bug. I've just updated to latest XulRunner (I'm running ChatZilla on that), and can no longer reproduce. Gij's idea made me think of bug 434002 being a possible cause of this. I'll watch this for another day, and if I still can't repro any longer, will mark this one fixed.

(In reply to comment #19) > This is still tentative, but it appears that bug 434002 also fixes this bug. > I've just updated to latest XulRunner (I'm running ChatZilla on that), and can > no longer reproduce. Gij's idea made me think of bug 434002 being a possible > cause of this. That's quite possible I think because if we don't fire delayed 'show' events then we don't invalidate the accessible tree.

Fixed by checkin for bug 434002. I just went on and off IRC servers to test out the new irc.nl.mozilla.org server, and I didn't get a single failure in over 40 opening channel windows.

I had a lot of trouble finding this back, so adding the dep so I can keep track of it... Sorry for the spam! :-)