67803 - No focus in Download Dialog box

Status: VERIFIED FIXED

(Core Graveyard :: File Handling, defect)

Description

[Tim Smith]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20010205
BuildID:    2001020520

When you download a file the download window pops up, but unlike IE (I'm sorry,
but the feature is nice) you cant just hit the up arrow and have that select
open with application instead of save to disk.  You have to first tab onto that
field.

Reproducible: Always
Steps to Reproduce:
1.Download a file
2.Hit the up arrow
3.

Actual Results:  Nada

Expected Results:  It would be nice it it would just select the other button

Comment 1

[Fabian Guisset]

-> UI:design feedback.
Reporter, could you tell us if anything is focused at the moment? Would 
focusing the radiobutton steal the focus from something else?
Thanks for reporting bugs!

Comment 2

[Warner Young]

Fabian, I can confirm using 2001020604 on Win98, Modern theme.  I can't tell
what has the focus.  Pressing tab once will bring the focus to "Open using". 
Pressing Shift-Tab at that point takes the focus indicator away again.  Whatever
this initial object is, it's not in the tab order of the dialog, because
pressing tab (not Shift-Tab) repeatedly moves the focus indicator through all
the visible widgets in the dialog.

Comment 3

[Tim Smith]

Nothin is selected when you start the download.  It would be stealing the
selection from anything

Comment 4

[Keyser Sose]

Changing Summary to reflect the fact that there is no focus on the dialog box.

Comment 5

[hangas]

Sending to component owner

Comment 6

[sairuh (rarely reading bugmail)]

->bill?

Comment 7

[Bill Law]

Setting target milestone.

Comment 8

[Aaron Leventhal]

Attachment: Appears to fix bug 67803, bug 74012, bug 79862, bug 98797

Comment 9

[Bill Law]

I tried this:
   this.dialogElement( "mode" ).focus();
instead of:
   
this.mDialog.document.commandDispatcher.advanceFocusIntoSubtree(this.mDialog.document.firstChild);

The only difference (aside from the length of that line of code :-) is that the
latter focuses the first child, rather than a specific child node.  But an
explicit focus() call was added to the onload handler in the progress dialog so
I'm not sure which is preferred.  I like the short version.

Also, bug 98797 requests that we leave the "Close this dialog" checkbox enabled
on the download progress dialog (so that users can change the setting that will
be in effect for the *next* download).  I attempted to do that (by removing the
line of code that disabled that checkbox) but found that that messed up your
code that puts the focus on the Close button when the download completes.

The problem is that the download can complete before the dialog finishes
loading.  In that case, the .focus() call added in the onload handler fires
*after* the .focus() for the Close button.

I fixed that by making the onload .focus() call only happen when the download
isn't yet completed.

I'll attach a patch file with my changes shortly.

      

Comment 10

[Bill Law]

Attachment: Slightly different patch

Comment 11

[sairuh (rarely reading bugmail)]

spam: over to File Handling.

Comment 12

[Aaron Leventhal]

r=aaronl

sr?

Comment 13

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 52601 [details] [diff] [review]
Slightly different patch

sr=[e-mail]

Comment 14

[Bill Law]

fixed

Comment 15

[sairuh (rarely reading bugmail)]

focus is working in the helper app dialog. but i noticed that i cannot use the
keyboard to change/navigate to its radio buttons --files bug 108981.

vrfy'ing this bug as fixed using commercial bits:

linux [rh6.2] - 2001.11.06.12
winNT - 2001.11.06.12
mac os 10.1 - 2001.11.06.08