Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | SdWindow returns empty accessible | ||
---|---|---|---|
Product: | Impress | Reporter: | nospam4obr |
Component: | code | Assignee: | eric.savary |
Status: | CLOSED FIXED | QA Contact: | issues@graphics <issues> |
Severity: | Trivial | ||
Priority: | P3 | CC: | eric.savary, issues |
Version: | 680m225 | Keywords: | accessibility |
Target Milestone: | OOo 3.2 | ||
Hardware: | All | ||
OS: | Windows, all | ||
Issue Type: | DEFECT | Latest Confirmation in: | --- |
Developer Difficulty: | --- |
Description
nospam4obr
2007-08-24 09:00:55 UTC
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.. Fixed and integrated => closing now.. |