Apache OpenOffice (AOO) Bugzilla – Issue 80994
SdWindow returns empty accessible
Last modified: 2010-01-08 09:16:14 UTC
When a presentation window gets constructed, the UNO <-> ATK bridge queries for the children of the top-level frame, but gets an empty XAccessible reference from SdWindow. (dbx) where current thread: t@1 =>[1] sd::ViewShell::CreateAccessibleDocumentView(this = 0x88c0ad8, _ARG3 = 0x88ae200), line 1300 in "viewshel.cxx" [2] sd::Window::CreateAccessible(this = 0x88ae200), line 1157 in "sdwindow.cxx" [3] Window::GetAccessible(this = 0x88ae200, bCreate = '\001'), line 8577 in "window.cxx" [4] VCLXAccessibleComponent::getAccessibleChild(this = 0xc8831f4c, i = 0), line 609 in "vclxaccessiblecomponent.cxx" [5] AtkListener::updateChildList(this = 0xc61fa9a4, pContext = 0xc8831f84), line 132 in "atklistener.cxx" [6] AtkListener::handleChildAdded(this = 0xc61fa9a4, rxParent = CLASS, rxAccessible = CLASS), line 149 in "atklistener.cxx" [7] AtkListener::notifyEvent(this = 0xc61fa9a4, aEvent = STRUCT), line 279 in "atklistener.cxx" [8] comphelper::AccessibleEventNotifier::addEvent(0x4e, 0x8045c90), at 0xcfb37230 [9] comphelper::OAccessibleContextHelper::NotifyAccessibleEvent(0xc8831f4c, 0x7, 0x8045dc0, 0x8045db4), at 0xcfb218dd [10] VCLXAccessibleComponent::ProcessWindowChildEvent(this = 0xc8831f4c, rVclWindowEvent = CLASS), line 243 in "vclxaccessiblecomponent.cxx" [11] VCLXAccessibleComponent::WindowChildEventListener(this = 0xc8831f4c, pEvent = 0x8045f04), line 211 in "vclxaccessiblecomponent.cxx" [12] VCLXAccessibleComponent::LinkStubWindowChildEventListener(pThis = 0xc8831f4c, pCaller = 0x8045f04), line 198 in "vclxaccessiblecomponent.cxx" [13] VclEventListeners::Call(this = ???, pEvent = ???) (optimized), at 0xd04f7368 (line ~52) in "vclevent.cxx" [14] Window::CallEventListeners(this = 0x88af080, nEvent = 1003U, pData = 0x88af080), line 5358 in "window.cxx" [15] Window::ImplCallEventListeners(this = 0x88af080, nEvent = 1003U, pData = 0x88af080), line 5327 in "window.cxx" [16] Window::ImplSetReallyVisible(this = 0x88af080), line 1611 in "window.cxx" [17] Window::Show(this = 0x88af080, bVisible = '\001', nFlags = 0), line 6500 in "window.cxx" [18] sd::ViewShell::construct(this = 0x88c0ad8), line 288 in "viewshel.cxx" [19] sd::ViewShell::ViewShell(this = 0x88c0ad8, _ARG2 = 0x877daa8, pParentWindow = 0x88acfd8, rViewShellBase = CLASS, bAllowCenter = true), line 207 in "viewshel.cxx" [20] sd::slidesorter::SlideSorterViewShell::SlideSorterViewShell(this = ???, pFrame = ???, rViewShellBase = CLASS, pParentWindow = ???, pFrameViewArgument = ???) (optimized), at 0xc55e9fcd (line ~119) in "SlideSorterViewShell.cxx" [21] sd::framework::BasicViewFactory::CreateViewShell(this = ???, rxViewId = CLASS, rFrame = CLASS, rWindow = CLASS, pFrameView = ???) (optimized), at 0xc56ca6fb (line ~479) in "BasicViewFactory.cxx" [22] sd::framework::BasicViewFactory::CreateView(this = ???, rxViewId = CLASS, rFrame = CLASS, rWindow = CLASS, rxPane = CLASS, pFrameView = ???) (optimized), at 0xc56c9f2a (line ~376) in "BasicViewFactory.cxx" [23] sd::framework::BasicViewFactory::createView(this = ???, rxViewId = CLASS, rxController = CLASS) (optimized), at 0xc56c8ecf (line ~251) in "BasicViewFactory.cxx" [24] sd::framework::ViewController::CreateView(this = ???, rxViewId = CLASS) (optimized), at 0xc56af022 (line ~390) in "ViewController.cxx" [25] sd::framework::ViewController::updateEnd(this = ???, rxRequestedConfiguration = CLASS, rxCurrentConfiguration = CLASS, rResourcesToActivate = CLASS) (optimized), at 0xc56ae96e (line ~267) in "ViewController.cxx" [26] sd::framework::ConfigurationUpdater::UpdateEnd(this = ???, rResources = CLASS) (optimized), at 0xc56be261 (line ~359) in "ConfigurationUpdater.cxx" [27] sd::framework::ConfigurationUpdater::UpdateCore(this = ???, rClassifier = CLASS) (optimized), at 0xc56bdc58 (line ~291) in "ConfigurationUpdater.cxx" [28] sd::framework::ConfigurationUpdater::UpdateConfiguration(this = ???) (optimized), at 0xc56bd7d4 (line ~215) in "ConfigurationUpdater.cxx" [29] sd::framework::ConfigurationUpdater::RequestUpdate(this = ???, rxRequestedConfiguration = CLASS) (optimized), at 0xc56bd5f3 (line ~139) in "ConfigurationUpdater.cxx" [30] sd::framework::ChangeRequestQueueProcessor::ProcessOneEvent(this = ???, pUnused = ???) (optimized), at 0xc56b1800 (line ~209) in "ChangeRequestQueueProcessor.cxx" [31] sd::framework::ChangeRequestQueueProcessor::LinkStubProcessOneEvent(pThis = ???, pCaller = ???) (optimized), at 0xc56b173c (line ~176) in "ChangeRequestQueueProcessor.cxx" [32] ImplHandleUserEvent(pSVEvent = 0x8613220), line 2023 in "winproc.cxx" [33] ImplWindowFrameProc(pInst = 0x81986f0, _ARG2 = 0x8191098, nEvent = 22U, pEvent = 0x8613220), line 2521 in "winproc.cxx" [34] SalDisplay::DispatchInternalEvent(0x810e800, 0x875c978, 0x0, 0xcf17b8f8, 0x80c2234, 0x1), at 0xcee95d4c [35] GtkXLib::userEventFn(data = ???) (optimized), at 0xcf12a02f (line ~715) in "gtkdata.cxx" [36] call_userEventFn(data = ???) (optimized), at 0xcf129f60 (line ~688) in "gtkdata.cxx" [37] g_idle_dispatch(0x875c978, 0xcf129f48, 0x80c7e38), at 0xcefbae9f [38] g_main_dispatch(0x80e36f8), at 0xcefb7c3a [39] g_main_context_dispatch(0x80e36f8), at 0xcefb8d49 [40] g_main_context_iterate(0x80e36f8, 0x0, 0x1, 0x80c5db0), at 0xcefb9166 [41] g_main_context_iteration(0x80e36f8, 0x0), at 0xcefb93bf [42] GtkXLib::Yield(this = ???, bWait = ???, bHandleAllCurrentEvents = ???) (optimized), at 0xcf12a1a3 (line ~770) in "gtkdata.cxx" [43] X11SalInstance::Yield(0x80c2208, 0x1, 0x0), at 0xcee9b43b [44] Application::Yield(bAllEvents = ???) (optimized), at 0xd04ec7fe (line ~557) in "svapp.cxx" [45] Application::Execute() (optimized), at 0xd04ec71c (line ~516) in "svapp.cxx" [46] desktop::Desktop::Main(0x8047160), at 0x806d116 [47] ImplSVMain() (optimized), at 0xd04f2b30 (line ~262) in "svmain.cxx" [48] SVMain() (optimized), at 0xd04f2caf (line ~303) in "svmain.cxx" [49] 0x806686a(0x1, 0x80471f0), at 0x806686a [50] main(0x1, 0x80471f0, 0x80471f8), at 0x806678d Looks like the SlideSorterViewShell object ist fully constructed when asked to create an XAccessible.
Maybe splitting XAccessible and XAccessibleContext might help here.
Setting target to 3.0
Retareted to OOo 3.x due to time constraints.
MT->AF: For setting an appropriate target I need to understand the implication of this bug. What does this mean for a screen Reader user?!
The screen reader might not get some child-removed events as the atk bridge has an incomplete child list.
Mt->Af: Please look at this soon, might be the reason for i90993 and i90825
Without fixing this it is hard to say if this is the cause for issue 90993 and issue 90825. Therefore I set the target to OOo 3.2 so that we can find out (by fixing it). This is an ugly slicing problem anyway.
This is not a problem for the Unixes with Orca and Accerciser: the accessible object of the slide sorter is requested on demand, not on startup. This makes this a Windows only problem.
Fixed the workaround that was already in place. More details will follow. SVN revision of the changes is 276217.
Here are some details. On Windows, unlike the Unixes, the UNO/ATK bridge asks new windows for their accessibility objects at the moment the Window::Show() method is called. For the relevant windows of the side panes (both slide sorter bar and task pane) this is the case during construction of the view shells. At this time the links between windows and view shells and views are not yet set up because the constructor of the SlideSorterViewShell and the TaskPaneViewShell are not yet finished. As a result the cal of the virtual CreateAccessibleDocumentView() is answered by the base class ViewShell, not by SlideSorterViewShell or TaskPaneViewShell. The former returns an empty reference. To the caller an empty reference may be unexpected but is not illegal. As a workaround, that is in place since a long time, the bridge handles the empty reference gracefully and both slide sorter and task pane use a little trick to bring their accessible objects into place: when they are fully initialized and their virtual function table is properly set up they call Hide() and then Show() at the window in question. As a result the bridge asks a second time for the accessible objects and this time gets the correct accessibility objects. For the bridge this is standard behavior, hiding and showing windows is not an uncommon procedure. This all may not be elegant but does not misuse the API either. The only problem, the one that I have fixed, is that the slide sorter did the Hide()/Show() trick at the wrong time, too early. I moved the code to a later point in the initialization procedure and now the bridge gets the right accessibility object. A more elegant fix would require a rewrite of the initialization of all Impress view shells. Something that might introduce a lot more problems than it would solve.
@es: This fix can be verified with the JavaMonkey tool. It shows different child objects for the slide sorter node before and after the fix.
Verified in CWS impressaccessibility4|
Fixed and integrated => closing now..