For optimizing places trees, the data for each row is built only once the row in question becomes visible. This behavior was quite-easy to implement given the tree-view api. It would be nice to have the same feature for richlistboxes. Take the old download manager for example: when it opens an unlimited number of richlistitems is built for not more than 7 or so visible items. The new downloads view in the Places library is going to use richlistbox too. Whilst this bug doesn't block that (because it's not a regression), it'd prevent adoption of this new view in other places ui.

Wouldn't be too difficult to implement. <listbox> already does this, although the code has issues. It would only work for richlistbox if each item was the same height, as the scrollbar can't be accurate unless the full height is known already.

So basically, richlistbox uses "children" property, where listbox uses a listBoxObject that does lazy frame construction (that we are also evaluating to remove in bug 643076?). If all of the children have the same height it may use the listBoxObject instead, if not that rlb supports box direction (like "reverse") while listbox doesn't. Looks like for now we may create a richlistbox-lazy widget that uses listBoxObject but doesn't support dir.

we could even create that special rlb in downloads component if we're not fine with taking it in toolkit (indeed could be better to first decide on bug 643076 and support box direction in listbox and then properly fix the toolkit widget)