Bug 251084 - NullPointerException when VoiceOver asks for position of Shell
Summary: NullPointerException when VoiceOver asks for position of Shell
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 3.5   Edit
Hardware: Macintosh Mac OS X
: P3 normal (vote)
Target Milestone: 3.5 M3   Edit
Assignee: Scott Kovatch CLA
QA Contact:
URL:
Whiteboard:
Keywords: accessibility
Depends on:
Blocks:
 
Reported: 2008-10-16 10:19 EDT by Carolyn MacLeod CLA
Modified: 2008-10-29 14:40 EDT (History)
3 users (show)

See Also:


Attachments
patch to defer to the os unless the app specifies a new position or size (2.29 KB, patch)
2008-10-16 16:54 EDT, Carolyn MacLeod CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Carolyn MacLeod CLA 2008-10-16 10:19:59 EDT
- load the latest SWT Cocoa from HEAD
- Run org.eclipse.swt.examples.accessibility.ControlsWithAccessibleNamesExample
- Turn on VoiceOver
- NPE

The NPE comes from this line in getPositionAttribute:

   Point pt = control.getParent().toDisplay(location.x, location.y);

The reason is that the control in this case is a Shell, and (top level) shells do not have a parent, so control.getParent() is null.

The attached patch fixes the problem, however you will note that the patch goes further and it removes the entire 'else' case. This is because when the application does not answer anything, then we need to defer entirely to Cocoa for the position, size, etc.

So the attached patch fixes the "if the app does nothing, then we do nothing" case for getPositionAttribute and getSizeAttribute. I did not go through the other attributes to do the same thing, but the same logic applies - we should only answer something if the app does.
Comment 1 Scott Kovatch CLA 2008-10-16 16:33:45 EDT
Hi Carolyn,

I fixed this as well but haven't committed it yet. You left off the patch but I get what you're saying here. I was making a last-second attempt to correctly represent the size of a StyledText, which shows as 100000x100000, but I see I goofed. We should try to fix that instead of working around it in accessibility.
Comment 2 Carolyn MacLeod CLA 2008-10-16 16:54:05 EDT
Created attachment 115312 [details]
patch to defer to the os unless the app specifies a new position or size

Very Strange. I attached the patch as part of creating the bug (new feature of Bugzilla), but it seems to have been ignored. Anyhow, here it is now.
Comment 3 Scott Kovatch CLA 2008-10-16 17:55:01 EDT
Thanks -- fixed >= 20081016.

I will file a new bug for the huge Canvas size.
Comment 4 Scott Kovatch CLA 2008-10-16 18:31:51 EDT
Actually, I need to make one small modification.  If the child ID passed in is non-zero, we are expecting the accessible listener to calculate the size and position. If it doesn't we need to return some kind of NSValue, because otherwise the Accessibility Verifier will correctly points out that no value was returned for the kAXSize attribute even though we declared it for the object. Probably 0, 0 for the size and the top-left of the Canvas/Composite.
Comment 5 Scott Kovatch CLA 2008-10-22 15:43:12 EDT
Fixed >= 20081022, including my last extra fix mentioned in #4.