78390 - Active Accessibility: support not working with Acrobat plugin

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect, P1)

Description

[lmcquarr]

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

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, [e-mail]


See http://access.adobe.com 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. 
http://access.adobe.com/browser/cookbook.pdf
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.

Comment 1

[timeless]

=>plugins?

Comment 2

[Aaron Leventhal]

I'll take this

Comment 3

[Aaron Leventhal]

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.

Comment 4

[Loretta Guarino Reid]

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.
[e-mail]

Comment 5

[Aaron Leventhal]

I had a pdf file on my hard drive, which I referenced in the URL bar with
c:\aaron\docs\document.pdf

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

[Loretta Guarino Reid]

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
document? 

Comment 7

[Aaron Leventhal]

Ah! I found the document content.

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

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

Comment 8

[Loretta Guarino Reid]

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

[Loretta Guarino Reid]

I tested the status of accessibility support for the Acrobat plugin in Mozilla, 
Build ID 2001080103. I loaded the PDF file at 
  http://www.adobe/com/products/acrobat/pdfx/accessbooklet.pdf

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
    > NAMELESS
    > Mozilla {Build ID: 2001080103}, role client, 2 children
      > unnamed, role window, 7 children
        > unnamed, role pane, 2 children, value 
chrome://navigator/content/navigator.xul
           > text node "Enter search term, keyword, or web address"
           > unnamed, role pane, 1 child, value 
chrome://communicator/content/sidebar/PageNotFound.xul
             > 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.

Comment 10

[saari (gone)]

-> 0.9.6

Comment 11

[saari (gone)]

-> 0.9.6

Comment 12

[Aaron Leventhal]

This is a tough one - if anyone has some ideas please let me know.

Comment 13

[Chak Nanga]

plusing. ADT/Emeddinig triage.

Comment 14

[Aaron Leventhal]

-> John Gaunt

Comment 15

[John Gaunt (redfive)]

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

[Loretta Guarino Reid]

John,
  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.
Loretta

Comment 17

[Aaron Leventhal]

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

[Loretta Guarino Reid]

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.

Comment 19

[John Gaunt (redfive)]

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

[John Gaunt (redfive)]

Loretta, 

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

[John Gaunt (redfive)]

Attachment: First cut patch - some issues to resolve

Comment 22

[John Gaunt (redfive)]

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

[John Gaunt (redfive)]

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.

Comment 24

[John Gaunt (redfive)]

Attachment: working patch

Walking into and out of the PDF IAccessible works. Yay!

Comment 25

[John Gaunt (redfive)]

aaronl, peterl can you review this?

Comment 26

[Aaron Leventhal]

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

[John Gaunt (redfive)]

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

[Loretta Guarino Reid]

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

[Aaron Leventhal]

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

[Loretta Guarino Reid]

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

Comment 31

[Aaron Leventhal]

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

See
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msaa/msaaccrf_8otw.asp

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

Comment 32

[John Gaunt (redfive)]

Attachment: latest patch, checking the linux/gmake on win builds

Comment 33

[Aaron Leventhal]

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

r=aaronl

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.

Comment 34

[John Gaunt (redfive)]

Attachment: Last patch with fixed makefile foo for Linux and gmake win

Comment 35

[John Gaunt (redfive)]

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 )

Comment 36

[Peter Lubczynski]

r=peterl

Comment 37

[John Gaunt (redfive)]

Attachment: mac project file changes

I'll just roll this in without posting a new patch unless sr requires

Comment 38

[Johnny Stenback (:jst)]

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>
contentDocShell(do_QueryInterface(contentShell));

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

...
+		     if (contentViewer) {
+		       nsCOMPtr<nsIPluginViewer> pluginViewer
(do_QueryInterface(contentViewer));

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

- In mozilla/modules/plugin/base/src/Makefile.in

		nsIPluginInstanceOwner.h \
+    nsPluginViewer.h \
		$(NULL)

Use tabs in Makefile.in's, they're significant.

sr=jst if you fix the above.

Comment 39

[timeless]

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

Comment 40

[John Gaunt (redfive)]

Attachment: 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

[John Gaunt (redfive)]

checked in to trunk

Comment 42

[shrirang khanzode]

Liz, could you please verify this one for me, Thanks !!

Comment 43

[Loretta Guarino Reid]

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

[Aaron Leventhal]

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

[Marek Z. Jeziorek]

batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html

Comment 46

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1527381