This assertion happens when running some of the e10s related tests with e10s enabled (passes when disabled). The tests that are fail, for example, are: accessible/tests/browser/browser_chaching_name.js accessible/tests/browser/browser_treeupdate_ariaowns.js ###!!! ASSERTION: adding child to unknown accessible: 'Error', file /Users/yzenevich/Github/gecko/accessible/ipc/DocAccessibleParent.cpp, line 39 #01: mozilla::a11y::PDocAccessibleParent::OnMessageReceived(IPC::Message const&) (PDocAccessibleParent.cpp:5434, in XUL) #02: mozilla::dom::PContentParent::OnMessageReceived(IPC::Message const&) (PContentParent.cpp:3731, in XUL) #03: mozilla::ipc::MessageChannel::DispatchAsyncMessage(IPC::Message const&) (MessageChannel.h:553, in XUL) #04: mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message const&) (MessageChannel.cpp:1593, in XUL) #05: mozilla::ipc::MessageChannel::OnMaybeDequeueOne() (MessageChannel.cpp:1560, in XUL) #06: nsRunnableMethodImpl<bool (mozilla::ipc::MessageChannel::*)(), false, true>::Run() (nsThreadUtils.h:707, in XUL) #07: mozilla::ipc::MessageChannel::DequeueTask::Run() (MessageChannel.h:498, in XUL) #08: nsThread::ProcessNextEvent(bool, bool*) (nsCOMPtr.h:403, in XUL) #09: NS_ProcessPendingEvents(nsIThread*, unsigned int) (nsThreadUtils.cpp:232, in XUL) #10: nsBaseAppShell::NativeEventCallback() (nsBaseAppShell.cpp:98, in XUL) #11: nsAppShell::ProcessGeckoEvents(void*) (nsAppShell.mm:388, in XUL) #12: __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ (in CoreFoundation) + 17 #13: __CFRunLoopDoSources0 (in CoreFoundation) + 556 #14: __CFRunLoopRun (in CoreFoundation) + 927 #15: CFRunLoopRunSpecific (in CoreFoundation) + 296 #16: RunCurrentEventLoopInMode (in HIToolbox) + 235 #17: ReceiveNextEventCommon (in HIToolbox) + 432 #18: _BlockUntilNextEventMatchingListInModeWithFilter (in HIToolbox) + 71 #19: _DPSNextEvent (in AppKit) + 1067 #20: -[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:] (in AppKit) + 454 #21: -[GeckoNSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] (nsAppShell.mm:121, in XUL) #22: -[NSApplication run] (in AppKit) + 682 #23: nsAppShell::Run() (nsCOMPtr.h:536, in XUL) #24: nsAppStartup::Run() (nsAppStartup.cpp:284, in XUL) #25: XREMain::XRE_mainRun() (nsAppRunner.cpp:4368, in XUL) #26: XREMain::XRE_main(int, char**, nsXREAppData const*) (nsAppRunner.cpp:4472, in XUL) #27: XRE_main (nsAppRunner.cpp:4580, in XUL) #28: main (nsBrowserApp.cpp:220, in firefox) Complete log here: http://paste2.org/fYAZtBIY

Ok, so as expected the problem is that the child process isn't firing events in the correct order / isn't coalescing them properly. The first time Accessible::HandleAccEvent() is called in the child process its for an accessible that is a grand child of a document. That's clearly bogus since there was no show events for the direct children of the document, which must have just been created. I believe the correct events for the children get queued first, but somehow the event tree stuff screws that up. I can't easily tell where exactly the problem is there because that code is really under documented. It might be useful to try reducing the test to see what part of it causes a problem.

(In reply to Trevor Saunders (:tbsaunde) from comment #1) > It might be useful to try reducing the test to see what part of it causes a > problem. that'd be definitely helpful, or description of what is inserted/removed that causes the problem, or/and A11YLOG logs.

Another small issue is that in EventTree, there are hide events for grandchild text nodes at the document level. This is because MoveChild() calls Hidden() first for the text node before moving it, and the text node is originally at the document level: https://dxr.mozilla.org/mozilla-central/source/accessible/generic/Accessible.cpp#2142 The parent process doesn't know about the text node being at the document level though, since this text node wasn't shown beforehand, so it tries to remove an invalid node. This might get fixed in bug 1289223, but calling Shown() on the text node before Hidden() doesn't seem to solve it.

hey Micheal, the current target for e10s+a11y rollout is 51. Is this somet5hing we need to look at before that happens?

Yes, the bug is blocking some e10s a11y tests from working.

Alex with Michael heading back to school are you picking this up?

it looks a dupe of bug 1294853 per comment #3. this bug may be kept open to enable the tests when the issue is resolved.

Yura did bug 1270916 fix this?

yes. closing.