Closed Bug 440770 Opened 12 years ago Closed 12 years ago

DOCUMENT_FRAME has a parent INTERNAL_FRAME with an action

Categories

(Core :: Disability Access APIs, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
mozilla1.9.1a1

People

(Reporter: steve, Assigned: MarcoZ)

References

Details

(Keywords: fixed1.9.0.2)

Attachments

(1 file)

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
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
Version: unspecified → Trunk
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 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+
(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!
Depends on: 441519
Adding Mochitest for this in bug 441519. Flagging for intestsuite.
Flags: in-testsuite?
Pushed in changeset:
http://hg.mozilla.org/mozilla-central/index.cgi/rev/0c8e64474660
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
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.
Test in fix for bug 441519, test_nsOuterDocAccessible.html.
Flags: in-testsuite? → in-testsuite+
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
Target Milestone: --- → mozilla1.9.1a1
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 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+
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.