Closed Bug 1310166 Opened 8 years ago Closed 8 years ago

QueryService() with IID_ISimpleDOMNode failed with e10s

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Version:
49 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla54
Tracking Flags:
Tracking Status
firefox54 --- fixed

People

(Reporter: rajeshcode, Assigned: bugzilla)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Register ISimpleDOMNode typelib in content
2.07 KB, patch
tbsaunde
: review+
Details | Diff | Splinter Review 
User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36

Steps to reproduce:

I am trying to find the URL from Mozilla window using VC++ project. For doing this, I used QueryService() API with parameter IID_ISimpleDOMNode". But the API fails on Windows 7 machines (both 32 bit and 64 bit) with Mozilla Version- 49.0.1. Sample code is given below:


// header files
#include "ISimpleDOMNode.h"
#include "ISimpleDOMText.h"
#include "ISimpleDOMDocument.h"

// GUIDs
const GUID refguid = {0x0c539790, 0x12e4, 0x11cf, 0xb6, 0x61, 0x00, 0xaa, 0x00, 0x4c, 0xd6, 0xd8};
const IID IID_ISimpleDOMNode= {0x1814ceeb,0x49e2,0x407f,0xaf,0x99,0xfa,0x75,0x5a,0x7d,0x26,0x07};
const IID IID_ISimpleDOMText= {0x4e747be5,0x2052,0x4265,0x8a,0xf0,0x8e,0xca,0xd7,0xaa,0xd1,0xc0};
const IID IID_ISimpleDOMDocument= {0x0D68D6D0,0xD93D,0x4d08,0xA3,0x0D,0xF0,0x0D,0xD1,0xF4,0x5B,0x24};

Void FindURLfromWindow(HWND hwnd)
{
	try
	{
		if(hwnd)
		{
			IAccessible *pAccBrowser = NULL;
			HRESULT hr = AccessibleObjectFromWindow(hwnd, OBJID_CLIENT, IID_IAccessible, (void**)&pAccBrowser);
			if(SUCCEEDED(hr) && (pAccBrowser))
			{
				VARIANT vtStart; 
				VARIANT vtResult;
				vtStart.vt = VT_I4;
				vtStart.lVal = CHILDID_SELF;
				/////////////////////////////
				hr = pAccBrowser->accNavigate(NAVRELATION_EMBEDS,vtStart,&vtResult);
				if(SUCCEEDED(hr))
				{
					IDispatch *pDisp = vtResult.pdispVal;
					IAccessible *pAccDoc = NULL; 
					hr = pDisp->QueryInterface(IID_IAccessible,(void **)&pAccDoc); 
					if(SUCCEEDED(hr) && (pAccDoc))
					{
						hr = pAccDoc->QueryInterface(IID_IServiceProvider, (void **)&pServProv); 
						if(SUCCEEDED(hr) && (pServProv))
						{
							ISimpleDOMNode *pNode = NULL; 
							hr = pServProv->QueryService(refguid, IID_ISimpleDOMNode,(void **)&pNode); //failed in Windows 7
							if(SUCCEEDED(hr) && (pNode))
							{
								ISimpleDOMDocument *pDoc = NULL; 
								hr = pNode->QueryInterface(IID_ISimpleDOMDocument, (void **)&pDoc); 
								if(SUCCEEDED(hr) && (pDoc))
								{
									BSTR bstrUrl = NULL;
									hr = pDoc->get_URL(&bstrUrl); 
									if(SUCCEEDED(hr) && (bstrUrl))
									{
										//success
									}
								}
							}
						}
					}
				}
			}
		}
	}
	catch(...)
	{
	}
}



Actual results:

QueryService() with IID_ISimpleDOMNode failed in Mozilla firefox version 49.0.1 on Windows 7 machines (both 32 bit and 64 bit).


Expected results:

QueryService() API call success with IID_ISimpleDOMNode to find the URL.
Severity: normal → major
OS: Unspecified → Windows 7
Priority: -- → P1
Hardware: Unspecified → x86_64
Do you have a testcase to reproduce the issue?
Severity: major → normal
Flags: needinfo?(rajeshcode)
Priority: P1 → --
(In reply to Loic from comment #1)
> Do you have a testcase to reproduce the issue?

Please follow the below steps to reproduce the issue:

1) Download and install Mozilla Firefox 49.0.1 from https://www.mozilla.org/en-US/firefox/new/  on Windows 7 (32/64 bit) machines.
2) Run the sample code which I send already.

Note:  The issue will not happens if we install Mozilla Firefox 48.x on windows 7 (32/64 bit) and update it into 49.0.1
Where do I need to run the code you wrote? How?
(In reply to Loic from comment #3)
> Where do I need to run the code you wrote? How?

Please follow the steps:

1) Create a sample VC++ project using "SetWinEventHook()" API to register the Window events.
2) With the event- "EVENT_OBJECT_NAMECHANGE" and Window class- "MozillaWindowClass" or "MozillaUIWindowClass", you need to call the functionality which I send already.
I don't know what's VC++ but if it's a C++ project with Visual Studio, it's out of my scope of testing.
If you can provide a simple DLL to launch to reproduce the issue, it will be better to test without creating a C++ project or something like that.

As you're able to reproduce the issue, could you download the tool mozregression to narrow down a regression.
See http://mozilla.github.io/mozregression/ for details to use it.
Run the command "mozregression --good=48 (or older)" then copy here the final pushlog from mozilla-inbound repository.
Keywords: regressionwindow-wanted
(In reply to Loic from comment #5)
> I don't know what's VC++ but if it's a C++ project with Visual Studio, it's
> out of my scope of testing.
> If you can provide a simple DLL to launch to reproduce the issue, it will be
> better to test without creating a C++ project or something like that.
> 
> As you're able to reproduce the issue, could you download the tool
> mozregression to narrow down a regression.
> See http://mozilla.github.io/mozregression/ for details to use it.
> Run the command "mozregression --good=48 (or older)" then copy here the
> final pushlog from mozilla-inbound repository.


For creating sample DLL/EXE file, we need more time. Here are the test results you requested with "mozregression", hope this will help:

1) Command -> mozregression-gui --good=48, result:

Output folder: C:\Program Files\mozregression-gui
Create folder: C:\Program Files\mozregression-gui
Extract: PyQt4.QtCore.pyd
Extract: PyQt4.QtGui.pyd
Extract: QtCore4.dll
Extract: QtGui4.dll
Extract: _ctypes.pyd
Extract: _hashlib.pyd
Extract: _multiprocessing.pyd
Extract: _socket.pyd
Extract: _sqlite3.pyd
Extract: _ssl.pyd
Extract: bz2.pyd
Extract: cacert.pem
Extract: mozregression-gui.exe
Extract: pyexpat.pyd
Extract: python27.dll
Extract: select.pyd
Extract: sip.pyd
Extract: sqlite3.dll
Extract: unicodedata.pyd
Output folder: C:\Program Files\mozregression-gui\imageformats
Extract: qgif4.dll
Extract: qico4.dll
Extract: qjpeg4.dll
Extract: qmng4.dll
Extract: qsvg4.dll
Extract: qtga4.dll
Extract: qtiff4.dll
Output folder: C:\Program Files\mozregression-gui
Extract: app_icon.ico
Created uninstaller: C:\Program Files\mozregression-gui\uninstall.exe
Create folder: C:\Users\win7\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\mozregression-gui
Create shortcut: C:\Users\win7\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\mozregression-gui\uninstall.lnk
Create shortcut: C:\Users\win7\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\mozregression-gui\mozregression-gui.lnk
Completed


2) Command -> mozregression-gui --good=49.0.1, result:

Output folder: C:\Program Files\mozregression-gui
Create folder: C:\Program Files\mozregression-gui
Extract: PyQt4.QtCore.pyd
Extract: PyQt4.QtGui.pyd
Extract: QtCore4.dll
Extract: QtGui4.dll
Extract: _ctypes.pyd
Extract: _hashlib.pyd
Extract: _multiprocessing.pyd
Extract: _socket.pyd
Extract: _sqlite3.pyd
Extract: _ssl.pyd
Extract: bz2.pyd
Extract: cacert.pem
Extract: mozregression-gui.exe
Extract: pyexpat.pyd
Extract: python27.dll
Extract: select.pyd
Extract: sip.pyd
Extract: sqlite3.dll
Extract: unicodedata.pyd
Output folder: C:\Program Files\mozregression-gui\imageformats
Extract: qgif4.dll
Extract: qico4.dll
Extract: qjpeg4.dll
Extract: qmng4.dll
Extract: qsvg4.dll
Extract: qtga4.dll
Extract: qtiff4.dll
Output folder: C:\Program Files\mozregression-gui
Extract: app_icon.ico
Created uninstaller: C:\Program Files\mozregression-gui\uninstall.exe
Create folder: C:\Users\win7\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\mozregression-gui
Create shortcut: C:\Users\win7\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\mozregression-gui\uninstall.lnk
Create shortcut: C:\Users\win7\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\mozregression-gui\mozregression-gui.lnk
Completed



3) Command -> mozregression-gui --bad=49.0.1, result:

Output folder: C:\Program Files\mozregression-gui
Create folder: C:\Program Files\mozregression-gui
Extract: PyQt4.QtCore.pyd
Extract: PyQt4.QtGui.pyd
Extract: QtCore4.dll
Extract: QtGui4.dll
Extract: _ctypes.pyd
Extract: _hashlib.pyd
Extract: _multiprocessing.pyd
Extract: _socket.pyd
Extract: _sqlite3.pyd
Extract: _ssl.pyd
Extract: bz2.pyd
Extract: cacert.pem
Extract: mozregression-gui.exe
Extract: pyexpat.pyd
Extract: python27.dll
Extract: select.pyd
Extract: sip.pyd
Extract: sqlite3.dll
Extract: unicodedata.pyd
Output folder: C:\Program Files\mozregression-gui\imageformats
Extract: qgif4.dll
Extract: qico4.dll
Extract: qjpeg4.dll
Extract: qmng4.dll
Extract: qsvg4.dll
Extract: qtga4.dll
Extract: qtiff4.dll
Output folder: C:\Program Files\mozregression-gui
Extract: app_icon.ico
Created uninstaller: C:\Program Files\mozregression-gui\uninstall.exe
Create folder: C:\Users\win7\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\mozregression-gui
Create shortcut: C:\Users\win7\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\mozregression-gui\uninstall.lnk
Create shortcut: C:\Users\win7\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\mozregression-gui\mozregression-gui.lnk
Completed
(In reply to rajeshcode from comment #6)
> For creating sample DLL/EXE file, we need more time. Here are the test
> results you requested with "mozregression", hope this will help:

You need to use the mozregression GUI to run a bisection. The software will download nightly builds then you make your test. for each build, you enter if the build is good or bad.
After that, you'll get a pushlog like 
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=63cc176d76a66b1807ea4b9500651063032123b1&tochange=d24b11e4beb29e7b0941121b93b10fc155c53a4e e.g.

That's this pushlog we need.
Simply we are following the Document Object Model (DOM) methodology to find the URL from Mozilla windows. So is there any changes in DOM model with fresh install of Mozilla (version 49.0.1) on Windows 7 (32bit/64bit). Because we are not getting the values of pointer "IID_ISimpleDOMNode".
Did yu try to run mozrgression again?
(In reply to Loic from comment #9)
> Did yu try to run mozrgression again?

Is it possible to send the step by step procedure for mozrgression?
(In reply to rajeshcode from comment #10)
> Is it possible to send the step by step procedure for mozrgression?

You will find all the documentation on that website: http://mozilla.github.io/mozregression/
NB: if you use the command-line version, you need to install python 2.7.

Mozregression downloads nighly builds one by one (by dichotomy) and you have to test your bug for each nightly downloaded to know if it's a good or a bad build.
Maybe you will need to modify your C++ project to detect the nightly.exe executable.
After the regression run, you will get a pushlog from the repository mozilla-inbound that you need to copy here.
(In reply to Loic from comment #11)
> (In reply to rajeshcode from comment #10)
> > Is it possible to send the step by step procedure for mozrgression?
> 
> You will find all the documentation on that website:
> http://mozilla.github.io/mozregression/
> NB: if you use the command-line version, you need to install python 2.7.
> 
> Mozregression downloads nighly builds one by one (by dichotomy) and you have
> to test your bug for each nightly downloaded to know if it's a good or a bad
> build.
> Maybe you will need to modify your C++ project to detect the nightly.exe
> executable.
> After the regression run, you will get a pushlog from the repository
> mozilla-inbound that you need to copy here.


Then link:-  http://mozilla.github.io/mozregression/quickstart.html    shows that we need to enter the known "good" date and known "bad" date. Actually we are testing these issue on virtual machines and every day we are resetting the OS images, so how can we enter the "good" date and "bad" date.
You don't need the dates. You said in comment #2 the issue was NOT present in FF48, so there is probably a regression introduced in FF49.
So after installed mozegression (if you use the command-line version, you need to install python 2.7 before), just run a bisection from --good=48 (or even 47 whatever), you don need to know a bad date.
For each nightly downloaded, you make the test with the IID_ISimpleDOMNode stuff and you enter if the build is good or bad.
We have created test application for reproducing the issue, please download the files from https://www.dropbox.com/s/ytt43inoyxarxbs/Mozilla.zip?dl=0   it contains four folders
1) Project - source code of the test application
2) Screenshot - you can see the issue
3) Test exe file - test application binary
4) Test tool - utility to capture the test application output

Kindly install fresh Mozilla Firefox 49.x into Windows 7 machines to reproduce the issue. Also please note that issue will not happening on Windows 8/10. You can notice that in Windows 7, the test tool (Dbgview) will have the line "MozillaTest: QueryService(IID_ISimpleDOMNode) failed". Please follow the below steps to reproduce the problem:
1) Install fresh Firefox 49.x on Windows 7 machine
2) Run Dbgview as administrator (please check the options as mentioned in Screnshot folder)
3) Run the test application.
4) Browse any websites using Firefox, now you will be able to see the error message mentioned above in Dbgview tool.

Please let us know if you have any questions. It would be helpful if we can interact with your development team to discuss the issue.
I tried but I can't reproduce the issue.
I got:
[4648] MozillaTest: before InstallHook -[Dlg]
[4648] MozillaTest: WindowsEventHookUrl success
[4648] MozillaTest: after InstallHook -[Dlg]
one time when starting Dbgview then nothing more when browsing websites in Firefox.

Any idea? (I'm on Win 7 64b)
(In reply to Loic from comment #15)
> I tried but I can't reproduce the issue.
> I got:
> [4648] MozillaTest: before InstallHook -[Dlg]
> [4648] MozillaTest: WindowsEventHookUrl success
> [4648] MozillaTest: after InstallHook -[Dlg]
> one time when starting Dbgview then nothing more when browsing websites in
> Firefox.
> 
> Any idea? (I'm on Win 7 64b)


Could you please check the same with latest test application from https://www.dropbox.com/s/851wub8wnd7dhof/MozillaNew.zip?dl=0

You need to run the test application before Mozilla instance starts (before browsing with Mozilla).
Works fine now, your test application is able to catch URL from FF49 on my Win 7.

[6212] MozillaTest: OBJECT_HIDE event
[6212] MozillaTest: AccessibleObjectFromWindow success
[6212] MozillaTest: accNavigate success
[6212] MozillaTest: QueryInterface(IID_IAccessible) success
[6212] MozillaTest: QueryInterface(IID_IServiceProvider) success
[6212] MozillaTest: QueryService(IID_ISimpleDOMNode) success
[6212] MozillaTest: QueryInterface(IID_ISimpleDOMDocument) success
[6212] MozillaTest: get_URL success
[6212] https://www.reddit.com/r/DotA2/

[6212] MozillaTest: OBJECT_SHOW event
[6212] MozillaTest: AccessibleObjectFromWindow success
[6212] MozillaTest: accNavigate success
[6212] MozillaTest: QueryInterface(IID_IAccessible) success
[6212] MozillaTest: QueryInterface(IID_IServiceProvider) success
[6212] MozillaTest: QueryService(IID_ISimpleDOMNode) success
[6212] MozillaTest: QueryInterface(IID_ISimpleDOMDocument) success
[6212] MozillaTest: get_URL success
[6212] https://bugzilla.mozilla.org/show_bug.cgi?id=1310166

[6212] MozillaTest: OBJECT_HIDE event
[6212] MozillaTest: AccessibleObjectFromWindow success
[6212] MozillaTest: accNavigate success
[6212] MozillaTest: QueryInterface(IID_IAccessible) success
[6212] MozillaTest: QueryInterface(IID_IServiceProvider) success
[6212] MozillaTest: QueryService(IID_ISimpleDOMNode) success
[6212] MozillaTest: QueryInterface(IID_ISimpleDOMDocument) success
[6212] MozillaTest: get_URL success
[6212] about:newtab


I searched for "failed" in the log file, I found none.
Flags: needinfo?(rajeshcode)
I think I found the root cause. It fails with e10s (multiprocess) enabled.

Can you type about:config in the location bar and check both strings:
1) browser.tabs.remote.autostart (should be false by default)
2) browser.tabs.remote.force-enable (should be missing by default)

If they are true, set them to false, restart Fiefox and test again.
Flags: needinfo?(rajeshcode)
I forgot to add it's probably due to:
https://support.mozilla.org/en-US/kb/accessibility-and-ppt
Component: Untriaged → Disability Access APIs
Product: Firefox → Core
Firefox 49 does not support accessibility in E10S yet. The earliest version that we expect to somehow work is 51, which will go to beta soon'ish. But best results will be obtained with 52 onwards. So please check this with a Nightly build and report back here if the problem persists.
(In reply to Loic from comment #18)
> I think I found the root cause. It fails with e10s (multiprocess) enabled.
> 
> Can you type about:config in the location bar and check both strings:
> 1) browser.tabs.remote.autostart (should be false by default)
> 2) browser.tabs.remote.force-enable (should be missing by default)
> 
> If they are true, set them to false, restart Fiefox and test again.


I checked with about:config and the results are:
1) browser.tabs.remote.autostart is false (default)
2) browser.tabs.remote.force-enable is missing

I created the entry "browser.tabs.remote.force-enable" and set to false, then restarted Firefox and test again with my test application but no luck.
(In reply to Loic from comment #19)
> I forgot to add it's probably due to:
> https://support.mozilla.org/en-US/kb/accessibility-and-ppt

These things will not solve the issue.
Can you test with a fresh profile, please:
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

It will "clean" all bad prefs about e10s.
(In reply to Marco Zehe (:MarcoZ) from comment #20)
> Firefox 49 does not support accessibility in E10S yet. The earliest version
> that we expect to somehow work is 51, which will go to beta soon'ish. But
> best results will be obtained with 52 onwards. So please check this with a
> Nightly build and report back here if the problem persists.

Accessibility related information with Firefox are stored in "AccessibleMarshal.dll" (C:\Program files\Mozilla Firefox) I guess. I tried to register (using regsvr32.exe) this dll file with Mozilla Firefox version 48.0.2 and the result was success. But when we tried to register the same dll file with Mozilla Firefox version 49.0.2 and result was failed. Error message shows "The module "C:\Program Files\Mozilla Firefox\AccessibleMarshal.dll" failed to load". Could you please check the same on you environment.
We checked this issue with Mozilla Firefox Nightly build, version- 52.0a1 (2016-11-01) (32-bit), and in this version the API "accNavigate" failed.
(In reply to Marco Zehe (:MarcoZ) from comment #20)
> Firefox 49 does not support accessibility in E10S yet. The earliest version
> that we expect to somehow work is 51, which will go to beta soon'ish. But
> best results will be obtained with 52 onwards. So please check this with a
> Nightly build and report back here if the problem persists.

We have a Screen Reading application, and we are unable to do our functionalities in Mozilla Firefox 49.x on Windows 7 machines due to the Accessibility issues. It was working fine till Firefox version 48.x. Since this issue is affecting many of our customers, is it possible to solve this issue on the next release of Firefox ?
Alex, any ideas?
Flags: needinfo?(surkov.alexander)
Not sure if I can be helpful here. Per comment #24 it may be a dll registration problem on a particular machine (since it works for Loic). Maybe the bell rings for Aaron?
Flags: needinfo?(surkov.alexander)
The code that regsvr32 executes in AccessibleMarshal.dll is just the default generated code that passes the library's proxy information to the NdrDllRegisterProxy API. There's nothing there that has changed between versions.

If the DLL cannot be loaded, that would suggest some kind of problem with the binary itself. Unless somebody else can confirm that registration fails for them on 49.0.2, I'd suggest that the reporter verify that the binary is unmodified from the original that was shipped. It might also be a good idea to ensure that a virus scanner or some other kind of security tool hasn't mistakenly identified that DLL as malware and tried to "clean" it. I could see that corrupting the DLL.

Another suggestion would be to run procmon and monitor the activity of regsvr32 while it is running. Maybe that could shed some more light on the DLL loading failure.

But unless somebody independently of the bug reporter can confirm a problem loading AccessibleMarshal.dll with regsvr32, I don't think that there is anything that is actionable by us.
(In reply to Aaron Klotz [:aklotz] from comment #29)
> The code that regsvr32 executes in AccessibleMarshal.dll is just the default
> generated code that passes the library's proxy information to the
> NdrDllRegisterProxy API. There's nothing there that has changed between
> versions.
> 
> If the DLL cannot be loaded, that would suggest some kind of problem with
> the binary itself. Unless somebody else can confirm that registration fails
> for them on 49.0.2, I'd suggest that the reporter verify that the binary is
> unmodified from the original that was shipped. It might also be a good idea
> to ensure that a virus scanner or some other kind of security tool hasn't
> mistakenly identified that DLL as malware and tried to "clean" it. I could
> see that corrupting the DLL.
> 
> Another suggestion would be to run procmon and monitor the activity of
> regsvr32 while it is running. Maybe that could shed some more light on the
> DLL loading failure.
> 
> But unless somebody independently of the bug reporter can confirm a problem
> loading AccessibleMarshal.dll with regsvr32, I don't think that there is
> anything that is actionable by us.

Today we checked the issue with two machines (fresh image), Windows 7 32bit and 64bit. And we can able to register the "AccessibleMarshal.dll" file, but the issue is still exists. Kindly download the test result from https://www.dropbox.com/sh/j37felx1ad1bglp/AABcpSXM6jbWwm5RG0qX-4lya?dl=0   and we are getting the error code 127 (ERROR_PROC_NOT_FOUND) with "IID_ISimpleDOMNode".

Is it possible to include the fix for accessibility support in E10S (multiprocess) on the very next version of the Firefox ? Because we have an urgency for this feature.
(In reply to rajeshcode from comment #30)

> Is it possible to include the fix for accessibility support in E10S
> (multiprocess) on the very next version of the Firefox ? Because we have an
> urgency for this feature.

see comment #20, multiprocess accessibility is not yet ready. Until this is done, Firefox will be running in single process mode, when accessibility use is detected.
I would appreciate if you can provide a tentative release date of Firefox 52 ?
Thank you.
Flags: needinfo?(rajeshcode)
Keywords: regressionwindow-wanted
Summary: QueryService() with IID_ISimpleDOMNode failed in Mozilla firefox version 49.0.1 → QueryService() with IID_ISimpleDOMNode failed with e10s
update:

we checked the same issue with FireFox Beta 52.0b2 on Windows 7 (32 bit) machine and issue is still there. we also checked FireFox Dev 53.0A2 on Windows 7 (32 bit) machine, this version is also not working.
We were told that issue will get resolved on Firefox 52. Do you have an update in which beta version this issue ( accessibility not working on Windows 7) will get resolved?
Alex , Logic,  can you comment on this issue?
I'm not a dev and the issue has been commented in comment #29.
Logic, i am bit confused.  According to comment #31,#20  this issue should be fixed on FireFox release 52.  We have tested with 52 beta and found that issue is still there. Do you have any update on this?
Currently we are targeting version 54.
I think that the problem here is that a11y+e10s on Windows requires the typelib to be registered, which it doesn't look like we're doing yet. This should be an easy patch, actually.

I can take this.
Assignee: nobody → aklotz
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Aaron , the release date planned for version 54 is June 2017 (depends on comment #39), so is there any possibility to get this fix before version 54, because we are seriously waiting for this fix from October 2016.

We tried to register the "AccessibleMarshal.dll" using the API "RegisterTypeLib()", but LoadTypeLib() failed with error code- 0x80029c4a.
Attachment #8840524 - Flags: review?(tbsaunde+mozbugs) → review+
(In reply to rajeshcode from comment #42)
> Aaron , the release date planned for version 54 is June 2017 (depends on
> comment #39), so is there any possibility to get this fix before version 54,
> because we are seriously waiting for this fix from October 2016.

I am not sure that I understand your request. We will not be shipping with e10s enabled for a11y on Windows until version 54. Until then, end users will still be running their ATs against single-process Firefox.
https://hg.mozilla.org/mozilla-central/rev/caf97eac5613
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
status-firefox54: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
(In reply to Aaron Klotz [:aklotz] from comment #44)
> (In reply to rajeshcode from comment #42)
> > Aaron , the release date planned for version 54 is June 2017 (depends on
> > comment #39), so is there any possibility to get this fix before version 54,
> > because we are seriously waiting for this fix from October 2016.
> 
> I am not sure that I understand your request. We will not be shipping with
> e10s enabled for a11y on Windows until version 54. Until then, end users
> will still be running their ATs against single-process Firefox.

Aaron, we have tried running Firefox (version 51.0.1) on single process mode. Accessibility has shown as enabled in "about:support" window, and we are still facing the same issue (Windows 7 OS).
Firefox settings has been uploaded to https://www.dropbox.com/sh/nnbpgz9cjas000l/AABv4mdck_ecgIeqUmDHafmOa?dl=0

can you help us to run the accessibility in single process mode?
Aaron , Loic , we are also facing the issue in accessibility API (QueryService() with IID_ISimpleDOMNode failed) with single process mode in Windows 7.  Can you check this issue?
It fails with FF51 and old versions of Firefox (with e10s disabled) so I don't think it's an issue with Firefox.
Are you sure a recent update of Win 7 didn't break your test application in comment #16?
This bug is specifically for e10s. Please file a separate bug if you have concerns for non-e10s mode.
Aaron , Loic, created a ticket for non e10s issue https://bugzilla.mozilla.org/show_bug.cgi?id=1343525
(In reply to Wes Kocher (:KWierso) from comment #45)
> https://hg.mozilla.org/mozilla-central/rev/caf97eac5613

Loic, Aron, We have tested with FF 54.0b2 version. Still this issue is not fixed. Please let us know if you need any details to resolve this issue.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: