Closed Bug 1346788 Opened 7 years ago Closed 5 years ago

XULTabAccessibles are recreated when the active tab changes

Categories

(Core :: Disability Access APIs, defect, P3)

52 Branch
x86_64
Windows
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: rajeshcode, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Steps to reproduce:

We tried to find the uniqueID for every tabs in a Mozilla Firefox window using "IAccessible2::get_uniqueID()" and this function always success ad returning uniqueID as negative value. But every time the value from get_uniqueID() varying for the same tab, and the description of "get_uniqueID()" shows that the uniqueID is not changing the life time of an object.


Actual results:

IAccessible2::get_uniqueID() is varying every time when we trying to access the same object (browser tab) in a Mozilla firefox window.


Expected results:

Need same uniqueID for single object (life time of that object) from "IAccessible2::get_uniqueID()" function.
Severity: normal → critical
Component: Untriaged → Disability Access
OS: Unspecified → Windows
Hardware: Unspecified → x86_64
Summary: IAccessible2::get_uniqueID() is varying every time when we trying to access → IAccessible2::get_uniqueID() is varying every time when we trying to access same object
Team, this is a basic API on MSAA interface. Any idea why it is not working as expected?
Well, this is obviously not a problem all ATs are having, or we would have heard something by now. It seems to be something unique to your way of querying things. So a bit of sample code might be helpful. What version of Firefox are you having this problem with? What version of Windows? Have you fiddled with settings, like turning on E10S (multi-process) even though it is not supported officially yet? Etc.
Severity: critical → normal
Component: Disability Access → Disability Access APIs
Product: Firefox → Core
(In reply to Marco Zehe (:MarcoZ) from comment #2)
> Well, this is obviously not a problem all ATs are having, or we would have
> heard something by now. It seems to be something unique to your way of
> querying things. So a bit of sample code might be helpful. What version of
> Firefox are you having this problem with? What version of Windows? Have you
> fiddled with settings, like turning on E10S (multi-process) even though it
> is not supported officially yet? Etc.

Hi Marco Zehe, first I wish to inform you that if we use the DOM (Document Object Model) along with "IAccessible2::get_uniqueID()" then we can get the proper unique ID for each Tab Windows. But if we use the MSAA along with "IAccessible2::get_uniqueID()" then we are not getting the proper unique IDs, and every time the unique ID is changing. Firefox version- 52.0, We checked with Windows 7 OS (both 32 and 64 bit) only, we didn't change the E10S settings. Sample code is given below:
----------------------------------
if(tab name matched)
{
	long lngUid = 0;
	IAccessible2 *pIAcc2 = NULL;
	IAccessible *pIAccTab	= NULL;
	IServiceProvider *pService = NULL;
	pIAccTab = *pIAccChild;
	//////////////////////////////////////////////
	hr = pIAccTab->QueryInterface(IID_IServiceProvider, (void **)&pService);
	if(SUCCEEDED(hr) && (pService))
	{
		hr = pService->QueryService(IID_IAccessible, IID_IAccessible2, (void**)&pIAcc2);
		if((SUCCEEDED(hr)) && (pIAcc2))
		{
			hr = pIAcc2->get_uniqueID(&lngUid); // not getting the proper unique IDs
			if(SUCCEEDED(hr))
			{
				if(pIAcc2)
					SAFE_RELEASE(pIAcc2);
				if(pService)
					SAFE_RELEASE(pService);
				break;
			}
			if(pIAcc2)
				SAFE_RELEASE(pIAcc2);
		}
		if(pService)
			SAFE_RELEASE(pService);
	}//End if hr
}
-----------------------------------------------

Hope this will help, otherwise we will provide you a test application.
> if we use the DOM (Document Object Model) along with "IAccessible2::get_uniqueID()" then we can get the proper unique ID for each Tab Windows. But if we use the MSAA along with "IAccessible2::get_uniqueID()" then we are not getting the proper unique IDs, and every time the unique ID is changing.

Could you clarify what exactly you mean when you talk about using the DOM vs using MSAA?

> Hope this will help, otherwise we will provide you a test application.

Overall this code looks like it should work. But I think we'll need to see a bit more, like where pIAccChild is coming from.

A more complete code sample (or perhaps a full test app) would be helpful.
Flags: needinfo?(rajeshcode)
(In reply to Aaron Klotz [:aklotz] from comment #4)
> > if we use the DOM (Document Object Model) along with "IAccessible2::get_uniqueID()" then we can get the proper unique ID for each Tab Windows. But if we use the MSAA along with "IAccessible2::get_uniqueID()" then we are not getting the proper unique IDs, and every time the unique ID is changing.
> 
> Could you clarify what exactly you mean when you talk about using the DOM vs
> using MSAA?
> 
> > Hope this will help, otherwise we will provide you a test application.
> 
> Overall this code looks like it should work. But I think we'll need to see a
> bit more, like where pIAccChild is coming from.
> 
> A more complete code sample (or perhaps a full test app) would be helpful.


Hi Aaron, here is the link for test application along with project source and Dbgview tool-> https://www.dropbox.com/s/9m80fxskajicqpj/TestAppMozilla.zip?dl=0

1) Run the Dbgview tool as administrator privilege.
2) Run test application
3) Browse atleast two tabs in Mozilla window.
4) Check the "UniqueID" for each tab and you can simultaneously visit each tab and cross check the same. You can see the that "UniqueID" is changing each time when you visit the same tab again and again.

You can also view the video for live testing-> https://www.screencast.com/t/nAGX5bqF
I looked into this to ensure that MSAA ID generation was looking OK (since I recently rewrote that), and it looks fine.

What I am noticing here is that the ID changes in the test program because the accessible object itself has changed. The accessible that the test program resolves is a XULTabAccessible. It looks to me like on every tab switch the resolved XULTabAccessible is different.

I don't know anything about how what the lifetime of XUL tabs are or what the lifetime of XULTabAccessibles are, so I cannot comment any further on that. I'll have to defer to somebody on the a11y team for that.

ni? Trevor to see what he knows.
Flags: needinfo?(rajeshcode) → needinfo?(tbsaunde+mozbugs)
(In reply to Aaron Klotz [:aklotz] from comment #6)
> I looked into this to ensure that MSAA ID generation was looking OK (since I
> recently rewrote that), and it looks fine.
> 
> What I am noticing here is that the ID changes in the test program because
> the accessible object itself has changed. The accessible that the test
> program resolves is a XULTabAccessible. It looks to me like on every tab
> switch the resolved XULTabAccessible is different.
> 
> I don't know anything about how what the lifetime of XUL tabs are or what
> the lifetime of XULTabAccessibles are, so I cannot comment any further on
> that. I'll have to defer to somebody on the a11y team for that.

they are destroyed when the content (in this case the xul tab containing a content tab) is layed out and changes.  I'm not sure how you are obtaining the accessible, but there's probably no requirement that keeps producing the same accessible.  So this may be undesirable, but I'm not sure its a bug, or even that this changed recently.
Flags: needinfo?(tbsaunde+mozbugs)
Summary: IAccessible2::get_uniqueID() is varying every time when we trying to access same object → XULTabAccessibles are recreated when the active tab changes
We have been using  MSAA:IAccessible2::get_uniqueID() a few years back and then we switched to DOM methodology (https://developer.mozilla.org/en-US/docs/Web/Accessibility/AT-APIs/ImplementationFeatures/MSAA#Additional_DOM_Support ). Since DOM support is broken from FF49 (https://bugzilla.mozilla.org/show_bug.cgi?id=1310166) we thought of going back to  MSAA. 

Basically, we are totally stuck since both (MSAA and DOM) the accessibility mechanisms are broken. If you can provide a rough estimate for providing a fix for this issue, it would be helpful.
Jamie any thoughts here? Is this causing unnecessary churn?
Flags: needinfo?(jamie)
It doesn't really cause any problems in terms of a user trying to switch tabs from the keyboard, which is the major use case for NVDA users. However, it's definitely not ideal; e.g. it breaks things if the user wants to lock their review cursor on the tab strip for some reason while they switch tabs. I also notice the accessible for a tab gets recreated when you mouse over it.
Flags: needinfo?(jamie)
Do we have an update on when this issue will get resolved?

This was fixed by bug 686400.

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Depends on: 686400
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.