Closed Bug 907682 Opened 8 years ago Closed 8 years ago

HTML:option group position is not correct when select is collapsed

Categories

(Core :: Disability Access APIs, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla29

People

(Reporter: surkov, Assigned: jwei)

References

(Blocks 1 open bug)

Details

(Keywords: access, regression, Whiteboard: [mentor=surkov.alexander@gmail.com][lang=c++])

Attachments

(1 file, 2 obsolete files)

reported by AT vendor. It should be relatively easy. Guys if you want to pick it up please go ahead.
I want to take this bug.Please provide the information on how to proceed.Thanks!
you need to set break point at Accessible::GroupPosition() and see what happens. To trigger it you can start DOM Inspector (an extension you need to install), switch to the accessible tree, select the HTML option accessible of some HTML select, call JS console from the context menu, type "accessible.groupPosition" and press "execute" button.
Depends on: 2013q4a11y
Blocks: 2013q4a11y
No longer depends on: 2013q4a11y
Hi, anyone working on this bug? I want to work on this. Can you help me?
(In reply to alexander :surkov from comment #2)
> you need to set break point at Accessible::GroupPosition() and see what
> happens. To trigger it you can start DOM Inspector (an extension you need to
> install), switch to the accessible tree, select the HTML option accessible
> of some HTML select, call JS console from the context menu, type
> "accessible.groupPosition" and press "execute" button.

Can you give me a testcase? I couldn't make out this exactly. I tried as surkov said in his comment 2, but nothing happend.
just ordinal HTML select

the problem here is all HTML select option except first one have invisible state what prevents us to calculate group position for it.
Hi !
I'm interested in contributing to mozilla with this bug.Kindly do assign it to me.
(In reply to Darshana Padmadas from comment #6)
> Hi !
> I'm interested in contributing to mozilla with this bug.Kindly do assign it
> to me.

Aveek pls confirm if you work on it
Flags: needinfo?(aveek1)
(In reply to Darshana Padmadas from comment #6)
> Hi !
> I'm interested in contributing to mozilla with this bug.Kindly do assign it
> to me.

are you still interested in it?
Yes.I am still interested in fixing this bug.
Thank you.
Assignee: nobody → darshanapadmadas
Blocks: 956711
Attachment #8356780 - Flags: review?(trev.saunders)
Darshana, since Jonathan has got a patch then it makes sense to change an assignee. Please let me know if you still want some bug to work on.
Flags: needinfo?(aveek1)
Assignee: darshanapadmadas → jwei
(In reply to alexander :surkov from comment #5)
> just ordinal HTML select
> 
> the problem here is all HTML select option except first one have invisible
> state what prevents us to calculate group position for it.

did you look into why VisibilityState() returns invisible? that might be interesting to understand.
I took a look at VisibilityState() for an HTML select element that's collapsed, and the view of one of the frames (the third one up the stack) is flagged as invisible when determining visibility for an option element.  When evaluating a combobox list, its view is invisible.  When evaluating a combobox, it's set to visible.  The combobox list is not actually visible to the user, so I guess it makes sense for it to be invisible.  I don't have enough knowledge yet about nsFrames, its relationship to the various accessible objects, and how the various accessibility tools utilise this information, but wouldn't changing this behaviour cause various other issues unrelated to this one?
(In reply to Jonathan Wei [:jwei] from comment #13)
> I took a look at VisibilityState() for an HTML select element that's
> collapsed, and the view of one of the frames (the third one up the stack) is
> flagged as invisible when determining visibility for an option element. 

well, its flagged as hidden which is right, and we interpret that as invisible, which might be a little fishy, but I guess I'm not that interested in touching that can of worms right now.

> When evaluating a combobox list, its view is invisible.  When evaluating a
> combobox, it's set to visible.  The combobox list is not actually visible to
> the user, so I guess it makes sense for it to be invisible.  I don't have

I guess somebody specificly makes the selected option shown then.

> enough knowledge yet about nsFrames, its relationship to the various
> accessible objects, and how the various accessibility tools utilise this
> information, but wouldn't changing this behaviour cause various other issues
> unrelated to this one?

Well, if I was going to change something else I'd consider how reasonable the check of the views visibility is, but I just assume not worry about breaking stuff which is really likely here.
Comment on attachment 8356780 [details] [diff] [review]
Made collapsed options offscreen and not invisible.

>     if (!selected) {
>       state |= states::OFFSCREEN;
>+      state &= ~(states::INVISIBLE);

^= might be clearer, but we generally have done &= ~x so whatever

>+++ b/accessible/tests/mochitest/states/test_selects.html

might be nice to test group position it self while your here.
Attachment #8356780 - Flags: review?(trev.saunders) → review+
Yes.I'm still looking for a bug to fix.Thanks.
It appears that tests related to group positioning, including that of the select element, already exist under attributes/test_obj_group.html.
Attachment #8356780 - Attachment is obsolete: true
> It appears that tests related to group positioning, including that of the
> select element, already exist under attributes/test_obj_group.html.

yes, but that only covers select size=N which is different, and of course if there was tests of this they would be marked as todo() since they clearly don't pass because the bug exists.
(In reply to Trevor Saunders (:tbsaunde) from comment #19)
> > It appears that tests related to group positioning, including that of the
> > select element, already exist under attributes/test_obj_group.html.
> 
> yes, but that only covers select size=N which is different, and of course if
> there was tests of this they would be marked as todo() since they clearly
> don't pass because the bug exists.

Ah, okay.  I'll get on that, then.  Apologies for the misunderstanding.
Attachment #8358565 - Attachment is obsolete: true
https://hg.mozilla.org/mozilla-central/rev/d2ec702a7017
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla29
Issue is resolved - clearing old keywords - qa-wanted clean-up
You need to log in before you can comment on or make changes to this bug.