397356 - Query Interface nsIAccessibleRetrieval on @mozilla.org/accessibleRetrieval;1 fails

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect)

Description

[Abe]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Build Identifier: 3.0a8

Querying Interface nsIAccessibleRetrieval on @mozilla.org/accessibleRetrieval;1 fails with error 80004002 (no such interface)

The same code works fine with Firefox 2.x

Environment: Windows XP

In process extension DLL (C++) call:
nsCOMPtr<nsIAccessibleRetrieval> refp =  do_GetService("@mozilla.org/accessibleRetrieval;1", &rv);

We compile & link with gecko 1.8 SDK (nspr4.lib xpcomglue_s.lib xpcom.lib  comsupp.lib) 

Reproducible: Always

Steps to Reproduce:
1. Create an Add-on DLL as per description above
2. call the function
3.
Actual Results:  
Fails with error 80004002 (no such interface)

Expected Results:  
A vaild Interface pointer

Comment 1

[Aaron Leventhal]

I see you are building your own.

Does the DOM Inspector work for you? It is working in the nightly builds, and that code depends on accessibleRetrieval, e.g.:
http://lxr.mozilla.org/seamonkey/source/extensions/inspector/resources/content/viewers/accessibleObject/accessibleObject.js#56
 56 const kAccessibleRetrievalCID = "@mozilla.org/accessibleRetrieval;1";
 58 const nsIAccessibleRetrieval = Components.interfaces.nsIAccessibleRetrieval;

So this appears to be something different in your code or build.

Comment 2

[alexander :surkov (:asurkov)]

Do you compile with gecko 1.8 but test with 1.9?

Comment 3

[Abe]

DOM inspector works fine.

Yes we do compile & link with 1.8. Compiling should not be a factor as the header file did not change. Linking may be an issue if there is a change specific to this call.
Are you aware of such a difference?

I will try to compile & link with 1.9 and report back.

Comment 4

[Abe]

I now compiled & linked with the latest 1.9 (http://ftp.mozilla.org/pub/mozilla.org/xulrunner/nightly/latest-trunk/xulrunner-1.9a9pre.en-US.win32.sdk.zip)

I linked with xpcomglue_s.lib xpcom.lib nspr4.lib and comsupp.lib  

The problem is still the same with Gran Paradiso 8. Error 80004002

The new compile is NOT Firefox 2 compatible as it generates stack corruption errors. But, the call to get nsIAccessibleRetrieval succeeds with Firefox 2 and this new link.

The fact that DOM Inspector works OK, may point to an issue with the glue libraries (since DOM inspector uses scripting components).

Comment 5

[alexander :surkov (:asurkov)]

Can you put small testcase I can try?

Comment 6

[Abe]

I have a test case ready. How do I post it?

Comment 7

[Abe]

Attachment: A compressed extension folder

Please install this folder under the extensions folder of the current profile and start Gran Paradiso and watch for error messages.

Comment 8

[Abe]

The attached extension dll was compiled and linked with sdk provided in
http://ftp.mozilla.org/pub/mozilla.org/xulrunner/nightly/latest-trunk/xulrunner-1.9a9pre.en-US.win32.sdk.zip  last modified on 10/24/2007

Linked to xpcomglue_s.lib xpcom.lib nspr4.lib

The code that generates the error message is invoked by method Init() which is called from foxtest.js. A similar test (jsShow) is run if you click on the foxtest button on the Addon's toolbar.

The test code is:

NS_IMETHODIMP foxtest::Init(nsIWebProgress* pProgress)
{
alert(_T("Init Called, getting nsIAccessibleRetrieval interface"));

nsresult rv; 
nsCOMPtr<nsIAccessibleRetrieval> spAr =  do_GetService("@mozilla.org/accessibleRetrieval;1", &rv);
if(NS_FAILED(rv)){
	alert(_T("no accessible interface"));
}
else
	alert(_T("accessible interface"));
return NS_OK;
}

Comment 9

[Abe]

Attachment: Source code for the extension

Source files that make up the extension. Not including project files.

Comment 10

[Abe]

(In reply to comment #5)
> Can you put small testcase I can try?

Please see attachments that can be used to recreate the bug.

Comment 11

[Abe]

Aaron, why did you remove the "Blocks 396346" from this bug?

Comment 12

[Aaron Leventhal]

Because I don't currently consider it as high priority as some of our other issues.

Comment 13

[Abe]

Tested with headers of Beta2Pre and Firefox 3.0b1. The bug is fixed.

Comment 14

[alexander :surkov (:asurkov)]

Thank you for keeping up to date. It's not fixed until you pointed bug number where bug has been fixed actually. So worksforme.