fire reorder event on XUL tree when treeview is changed

RESOLVED FIXED in mozilla2.0b8

Status

()

Core
Disability Access APIs
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: surkov, Assigned: surkov)

Tracking

({access})

unspecified
mozilla2.0b8
access
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

7 years ago
Created attachment 492988 [details] [diff] [review]
patch

Now we fire platform show/hide events on XUL tree when tree view is changed. The reality is show/hide events aren't used by AT in general. But they listen for reorder events. It's more expected to use it instead of platform show/hide events. Ideally we should fire hide events for all old tree items and new for new tree items but I afraid of perf issue. Therefore I suggest to fire reorder event only and leave show/hide events issue for future.
Attachment #492988 - Flags: review?(marco.zehe)
Attachment #492988 - Flags: review?(bolterbugz)
Attachment #492988 - Flags: approval2.0?
(Assignee)

Comment 1

7 years ago
I need this for bug 498015 where I'm going to process DOM events after layout. So that mochitest can't rely on TreeViewChanged DOM event anymore.
I think we need a try build here.
Blocks: 498015
(Assignee)

Comment 3

7 years ago
np - http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/surkov.alexander@gmail.com-6a0fefcfd139
Comment on attachment 492988 [details] [diff] [review]
patch

Removing patch approval request as this blocks a blocker now.
Attachment #492988 - Flags: approval2.0?

Comment 5

7 years ago
Comment on attachment 492988 [details] [diff] [review]
patch

The patch looks straight-forward, but I'd like to see a try build before I can r+ this one.
Comment on attachment 492988 [details] [diff] [review]
patch

>@@ -591,36 +591,28 @@ nsXULTreeAccessible::TreeViewInvalidated

> void
> nsXULTreeAccessible::TreeViewChanged()

>-
>   mTree->GetView(getter_AddRefs(mTreeView));

What is this for?
(Assignee)

Comment 7

7 years ago
(In reply to comment #6)

> >-
> >   mTree->GetView(getter_AddRefs(mTreeView));
> 
> What is this for?

line removal or mTreeView intializing when tree view was changed?
The latter. This call initializes the tree view?
Comment on attachment 492988 [details] [diff] [review]
patch

r=me, ignore my last comment/question (I totally missed the mTreeView somehow). Not this r+ is conditional on not breaking screen readers ;)
Attachment #492988 - Flags: review?(bolterbugz) → review+
Comment on attachment 492988 [details] [diff] [review]
patch

Yep this works, thanks! r=me.
Attachment #492988 - Flags: review?(marco.zehe) → review+
(Assignee)

Comment 11

7 years ago
landed on 2.0 - http://hg.mozilla.org/mozilla-central/rev/6038dc8945d8
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8
You need to log in before you can comment on or make changes to this bug.