If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Obtaining the IAccessible interface takes several seconds on Vista

RESOLVED WORKSFORME

Status

()

Core
Disability Access APIs
RESOLVED WORKSFORME
7 years ago
7 years ago

People

(Reporter: Adam Marks, Unassigned)

Tracking

Trunk
x86_64
Windows Vista
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Windows NT 6.0; WOW64; rv:2.0b11) Gecko/20100101 Firefox/4.0b11
Build Identifier: 4.0b11

This behavior is new for beta 11, we did not see it with beta9 and before.  It may have been in beta 10.  We are seeing it on Windows Vista and Windows 7.

We are calling the Win32 api AccessibleObjectFromWindow( hwndOfFirefoxWindow, OBJID_CLIENT, IID_IAccessible, ppIAccRoot )   and it is taking 5-7 seconds per call to obtain the IAccessible*.




Reproducible: Always

Steps to Reproduce:
1. Run a application that requests accessibility information from Firefox
2. Time the application 
Actual Results:  
The application will run slower with Firefox 4.0 than with previous releases.

Expected Results:  
The application will run just as fast with Firefox 4.0.
Thanks Adam, can you please confirm with the latest nightly?
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Comment 2

7 years ago
I cannot rpeproduce this with NVDA or one of the commercial screen readers. Availability is instant, and from the timing of things, I have a feeling with 4.0 stuff works even faster than with 3.6.

Comment 3

7 years ago
If it still occurs with the latest nightly, would you be able to try and find the regression range:
http://harthur.github.com/mozregression/
Version: unspecified → Trunk
(Reporter)

Comment 4

7 years ago
(In reply to comment #2)
> I cannot rpeproduce this with NVDA or one of the commercial screen readers.
> Availability is instant, and from the timing of things, I have a feeling with
> 4.0 stuff works even faster than with 3.6.

Another dev here tried this and we are now thinking the slowdown might be related to one of the config settings we had on:  gfx.font_rendering.directwrite.enabled was set to true  ,  When this is set to false, which I believe is the default,  we don't see a slowdown.
Thanks Adam, there might be another bug here so let's be sure. Can you type about:support in the location bar and report here what it says (for the machine that showed slowness)?

Comment 6

7 years ago
Marco, did you try to reproduce following comment 4?
Target Milestone: --- → mozilla2.0b12

Updated

7 years ago
Target Milestone: mozilla2.0b12 → ---

Comment 7

7 years ago
Not yet, was concentrating on our blockers until now.

Comment 8

7 years ago
This setting gfx.font_rendering.directwrite.enabled to true does not have any impact on NVDA whatsoever. Minefield launches just as fast, pages don't feel slower when loading etc. No, cannot reproduce.

Comment 9

7 years ago
Ok, then we need a help from reporter to get a steps to reproduce.
(Reporter)

Comment 10

7 years ago
We are no longer seeing this issue,  it may have been fixed in Firefox or in our code.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME

Comment 11

7 years ago
(In reply to comment #10)
> We are no longer seeing this issue,  it may have been fixed in Firefox or in
> our code.

Thank you for checking this.
You need to log in before you can comment on or make changes to this bug.