Closed
Bug 440770
Opened 16 years ago
Closed 16 years ago
DOCUMENT_FRAME has a parent INTERNAL_FRAME with an action
Categories
(Core :: Disability Access APIs, defect)
Core
Disability Access APIs
Tracking
()
VERIFIED
FIXED
mozilla1.9.1a1
People
(Reporter: steve, Assigned: MarcoZ)
References
Details
(Keywords: fixed1.9.0.2)
Attachments
(1 file)
1.58 KB,
patch
|
aaronlev
:
review+
samuel.sidler+old
:
approval1.9.0.2+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9) Gecko/2008061015 Firefox/3.0 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9) Gecko/2008061015 Firefox/3.0 The INTERNAL_FRAME parent of the DOCUMENT_FRAME has a action of click that seems spurious. Is it supposed to do anything? It confuses Jambu which only expects actions on leaf (non-container) nodes and so does not navigate down into it. Is this a bad assumption to make? Reproducible: Always Steps to Reproduce: 1.look in accerciser at INTERNAL_FRAME 0 18 30 0 2. 3. Actual Results: Internal frame has an action Expected Results: no action
Comment 1•16 years ago
|
||
To answer your questions, yes & no. I think it's a bad assumption that actions will be on leaf elements, since any HTML element can have an onclick and the other may use that for something important. For example, imagine a diagram where each diagram object has descendants, but clicking on the object makes it the center of the diagram. That said, the INTERNAL FRAME might in fact be a weird place to have the action, but I'd like more details. Is this for any web page?
(In reply to comment #1) > To answer your questions, yes & no. > I think it's a bad assumption that actions will be on leaf elements, since any > HTML element can have an onclick and the other may use that for something > important. For example, imagine a diagram where each diagram object has > descendants, but clicking on the object makes it the center of the diagram. Yes I considered that general case but after investigation of the cases could find I to a pragmatic view that simplifies the UI as it allows a single gesture do either enter collection (parent) or do action (leaf). It might well be that we need to allow different actions for a node but for now this seems to be enough. You give a plausible scenario there though. > That said, the INTERNAL FRAME might in fact be a weird place to have the > action, Agreed. > but I'd like more details. Is this for any web page? Yes as far as I can tell
Assignee | ||
Updated•16 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
Version: unspecified → Trunk
Assignee | ||
Comment 3•16 years ago
|
||
Override action-related method in nsOuterDocAccessible so no actions are exposed for the internal frame.
Assignee: nobody → marco.zehe
Status: NEW → ASSIGNED
Attachment #326453 -
Flags: review?(aaronleventhal)
Comment 4•16 years ago
|
||
Comment on attachment 326453 [details] [diff] [review] Remove any actions from nsOuterDocAccessible Curious, why is there an onclick there at all? If it's hard to answer, no problem. This is a reasonable fix in any case, since I can't imagine any time where we'd want to expose an action there. Nit: I think the new GetActionDescription should just truncate instead of deferring to GetActionName().
Attachment #326453 -
Flags: review?(aaronleventhal) → review+
Assignee | ||
Comment 5•16 years ago
|
||
(In reply to comment #4) > Curious, why is there an onclick there at all? If it's hard to answer, no > problem. nsAccUtils::hasListener determines that there aparently is an onclick handler for this content node. > Nit: I think the new GetActionDescription should just truncate instead of > deferring to GetActionName(). Fixed, thanks!
Assignee | ||
Comment 6•16 years ago
|
||
Adding Mochitest for this in bug 441519. Flagging for intestsuite.
Flags: in-testsuite?
Assignee | ||
Comment 7•16 years ago
|
||
Pushed in changeset: http://hg.mozilla.org/mozilla-central/index.cgi/rev/0c8e64474660
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Comment 8•16 years ago
|
||
Comment on attachment 326453 [details] [diff] [review] Remove any actions from nsOuterDocAccessible >+NS_IMETHODIMP >+nsOuterDocAccessible::GetActionDescription(PRUint8 aIndex, nsAString& aDescription) >+{ >+ // default to same as action name. >+ return GetActionName(aIndex, aDescription); >+} it doesn't make sense to override this method.
Assignee | ||
Comment 9•16 years ago
|
||
Test in fix for bug 441519, test_nsOuterDocAccessible.html.
Flags: in-testsuite? → in-testsuite+
Assignee | ||
Comment 10•16 years ago
|
||
Verified fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008062603 Minefield/3.1a1pre
Status: RESOLVED → VERIFIED
Assignee | ||
Updated•16 years ago
|
Target Milestone: --- → mozilla1.9.1a1
Assignee | ||
Comment 11•16 years ago
|
||
Comment on attachment 326453 [details] [diff] [review] Remove any actions from nsOuterDocAccessible Has test, has been baking on 1.9.1a1 for weeks, and would help the Jambu (alternative input device software on Linux) developers tremendously in properly navigating and identifying clickable items.
Attachment #326453 -
Flags: approval1.9.0.2?
Comment 12•16 years ago
|
||
Comment on attachment 326453 [details] [diff] [review] Remove any actions from nsOuterDocAccessible Approved for 1.9.0.2. Please land in CVS. a=ss. Also, be sure to land the test from bug 441519 when you land this.
Attachment #326453 -
Flags: approval1.9.0.2? → approval1.9.0.2+
Assignee | ||
Comment 13•16 years ago
|
||
Checking in accessible/src/base/nsOuterDocAccessible.cpp; /cvsroot/mozilla/accessible/src/base/nsOuterDocAccessible.cpp,v <-- nsOuterDocAccessible.cpp new revision: 1.41; previous revision: 1.40 done Checking in accessible/src/base/nsOuterDocAccessible.h; /cvsroot/mozilla/accessible/src/base/nsOuterDocAccessible.h,v <-- nsOuterDocAccessible.h new revision: 1.18; previous revision: 1.17 done
Keywords: fixed1.9.0.2
You need to log in
before you can comment on or make changes to this bug.
Description
•