416804 - No longer seeing values getting updated automatically in Download Manager, fire proper name-changed events for ListItems.

Status: VERIFIED WORKSFORME

(Core :: Disability Access APIs, defect)

Description

[Marco Zehe (:MarcoZ)]

When downloading a file, I no longer see the download status get updated automatically. I suspect that this is a regression from landing of bug 308564, but did not have time to verify that yet.
STR:
1. Start any download large enough so that you get the List in DM for a few seconds.
Expected: Values should get updated as the download progresses.
Actual: No updating occurs.

Comment 1

[alexander :surkov (:asurkov)]

It shouldn't be cause of bug 308564 because that bug was targeted on xul:tree but DM uses richlistbox.

Comment 2

[Aaron Leventhal]

Surkov, if you could take this one that'd be great.

Comment 3

[alexander :surkov (:asurkov)]

Marco, I see ValueChange event from accessible for xul:progressmeter in Gecko layer. Can you give me some technical details?

Comment 4

[Marco Zehe (:MarcoZ)]

The progress meter is fine. The problem is in the ListItem that contains the info for the file you are currently downloading. it used to update as the kbyte blocks came in, updating the kb/sedc value and the time remaining etc.

Comment 5

[alexander :surkov (:asurkov)]

iirc value of label (as DOM node) is changed, do you mean some accessibility events are missed?

Comment 6

[Marco Zehe (:MarcoZ)]

Right. Last week when I was testing, and for weeks before that, I got frequent updates as I was downloading a file. This has stopped.

Comment 7

[Marco Zehe (:MarcoZ)]

Thiss is actually a regression resulting from fix for bug 407359. That bug converted the items of a RichListbox to ListItems. The patch landed in this build:
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b3pre) Gecko/2008012404 Minefield/3.0b3pre

Comment 8

[alexander :surkov (:asurkov)]

Marco, do you have in view this?

// nsIAccessibleRole::ROLE_RICH_OPTION
- { ROLE_SYSTEM_LIST, ROLE_SYSTEM_LIST },
+ { ROLE_SYSTEM_LISTITEM, ROLE_SYSTEM_LISTITEM },

Comment 9

[Marco Zehe (:MarcoZ)]

Right. The LISTITEM role is appropriate, we just need to make sure the proper events get fired once the label changes.

Comment 10

[alexander :surkov (:asurkov)]

Could you look what events have been fired?

Comment 11

[alexander :surkov (:asurkov)]

Marco, I really have not idea what was worked and why it had been stoped because we do not fire name_changed event at all (excepting recent tree accessible change). It sounds the proper way to fix the bug is to watch DOM mutations and fire name changed event if corresponding node has changed. Sure it's valid only if the bug is about we don't fire name_changed event.

Comment 12

[Marco Zehe (:MarcoZ)]

I just did a check using DOM Inspector, and the only events I see in both builds are the ValueChanged events of the progress meter. The progress meter is a child of the LISTITEM accessible in current builds, and was the child of the LIST. Both the old LIST and the current LISTITEM are the first child of the RICHLISTBOX. So only the change from being a LIST to bein a LISTITEM makes the item not update automatically. It appears that JAWS has different handlings for when a child of a list changes versus a child of a LISTITEM.

Comment 13

[alexander :surkov (:asurkov)]

Marco, could you retest the bug against nightlies please?

Comment 14

[Marco Zehe (:MarcoZ)]

There are some updates that now happen automatically: Not while downloading, but when checking it for viruses, and when having finished that, I get updates of the accName of the accessible item. But as the download happens, it either isn't updated, or the updates happen so fast that NVDA doesn't keep up.

Comment 15

[Trevor Saunders (:tbsaunde)]

(In reply to comment #14)
> There are some updates that now happen automatically: Not while downloading,
> but when checking it for viruses, and when having finished that, I get
> updates of the accName of the accessible item. But as the download happens,
> it either isn't updated, or the updates happen so fast that NVDA doesn't
> keep up.

I tried downloading some big files, with nvda I saw the beeping progress meter, but no automatic reading, but that may be because nvda choose not to read with the beepy thing.  However if I explicitly reaad the entry in the list it was being updated properly.  I also tried with orca and saw aproximately the same behavior. So my gues with out digging deeper is that this all works fine.  Marco mind calling this worksforme?

Comment 16

[Marco Zehe (:MarcoZ)]

Not at all, this is working for me again.

Comment 17

[Marco Zehe (:MarcoZ)]

Last tested with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110610 Firefox/7.0a1, but this also works in Firefox 4.