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)
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
Assignee | ||
Comment 1•19 years ago
|
||
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)
Assignee | ||
Updated•19 years ago
|
Attachment #184068 -
Attachment is obsolete: true
Attachment #184068 -
Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #184068 -
Flags: review?(timeless)
Assignee | ||
Comment 2•19 years ago
|
||
Attachment #184072 -
Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #184072 -
Flags: review?(timeless)
Comment 3•19 years ago
|
||
(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?
Assignee | ||
Comment 4•19 years ago
|
||
(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?
Assignee | ||
Updated•19 years ago
|
Attachment #184072 -
Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #184072 -
Flags: review?(timeless)
Assignee | ||
Updated•19 years ago
|
Attachment #184072 -
Flags: superreview-
Attachment #184072 -
Flags: review-
Assignee | ||
Comment 5•19 years ago
|
||
Neil, your questions are addressed in my comment #4.
Assignee | ||
Updated•19 years ago
|
Attachment #184072 -
Attachment is obsolete: true
Attachment #184345 -
Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #184345 -
Flags: review?(timeless)
Updated•19 years ago
|
Attachment #184345 -
Flags: superreview?(neil.parkwaycc.co.uk) → superreview+
Comment 6•19 years ago
|
||
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+
Assignee | ||
Comment 7•19 years ago
|
||
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+
Assignee | ||
Comment 9•19 years ago
|
||
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.
Description
•