384667 - AT-SPI events not generated for all Firefox progress bars

Status: RESOLVED FIXED

(Firefox :: Disability Access, defect)

Description

[Joanmarie Diggs]

Steps to reproduce:

1. Launch Accerciser and turn event monitoring on.
2. Launch Firefox and begin the download of a file (e.g. a nightly build of Firefox).

Expected results:  Events would be generated for changes to the progress bar in the Downloads window.

Actual results:  Events are generated only for the changes to the Downloads window's title bar:

    object:property-change:accessible-name(0, 0, 55% of 1 file - Downloads)
	    source: [frame | 55% of 1 file - Downloads]
    	    application: [application | Minefield]
    object:visible-data-changed(0, 0, None)
	    source: [frame | 55% of 1 file - Downloads]
	    application: [application | Minefield]

Notes:

1. We are getting events for other XUL progress bars.  For instance, when downloading the latest update to Firefox or checking for mail in Thunderbird, we get object:property-change:accessible-value events, e.g.:

    object:property-change:accessible-value(0, 0, None)
            source: [progress bar | ]
            application: [application | Thunderbird]

2. This bug also seems to be present with the progress bar that is contained within the Firefox status bar and displayed when a page loads.  However, it is NOT present with all Firefox progress bars (e.g. the progress bar in the add-ons dialog that appears when you press the Find Updates button)

3. This does not seem to be a regression.  I "spot-checked" a number of builds between 2/28 and the present.

Comment 1

[Evan Yan]

We get dom event "ValueChange" for progressmeter when loading page, but don't get the event when downloading some file.

Comment 2

[Evan Yan]

in progressmeter's definition, it will dispatch 'ValueChange' event when its value get set.

http://lxr.mozilla.org/seamonkey/source/toolkit/content/widgets/progressmeter.xml
 22       <property name="value" onget="return this.getAttribute('value') || '0';">
 23         <setter><![CDATA[
[...]
 36               // Fire DOM event so that accessible value change events occur
 37               var event = document.createEvent('Events');
 38               event.initEvent('ValueChange', true, true);
 39               this.dispatchEvent(event);
 40             }

However, the value of progressmeter is inherit from some attribute in downloads dialog.

http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/downloads/content/download.xml
172               <xul:progressmeter mode="normal" value="0" flex="1"
173                     xbl:inherits="value=progress,mode=progressmode"/>

It seems the onset method of progressmeter won't be called when set value to the inherited attribute "progress"

Comment 3

[Evan Yan]

Attachment: Fire DOM event so that accessible value change events occur

Comment 4

[Mike Connor [:mconnor]]

Comment on attachment 268944 [details] [diff] [review]
Fire DOM event so that accessible value change events occur

probably worth filing a followup about not firing if the value is inherited.

Comment 5

[Evan Yan]

Comment on attachment 268944 [details] [diff] [review]
Fire DOM event so that accessible value change events occur

mconnor,
could you also sr this, or you'd like to have another sr to take a look?

Comment 6

[Aaron Leventhal]

Comment on attachment 268944 [details] [diff] [review]
Fire DOM event so that accessible value change events occur

Evan, sr= is not necessary in chrome (and I'm not sure that mconnor is an sr= anyway). It's ready for checkin now.

Comment 7

[Mike Connor [:mconnor]]

To clarify, SR isn't necessary in /browser or /toolkit, (chrome is a little fuzzy).  I am an SR these days, but shh, don't tell anyone.

Comment 8

[Evan Yan]

Checking in download.xml;
/cvsroot/mozilla/toolkit/mozapps/downloads/content/download.xml,v  <--  download.xml
new revision: 1.27; previous revision: 1.26
done
Checking in downloads.js;
/cvsroot/mozilla/toolkit/mozapps/downloads/content/downloads.js,v  <--  downloads.js
new revision: 1.65; previous revision: 1.64
done

Comment 9

[Joanmarie Diggs]

Thanks Evan!

This is working great.  It seems, however, that we're not getting an event when the progress bar reaches 100%.  Instead the progress bar just goes away.  Assuming I'm not missing something, would it be possible to tweak this further to issue an event at 100%?

Comment 10

[Evan Yan]

I looked at the download manager GUI, it seems there isn't a 100% state on it. I see the downloading progress goes to 96% or so, then it comes to finished directly without passing a 100% state.

Could orca work around this?

Comment 11

[Mike Pedersen]

I really don't think this one is a huge issue.  It is working quite well otherwise.  I'd say it's OK to close.

Comment 12

[Shawn Wilsher :sdwilsh]

This wasn't the right place to put that piece of code...

It would have made more sense placing it in onProgressChange (DownloadProgressListener.js)