Closed Bug 294834 Opened 19 years ago Closed 19 years ago

Expose the type of HTML content area in the role

Categories

(Core :: Disability Access APIs, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: aaronlev, Assigned: aaronlev)

Details

(Keywords: access)

Attachments

(1 file, 2 obsolete files)

There are essentially different kinds of areas we care about:
browser
frame
iframe
document
application
dialog
When we have subdocuments we use 2 objects, an inner and an outer object.
The outor or parent object is the <browser>, <frame>, <iframe>, <editor> etc.
-- and we're now going to expose exactly what the outer object's tag is, but
not allow the role on that one.

The role attribute will be allow on the inner or child object which is the root
object for the sub document.
Attachment #184068 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #184068 - Flags: review?(timeless)
Attachment #184068 - Attachment is obsolete: true
Attachment #184068 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #184068 - Flags: review?(timeless)
(In reply to comment #2)
>1) Expose the container tag (browser/frame/iframe/editor) for outer doc
>accessibles and 2) Expose role attribute for inner document element
a) I'm sure you're doing 1) but I just can't follow the code to see where
b) The change from nsCOMPtr to nsIContent* is safe in this case, I hope?
(In reply to comment #3)
> (In reply to comment #2)
> >1) Expose the container tag (browser/frame/iframe/editor) for outer doc
> >accessibles and 2) Expose role attribute for inner document element
> a) I'm sure you're doing 1) but I just can't follow the code to see where
In get_accRole() we now fall into the using the string role via the tag or role
attribute for role == ROLE_CLIENT, which we only used to do if role ==
ROLE_NOTHING. The ROLE_CLIENT is the nsOuterDocAccessible role which is created
for frame/iframe/browser/editor objects. 
> b) The change from nsCOMPtr to nsIContent* is safe in this case, I hope?
I notice a lot of nsIContent getters, such as nsIContent::GetParent() just
return a plain pointer. The content node is not going away during its use in
this method, so why addref?

Attachment #184072 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #184072 - Flags: review?(timeless)
Attachment #184072 - Flags: superreview-
Attachment #184072 - Flags: review-
Attachment #184072 - Attachment is obsolete: true
Attachment #184345 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #184345 - Flags: review?(timeless)
Attachment #184345 - Flags: superreview?(neil.parkwaycc.co.uk) → superreview+
Comment on attachment 184345 [details] [diff] [review]
Enforce rule that root object in window must be application, document or dialog. We don't want someone saying that a document is a checkbox, for example.

>Index: accessible/src/base/nsAccessible.cpp
>===================================================================
>RCS file: /cvsroot/mozilla/accessible/src/base/nsAccessible.cpp,v
>retrieving revision 1.147
>diff -p -u -3 -r1.147 nsAccessible.cpp
>--- accessible/src/base/nsAccessible.cpp	6 May 2005 15:31:46 -0000	1.147
>+++ accessible/src/base/nsAccessible.cpp	23 May 2005 19:53:48 -0000
>@@ -280,6 +281,48 @@ NS_IMETHODIMP nsAccessible::Init()
>+nsIContent *nsAccessible::GetRoleContent(nsIDOMNode *aDOMNode)

I'm a little concerned about the nsCOMPtr usage here. Shouldn't you just return
an already addref'd pointer from this method?

>+  // Given the DOM node for an acessible, return content node that
>+  // we should look at role string from

Nit: accessible is misspelled, and comment is confusing.
Attachment #184345 - Flags: review?(timeless) → review+
Comment on attachment 184345 [details] [diff] [review]
Enforce rule that root object in window must be application, document or dialog. We don't want someone saying that a document is a checkbox, for example.

I'll fix the comment, but the lack of already_AddRefed is ok just as it is for
other nsIContent* getters.
Attachment #184345 - Flags: approval1.8b3?
Comment on attachment 184345 [details] [diff] [review]
Enforce rule that root object in window must be application, document or dialog. We don't want someone saying that a document is a checkbox, for example.

a=shaver
Attachment #184345 - Flags: approval1.8b3? → approval1.8b3+
Checking in src/base/nsAccessibilityAtomList.h;
/cvsroot/mozilla/accessible/src/base/nsAccessibilityAtomList.h,v  <-- 
nsAccessibilityAtomList.h
new revision: 1.19; previous revision: 1.18
done
Checking in src/base/nsAccessibilityService.cpp;
/cvsroot/mozilla/accessible/src/base/nsAccessibilityService.cpp,v  <-- 
nsAccessibilityService.cpp
new revision: 1.141; previous revision: 1.140
done
Checking in src/base/nsAccessible.cpp;
/cvsroot/mozilla/accessible/src/base/nsAccessible.cpp,v  <--  nsAccessible.cpp
new revision: 1.148; previous revision: 1.147
done
Checking in src/base/nsAccessible.h;
/cvsroot/mozilla/accessible/src/base/nsAccessible.h,v  <--  nsAccessible.h
new revision: 1.62; previous revision: 1.61
done
Checking in src/base/nsDocAccessible.cpp;
/cvsroot/mozilla/accessible/src/base/nsDocAccessible.cpp,v  <--  nsDocAccessible.cpp
new revision: 1.60; previous revision: 1.59
done
Checking in src/base/nsRootAccessible.cpp;
/cvsroot/mozilla/accessible/src/base/nsRootAccessible.cpp,v  <-- 
nsRootAccessible.cpp
new revision: 1.117; previous revision: 1.116
done
Checking in src/msaa/nsAccessibleWrap.cpp;
/cvsroot/mozilla/accessible/src/msaa/nsAccessibleWrap.cpp,v  <-- 
nsAccessibleWrap.cpp
new revision: 1.27; previous revision: 1.26
done
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: