301435 - Rich list box focus gets lost when focused item removed from list

Status: RESOLVED INVALID

(Toolkit :: UI Widgets, defect)

Description

[Aaron Leventhal]

1. Go to download manager
2. Arrow down to one of the items
3. Tab to "remove"
4. Hit enter

Focus goes away in the list. You can tab to other things, but not back into the
list.

This means that kbd users cannot really clean up their list of downloads.

Comment 1

[Doron Rosenberg (IBM)]

robert: I believe you said you had a patch to fix this?

Comment 2

[Aaron Leventhal]

Attachment: When new richlistitems are added, check selection and restore to an appropriate place

This also fixes bug 300780 -- initial focus in download/extension/theme manager

Comment 3

[Aaron Leventhal]

Attachment: Merge with trunk

Another thing that would be nice would be to show focus on the #saveToFolder
button at the bottom. Right now when you tab to it, focus disappears. I tried
adding a style rule for :focus to that or toolbarbutton in general, but most of
my style rules wouldn't take for some reason, even with !important.

Comment 4

[Doron Rosenberg (IBM)]

Comment on attachment 189998 [details] [diff] [review]
Merge with trunk

We should be checking if we are selected on destruction and if so, clear
selection.

Comment 5

[Doron Rosenberg (IBM)]

Attachment: patch

This patches download manager to set focus back and all, since doing it from
inside richlistbox was really hacky (checking if selection broke each time
somethign was added just sounds wrong).  Sadley there is no way to be notified
when the template gets rebuilt.

Comment 6

[Aaron Leventhal]

(In reply to comment #5)
> This patches download manager to set focus back and all, since doing it from
> inside richlistbox was really hacky (checking if selection broke each time
> somethign was added just sounds wrong).  

Yes but that fixed the base widget. We should always fix the base widget because
people will use richlistbox for other things. We can't always be around to fix
this kind of bug in each use of richlist box in extensions and with xulrunner.

Comment 7

[Doron Rosenberg (IBM)]

(In reply to comment #6)
> (In reply to comment #5)
> > This patches download manager to set focus back and all, since doing it from
> > inside richlistbox was really hacky (checking if selection broke each time
> > somethign was added just sounds wrong).  
> 
> Yes but that fixed the base widget. We should always fix the base widget because
> people will use richlistbox for other things. We can't always be around to fix
> this kind of bug in each use of richlist box in extensions and with xulrunner.

I'd rather fix it in the users for now and research a better way.  I'll talk to
the rdf people about a way to listen to rebuilds of templates. mconnor probably
needs to decide if the constructor thing is something we want to take

Comment 8

[Aaron Leventhal]

Doron, we would still need the <constructor> for the part that fixed bug 300780.

      <constructor>
+        <![CDATA[
+          var listBox = this.control;
+          if (!listBox.selectedItem)
+            listBox.goDown();  // Fix up initial focus as items are created

I guess I'll put that in a separate patch for that bug.

Comment 9

[Mike Connor [:mconnor]]

Comment on attachment 190062 [details] [diff] [review]
patch

r+a=me with the bogus blank line removed.

Comment 10

[Aaron Leventhal]

Checked in for Doron.

Checking in toolkit/content/widgets/richlistbox.xml;
/cvsroot/mozilla/toolkit/content/widgets/richlistbox.xml,v  <--  richlistbox.xml
new revision: 1.11; previous revision: 1.10
done
Checking in toolkit/mozapps/downloads/content/downloads.js;
/cvsroot/mozilla/toolkit/mozapps/downloads/content/downloads.js,v  <--  downloads.js
new revision: 1.47; previous revision: 1.46
done

Comment 11

[Aaron Leventhal]

Actually I'm going to reopen this so that at some point we can get a general fix
for richlistbox, instead of a workaround in the users of <richlistbox>.

Comment 12

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1527381