Closed Bug 444279 Opened 12 years ago Closed 12 years ago

mochitest for accessible name calculating

Categories

(Core :: Disability Access APIs, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla1.9.1a1

People

(Reporter: surkov, Assigned: surkov)

References

Details

Attachments

(1 file, 3 obsolete files)

mainly I want to put tests for bug 436453.

1) nsresult nsAccessible::GetXULName

// Can get text from title of <toolbaritem> if we're a child of a <toolbaritem>
nsIContent *bindingParent = content->GetBindingParent();
// XXXldb: Why do we skip to bindingParent's parent?
nsIContent *parent = bindingParent? bindingParent->GetParent() :
                                                                   content->GetParent();

This part of code has been introduced in bug 237249. I was impressed but browser.xul really uses @title attribute on toolbaritem. Though it's not documented. I'll put tests for this.

2) nsAccUtils::FindNeighbourPointingToNode

- if (binding == aForNode)
+ if (aForNode->IsNativeAnonymous()) // XXX Was this the intent?

need to add test for this to ensure it's equivalent things
Attached patch wip (obsolete) — Splinter Review
test for names calculated from title attribute of toolbaritem
(In reply to comment #0)

> This part of code has been introduced in bug 237249. I was impressed but
> browser.xul really uses @title attribute on toolbaritem. Though it's not
> documented. I'll put tests for this.

I can't figure what @title attribute on xul:toolbaritem is supposed to do. This attribute has been introduced by Joe Hewitt in http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/browser/base/content/browser.xul&rev=1.68. There is no link on bug. So I can't get the reason. 

Neil and Enn, do you have any idea?

Marco, please look at mochitest. There you will find usecases how we @title of toolbaritem. Do we really need there to grab the name from @title of titlebar? Can we use some technique to avoid this?
(In reply to comment #2)
> I can't figure what @title attribute on xul:toolbaritem is supposed to do.
My understanding is that it's displayed when customising the toolbar.
(In reply to comment #3)
> (In reply to comment #2)
> > I can't figure what @title attribute on xul:toolbaritem is supposed to do.
> My understanding is that it's displayed when customising the toolbar.
> 

Ah, ok. So that's the thing that is used in customize toolbar dialog. We rely on it when we are calculating accessible name for children of toolbaritem. So that's a pure hack for firefox and we hardcode it into accessibility code. So either we shouldn't use @title in accessibility (and remove its support from ally) or we should legalize its usage from point of view of accessibility and place this information on devmo XUL references. What do you think?
I was under the impression that tooltiptext should be used as the accName for a11y for toolbar items. Am I wrong?
(In reply to comment #5)
> I was under the impression that tooltiptext should be used as the accName for
> a11y for toolbar items. Am I wrong?
> 

It's not a tooltip text. It's title attribute. That is used by browser implementation (for customize toolbar dialog) and by accessibility to form accessible name for children of toolbaritem.
Attached patch wip2 (obsolete) — Splinter Review
+html test (aria_labelledby and name from subtree)
Attachment #328627 - Attachment is obsolete: true
Attached patch patch (obsolete) — Splinter Review
wild toolbaritem stuffs + html name calculation in general case (logic of nsAccessible)

Let's start Marco.
Attachment #328878 - Attachment is obsolete: true
Attachment #328890 - Flags: review?(marco.zehe)
Comment on attachment 328890 [details] [diff] [review]
patch

>+  <!-- label element, label is outside of the form of the button -->
>+  <label for="btn_label_indocument">in document</label>
>+  <button id="btn_label_indocument">13</button>

You mean the label and button are not within a form, don't you? Please adjust this comment. You've commented correctly in the JavaScript section on this. ;-)
Do you plan to also add other wild XUL stuff like we have in some of the Thunderbird XUL files where a radio button is being labelled by a textbox and a label, and the same textbox is also labelled by the radio button, itself, and the label? Or do you want to handle this separately?
(In reply to comment #9)
> (From update of attachment 328890 [details] [diff] [review])
> >+  <!-- label element, label is outside of the form of the button -->
> >+  <label for="btn_label_indocument">in document</label>
> >+  <button id="btn_label_indocument">13</button>
> 
> You mean the label and button are not within a form, don't you? Please adjust
> this comment. You've commented correctly in the JavaScript section on this. ;-)

thank you :)

> Do you plan to also add other wild XUL stuff like we have in some of the
> Thunderbird XUL files where a radio button is being labelled by a textbox and a
> label, and the same textbox is also labelled by the radio button, itself, and
> the label? Or do you want to handle this separately?
> 

I'm not sure. I run through the code and cvs history and write examples. I'll put here the same stuffs like I did for HTML. If we have hardcoded wild thunderbird stuffs into nsAccessible then they will be there ;)
Status: NEW → ASSIGNED
(In reply to comment #10)
> If we have hardcoded wild thunderbird stuffs into nsAccessible then they will
> be there ;)

I was specifically thinking of bug 433895, where referencing the textbox's ID does not only account for its value, but undesirably also preceeds that value with the name it gets from the label's @control attribute.
Attached patch patch2Splinter Review
can't believe I finished :)
Attachment #328890 - Attachment is obsolete: true
Attachment #329072 - Flags: review?(marco.zehe)
Attachment #328890 - Flags: review?(marco.zehe)
Comment on attachment 329072 [details] [diff] [review]
patch2

r=me, with two nits from the XUL file:

>+      // Gets the name from text nodes and selected item of menulist
>+      // (another items are ignored).

Should be "(other items...)"

>+      // The label is on 1th, the button is on 5nd level relative common parent.

"1st" and "5th".

Thanks!
Attachment #329072 - Flags: review?(marco.zehe) → review+
checked in http://hg.mozilla.org/mozilla-central/index.cgi/rev/b6f1af141782
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1a1
You need to log in before you can comment on or make changes to this bug.