Active Accessibility: support not working with Acrobat plugin

RESOLVED FIXED in mozilla1.0



17 years ago
14 years ago


(Reporter: lmcquarr, Assigned: John Gaunt (redfive))


({access, sec508, topembed})

Windows 2000
access, sec508, topembed
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




(3 attachments, 3 obsolete attachments)



17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/4.73 [en] (Windows NT 5.0; U)

We understand that important feature that is being worked on
in mozilla is the accessibility of the browser for those with
disabilities, especially those who are visually impaired.

One main feature of our latest release of Adobe Acrobat
is accessibility.  A lot of work was done for Acrobat
5 was to make it accessible, including inside the browser.
Frankly, the only game in town at that time in terms
of browser accessibility was Internet Explorer, so that
is where we focused our development efforts.  

Now that the mozilla team is looking at mozilla accessibility,
we would like to work with you to ensure that Acrobat is
accessible in mozilla.  

The contact person in Acrobat
Engineering is Loretta Guarino Reid,

See for more details on the Acrobat
accessibility efforts.

Reproducible: Always
Steps to Reproduce:
1.Start any screen reading program on Windows 2000, e.g. JAWS. 
2.Install Adobe Acrobat 5 and mozilla.
3.Drop the nppdf32.dll plug-in from the Acrobat install directory
into the mozilla plug-ins directory.
4.Browse to any PDF file on the web, e.g.
5.Attempt to read the PDF document using the screen reader.

Then, compare what happens when you use IE to browse to the same
document (you don't have to move a plug-in to IE). 

Actual Results:  The screen reader is unable to read the Acrobat PDF document. 

Expected Results:  The screen reader can read the Acrobat PDF document. 

If you are just starting your efforts to make mozilla accessible,
it is possible that the folks here can give you a leg up.


17 years ago
Keywords: acrobat

Comment 1

17 years ago
Assignee: asa → av
Component: Browser-General → Plug-ins
Ever confirmed: true
Keywords: access
QA Contact: doronr → shrir

Comment 2

17 years ago
I'll take this
Assignee: av → aaronl
Severity: normal → major
Keywords: fcc508
Priority: -- → P1
Target Milestone: --- → mozilla0.9.3


17 years ago


17 years ago
Target Milestone: mozilla0.9.3 → mozilla0.9.4

Comment 3

17 years ago
Status report:

I tried the new Adobe 5.0 plugin with accessibility enabled (don't ask me why
they don't include it with the normal download).

With IE, the MSAA Accessible Explorer reports objects for most of the user
interface elements, but it does not report anything for the actual document
content. How is the screen reader supposed to get at that information?

With Netscape, we must be hogging the MSAA messages and not passing them to the
next application. I'll have to look into how we can fix that.
Summary: Accessibility for the Visually Impaired and Adobe Acrobat → Active Accessibility support not working with Acrobat plugin

Comment 4

17 years ago
What test file did you use when examining the MSAA tree under IE? We still have
problems with IE if the PDF is in a frame within an html page. Otherwise, I can
show you where the PDF content should be in the MSAA tree for Acrobat.

Comment 5

17 years ago
I had a pdf file on my hard drive, which I referenced in the URL bar with

I also had problems accessing the document in the reader itself.

I get "Alert - protection failure"
This document's settings prevent access.

So, let me get this straight - as I sighted person I'm allowed to read this
document, but a blind person is not allowed?

Comment 6

17 years ago
Yes, when the protections are set "the wrong way", the document is inaccessible.
For a document that uses 40-bit encryption, if copying the text and graphics is
prohibited, we can't send the data out through the MSAA interface. For a
document that uses 128-bit encryption, there is a separate bit that controls
whether the data can go out over MSAA. Can you fix the security settings on your

Comment 7

17 years ago
Ah! I found the document content.

Okay, looks like we have some work to do on our end to make sure your MSAA gets

What screen readers so far work with the MSAA Acrobate generates?

Comment 8

17 years ago
WindowEyes 4.1 and JAWS, although we are still working through some bugs with
JAWS. The public beta of JAWS 3.71 works pretty well.

Comment 9

17 years ago
I tested the status of accessibility support for the Acrobat plugin in Mozilla, 
Build ID 2001080103. I loaded the PDF file at 

then I ran AccExplorer to look at the resulting tree. I suspect an error is 
occuring when AccExplorer tries to access the plugin window. What I see in 
AccExplorer is:
  > Mozilla {Build ID: 2001080103}, role window, 7 children
    > Mozilla {Build ID: 2001080103}, role client, 2 children
      > unnamed, role window, 7 children
        > unnamed, role pane, 2 children, value 
           > text node "Enter search term, keyword, or web address"
           > unnamed, role pane, 1 child, value 
             > text node "This tab is not available right now"
So "unname, role window, 7 children" only displays 1 child. This usually 
indicates that errors occured in trying to process the second child, causing
the rest of the tree walk to abort.


17 years ago
Target Milestone: mozilla0.9.4 → mozilla0.9.5

Comment 10

16 years ago
-> 0.9.6

Comment 11

16 years ago
-> 0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6


16 years ago
Target Milestone: mozilla0.9.6 → mozilla0.9.7


16 years ago
Summary: Active Accessibility support not working with Acrobat plugin → Active Accessibility: support not working with Acrobat plugin


16 years ago
Target Milestone: mozilla0.9.7 → Future

Comment 12

16 years ago
This is a tough one - if anyone has some ideas please let me know.
Target Milestone: Future → mozilla1.0


16 years ago
Keywords: nsbeta1


16 years ago
Depends on: 124448

Comment 13

16 years ago
plusing. ADT/Emeddinig triage.
Keywords: nsbeta1 → nsbeta1+

Comment 14

16 years ago
-> John Gaunt
Assignee: aaronl → jgaunt

Comment 15

16 years ago
Some initial thoughts:
  there are a couple ways to tackle this. since we are going to receive the call
from the msaa library to get the information about the acrobat stuff we can 1)
act as a proxy, receiving the call and asking the plugin for the info we need
and passing it back 2) when we get a call for the acrobat  info we may be able
to return a handle to the acrobat's COM interface ( I'm assuming acrobat has a
COM interface much like we have for interfacing with the MSAA library ) and let
the MSAA library ask it directly 3) well, I guess there are just 2 options. :-)

lguarino: how do you interact with IE? I'm looking at our plugin apis (
specifically nsIPluginInstancePeer and nsIPluginInstance ) looking at how I can
get ahold of your object and querying it for information. Do you use one of the
two approaches above or something different I haven't considered?

Comment 16

16 years ago
  With IE, the Acrobat window tree is attached to IE's window tree; I think 
the screen readers are able to use standard MSAA support to descend 
from the IE window into Acrobat's tree, that is, if they query for children on 
the window in IE where we attach Acrobat's window, they can descend 
into our MSAA subtree.
  What took more work with IE was handling moving focus between the
applications. We were able to monitor focus notifications on our window 
in IE, and pass them on to Acrobat explicitly. Similarly, when Acrobat 
wanted to return focus to the browser, we sent a message back to our 
plug-in code and assigned focus to the IE window.
  Let me know if you want to discuss this on the phone.

Comment 17

16 years ago
John, Acrobat doesn't support AccessibleObjectFromPoint(). However, it is
possible to see Acrobat's MSAA tree using Accessible Explorer, and searching for
a node with a certain name. Loretta, can you remind us what that name was?

AccessibleObjectFromWindow(), AccessibleObjectFromPoint() and
AccessibleObjectFromEvent() work in two parts: 1) use the WM_GETOBJECT message
to get the root IAccessible from a window, and then 2) use that root IAccessible
to go from there, with a specific method call such as accHitTest(long xLeft,
long yTop, VARIANT __RPC_FAR *pvarChild) or get_accChild(VARIANT varChild,
IDispatch __RPC_FAR *__RPC_FAR *ppdispChild)

In the case of an embedded PDF object (or any other special <object> window>, I
think we should be able to see some "outer" container object that Mozilla houses
the content in. It should know how to walk into that by again using
AccessibleObjectFromWindow() or AccessibleObjectFromPoint() all over again.

Comment 18

16 years ago
To find the content of the PDF file in the Acrobat MSAA tree, find the first
object named AVScrollView. It will contain a child named AVScrollView, which
will contain a number of children. The first child will be NAMELESS, and that is
the start of the PDF content subtree. However, anytime you start seeing object
with names that start with AV, you are within Acrobat's MSAA subtree.

I should look into why AVAccessibleFromPoint isn't working properly; it is
probably due to sloppy implementations of AVHitTest.


16 years ago
Severity: major → blocker
Keywords: topembed


16 years ago
Blocks: 75785


16 years ago
Keywords: topembed → topembed+


16 years ago
Blocks: 135206

Comment 19

16 years ago
Intersting, I just brought up a pdf file in our mfcembed test program and we get
into the pdf content just fine. :-) Althought the navigation seems a bit weird (
lots of AVScrollView windows ) and I couldn't actually navigate into the
document, and I couldn't get an object from point either.

This is good, because I think I have a way to get it working in the main browser
I just have to make sure I don't break the support in the embedded side. The
plan is to use the XUL TabPanel to look for a window or content or something
special when there is no children ( the case when there is a full page plugin ).
This _should_ enable us to get to the IAccessible from the plugin. 

I better check and figure out how we are allowing event through for the embedded
case too. :-) Best to know why it is working.

Comment 20

16 years ago

I'm looking at the windows present for a pdf file in two cases. When the PDF
file is linked to directly I see a whole bunch of AV windows starting with an
AmberExternalWindow. From the first AVScrollView window I see the first child
being nameless and being a scrollbar. From your comment above I thought the
first nameless child was going to be the document root, but it would seem that
the AVScrollView window is the document root and it's first child is the first
part of the content. Am I understanding this correctly? If I try and get an
accessible from the AVScrollView window ( using AccessibleObjectFromWindow() )
will that get us into your content accessibility tree?

The second case I am looking at is when a pdf file is referenced in an object
tag. In this case the pdf isn't loaded full screen but only given a portion of
the screen. I don't get any functionality of the pdf viewer. Instead I get the
first page of the document. No toolbar, no ability to navigate the document. It
seems to me the pdf viewer is not supposed to be used in this manner. Is this
correct? I do get the AmberExternalWindow in this case, but it has no children.
This is with respect to bug 124448.

Comment 21

16 years ago
Created attachment 84655 [details] [diff] [review]
First cut patch - some issues to resolve

Comment 22

16 years ago
I'm going to re-test this functionality with MFCembed. Last time I tested I
remember it working just fine. I think this bug has to do specifically with the
full client. Of course, specific embeddors may run into the same problems we do
with the client, but that will have to be dealt with one-off most likely.

Comment 23

16 years ago
removing topembed+ and nsbeta1+ since this bug deals only with the client,
MFCEmbed is working fine with pdf files, and this bug isn't a candidate for the
next netscape release.
Keywords: nsbeta1+, topembed+

Comment 24

16 years ago
Created attachment 84830 [details] [diff] [review]
working patch

Walking into and out of the PDF IAccessible works. Yay!
Attachment #84655 - Attachment is obsolete: true

Comment 25

16 years ago
aaronl, peterl can you review this?

Comment 26

16 years ago
The biggest thing I see, is that the tabpanelaccessible is not the right place
for this. it should be at the level of <browser>. In browser.xml, I see that we
call createIFrameAccessible. I believe that <tabbrowser> contains <browser> in
the anon content.

This line is superfluous, and the naming convention is wrong.
nsIWebShell *Shell ;
Not sure why it's there - looks like a mistake, you arleady have nsIWebShell
*webShell on the next line.

+  nsAccessible::GetAccLastChild(_retval);
+  if (*_retval == nsnull)
+    GetAccPluginChild(_retval);
+  return NS_OK;
perhaps should be 
+  nsresult rv = nsAccessible::GetAccLastChild(_retval);
+  if (*_retval == nsnull)
+    rv = GetAccPluginChild(_retval);
+  return rv;
for both GetAccFirstChild and GetAccLastChild

Comment 27

16 years ago
uh, nevermind on the reviews. Just realized this doesn't work when you have a
frameset. I've based this in the wrong area in the accessible code. have to move it.

Comment 28

16 years ago
I installed today's build (Build ID: 2002052408) and loaded a local PDF file
using "Open File...". It display fine. Then I ran AccExplorer to see what sort
of accessibility tree is exposed. AccExplorer isn't able to see any of the
Acrobat subtree from the Mozilla root. I can get to a MozillaWindowClass window
that covers the plug-in area; it has 2 children. The first is a PropertyPage
with the same coordinates as its parent window. The second looks like most of
its MSAA calls must have failed. 

Comment 29

16 years ago
Loretta, John hasn't checked this in yet. He has a working patch. You would have
to download the source, apply the patch and build in order to test it. He'll be
back from vacation June 9, so he should be able to get it reviewed and checked
in shortly thereafter.

Comment 30

16 years ago
Thanks, Aaron. I'll wait for his return to test this support.

Comment 31

16 years ago
I was looking at the latest MSAA docs on MSDN.
I noticed that there are some interesting functions that might be helpful here:
CreateStdAccessibleProxy and CreateStdAccessibleObject


John, do you think we should be using this? It looks right on.

Comment 32

16 years ago
Created attachment 89423 [details] [diff] [review]
latest patch, checking the linux/gmake on win builds
Attachment #84830 - Attachment is obsolete: true

Comment 33

16 years ago
Comment on attachment 89423 [details] [diff] [review]
latest patch, checking the linux/gmake on win builds


It looks like you need to go back and check the spacing/tabbing of the lines
you added to the various makefiles you're touching, to make it consistent with
the rest of the file.
Attachment #89423 - Flags: review+

Comment 34

16 years ago
Created attachment 89567 [details] [diff] [review]
Last patch with fixed makefile foo for Linux and gmake win
Attachment #89423 - Attachment is obsolete: true

Comment 35

16 years ago
Comment on attachment 89567 [details] [diff] [review]
Last patch with fixed makefile foo for Linux and gmake win

carrying forward aaron's r=

ready for sr=

( sanity building on mac just to be sure )
Attachment #89567 - Flags: review+

Comment 36

16 years ago

Comment 37

16 years ago
Created attachment 89628 [details] [diff] [review]
mac project file changes

I'll just roll this in without posting a new patch unless sr requires
Comment on attachment 89567 [details] [diff] [review]
Last patch with fixed makefile foo for Linux and gmake win

- In nsXULTabPanelsAccessible::GetAccPluginChild():

+  if (domDoc) {
+    nsCOMPtr<nsIDocument> doc(do_QueryInterface(domDoc));

The above |if (domDoc)| check is not needed, do_QueryInterface() is null safe.

+	 if (docShell) {
+	   nsCOMPtr<nsIWebShell> webShell(do_QueryInterface(docShell));

The above |if (docShell)| is not needed, same reason.

+	     if (container) {
+	       nsCOMPtr<nsIWebShellWindow> wsWin(do_QueryInterface(container));

Same here, no need for the |if (container)|

+		 if (contentShell){
+		   nsCOMPtr<nsIDocShell>

No need for the |if (contentShell)|...

+		     if (contentViewer) {
+		       nsCOMPtr<nsIPluginViewer> pluginViewer

Same here, no need for |if (contentViewer)|...

- In mozilla/modules/plugin/base/src/

		nsIPluginInstanceOwner.h \
+    nsPluginViewer.h \

Use tabs in's, they're significant.

sr=jst if you fix the above.
Attachment #89567 - Flags: superreview+

Comment 39

16 years ago
tabs can be significant in makefiles, but they are not in this case because of 
the \ line continuation character.

Comment 40

16 years ago
Created attachment 89944 [details] [diff] [review]
removed the useless if()s and included the mac project files 

opted to leave the spaces in the makefiles alone since it matches the rest of
the file.

Comment 41

16 years ago
checked in to trunk
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 42

16 years ago
Liz, could you please verify this one for me, Thanks !!
QA Contact: shrir → lmcquarr

Comment 43

16 years ago
This looks good; using AccExplorer, I can see the Acrobat subtree within the
Mozilla IAccessible tree, including the contents of the document. Is there a
(Mozilla + Acrobat aware) screen reader that I could test with, to see whether
the screen reader can read the content in the browser?

Comment 44

16 years ago
Loretta, we're still working on getting a Gecko-aware screen reader, period :\
Once we do, we're definitely work with you on PDF support.

Comment 45

15 years ago
batch: adding topembed per Gecko2 document
Keywords: topembed


15 years ago
Blocks: 176349
You need to log in before you can comment on or make changes to this bug.