Closed
Bug 298524
Opened 19 years ago
Closed 19 years ago
Add init() method to richlistbox
Categories
(Toolkit :: UI Widgets, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: doronr, Assigned: doronr)
References
Details
Attachments
(1 file, 1 obsolete file)
3.81 KB,
patch
|
mconnor
:
first-review+
benjamin
:
approval-aviary1.1a2+
|
Details | Diff | Splinter Review |
Assignee | ||
Comment 1•19 years ago
|
||
Adds init() and 2 other methods. Also fixes cdata differences (not included in patch :)
Comment 2•19 years ago
|
||
+ var lastSelected = this.getAttribute("last-selected"); I'm not sure making a "last-selected" attribute manadatory for this to work is the way to go though it does work for the EM, etc. + if (!lastSelected) + this.goDown(); + else + this.selectedItem = lastSelected; I'm pretty sure that ensureElementIsVisible will not behave as expected when this is called from startup in extensions.js since the window is not visible yet. A setTimeout on both of these should do the trick.
Comment 3•19 years ago
|
||
It turns out that by calling scrollToElement at the end of init the setTimout is not necessary. Also, the constructor for richlistitem is rather evil and should probably be removed... it calls setTimeout(listbox.goDown, 0); once for each richlistitem added and doesn't provide any value that I can see.
Assignee | ||
Comment 4•19 years ago
|
||
(In reply to comment #3) > It turns out that by calling scrollToElement at the end of init the setTimout is > not necessary. Also, the constructor for richlistitem is rather evil and should > probably be removed... it calls setTimeout(listbox.goDown, 0); once for each > richlistitem added and doesn't provide any value that I can see. With my patch and removing the richlistitem constructor, EM selects the right one when init gets called. So am confused by your "scrollToElement" comment
Comment 5•19 years ago
|
||
(In reply to comment #4) > With my patch and removing the richlistitem constructor, EM selects the right > one when init gets called. So am confused by your "scrollToElement" comment I have a test profile with 30+ extensions and when I select an extension that is out of view when the EM is opened, close the EM, and reopen it the extension is selected but it is one position off out of view as described in bug 298164. This is without the setTimeout's that get called for each item as they are added which may be why you are seeing the item when the EM is opened.
Assignee | ||
Comment 6•19 years ago
|
||
Attachment #187067 -
Attachment is obsolete: true
Attachment #187140 -
Flags: first-review?(mconnor)
Updated•19 years ago
|
Attachment #187140 -
Flags: first-review?(mconnor) → first-review+
Assignee | ||
Updated•19 years ago
|
Attachment #187140 -
Flags: approval-aviary1.1a2?
Comment 7•19 years ago
|
||
*** Bug 298164 has been marked as a duplicate of this bug. ***
Updated•19 years ago
|
Attachment #187140 -
Flags: approval-aviary1.1a2? → approval-aviary1.1a2+
Assignee | ||
Comment 8•19 years ago
|
||
checked in
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment 9•19 years ago
|
||
I should have been more specific when I suggested using scollToElement... this should only be called in init and not when setting selectedItem. When selecting an item it should only scroll when an item that is being selected is not in view and with scrollToElement it always scrolls the selected item to the top.
Assignee | ||
Comment 10•19 years ago
|
||
(In reply to comment #9) > I should have been more specific when I suggested using scollToElement... this > should only be called in init and not when setting selectedItem. When selecting > an item it should only scroll when an item that is being selected is not in view > and with scrollToElement it always scrolls the selected item to the top. oops, good catch
You need to log in
before you can comment on or make changes to this bug.
Description
•