Closed Bug 294834 Opened 21 years ago Closed 21 years ago

Expose the type of HTML content area in the role

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: aaronlev, Assigned: aaronlev)

Details

(Keywords: access)

Attachments

(1 file, 2 obsolete files)

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.
7.30 KB, patch
pkwarren
: review+
neil
: superreview+
shaver
: approval1.8b3+
Details | Diff | Splinter Review
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: 21 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: