Closed Bug 397356 Opened 13 years ago Closed 13 years ago

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

Categories

(Core :: Disability Access APIs, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: bugzilla.mozilla.org.4398, Assigned: surkov)

Details

Attachments

(2 files)

8.15 KB, application/octet-stream
Details
2.42 KB, application/octet-stream
Details
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
Assignee: aaronleventhal → surkov.alexander
Blocks: fox3access
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.
Do you compile with gecko 1.8 but test with 1.9?
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.

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).

Can you put small testcase I can try?
No longer blocks: fox3access
I have a test case ready. How do I post it?
Please install this folder under the extensions folder of the current profile and start Gran Paradiso and watch for error messages.
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;
}



Source files that make up the extension. Not including project files.
(In reply to comment #5)
> Can you put small testcase I can try?

Please see attachments that can be used to recreate the bug.
Aaron, why did you remove the "Blocks 396346" from this bug?
Because I don't currently consider it as high priority as some of our other issues.
Tested with headers of Beta2Pre and Firefox 3.0b1. The bug is fixed.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Thank you for keeping up to date. It's not fixed until you pointed bug number where bug has been fixed actually. So worksforme.
Resolution: FIXED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.