Assignee: jag → nobody
Component: XP Toolkit/Widgets → XP Toolkit/Widgets: XUL
QA Contact: jrgmorrison
We just experienced this bug in Forecastfox. All sorts of weird stuff happens when the selected item is not visible. In addition to the .value and .label properties being undefined, you can't actually select it. Check out the test case where "h" is supposed to be selected. After it is selected but not visible, you can't select it again.
Compare bug 120410.
Sucky platform bug, nominating.
Yeah, as listbox doesn't create frames for hidden rows, and thus no XBL gets attached to them.
Not going to block 1.8.1 for this, but we'll happily consider a baked-on-trunk patch.
Flags: blocking1.8.1? → blocking1.8.1-
This is a sucky bug for a lot of people working with dynamic chrome UI (including comment #1, which might partially be describing another bug). I'll plead my case to drivers, I guess.
Flags: blocking1.8.1- → blocking1.8.1?
No doubt. Bring us a baked-on-trunk patch ;-)
Flags: blocking1.8.1? → blocking1.8.1-
Johnny any chance you could take a look at this?
Assignee: nobody → jst
Don't see any reason to fix this until XBL2
Please make a note of this limitation in the docs.
I can second what J. Stritar said - there are also problems with adding to a selection when the element being added is off-screen.
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.widgets
Another fun variant, not sure if this stems from the same thing or not. Dynamically building a listbox on say an onpaneload function and then setting the selection fails. There's no visual selection, though the control does report the selection if asked programatically. I ended up doing it from a timeout and that seems to work, though a bit hokey.
Bug 437470 and Bug 553768 seems duplicate of this: a bit different descriptions but the same problem at back-end: - 'Invisible' (because never was show it) elements in listbox cause problems when access it by code -getting properties, executing methods-, including when pass it like a parameter of a ListBox method. - And the same workaround: use the ListBox.ensureElementIsVisible(listitem) after the element is added to the listbox, or before to access listitem properties or methods. Is alright? The another bugs confirm that the problem happens in another platforms: x86 Windows XP and x86 Linux, seems like a platform independent bug. Is possible add documentation about this with the workaround in Mozilla Developer Center (in pages like https://developer.mozilla.org/en/XUL_Tutorial/List_Controls)? Thanks!
Sorry, I am testing the workaround and I find a small detail: With the workaround explained before it's needed know that, when use it, the scroll in the listbox is moved to the position of the listitem, doing a small change in the user interface. It is not possible avoid this behavior, but you can restore the scroll after apply 'ensureElementIsVisible' to simulate it, using the pair of methods: getIndexOfFirstVisibleRow() and scrollToIndex(index). A complete example of the workaround: let listBox = document.getElementById("mylistbox"); // ... maybe some code... // We save the index of the current scroll: let index = listBox.getIndexOfFirstVisibleRow(); // maybe you are creating a new element in the listBox (or searching a // listitem in the listBox): let item = listBox.appendItem('item label', 'item value'); // now, we use the workaround to avoid problems with 'item': listBox.ensureElementIsVisible(item); // we do something with the item, like add to the selected items // (without the 'ensureElementIsVisible' call, the next line would be // problematic -don't raise an error, but the user will not see the 'item' // like selected-) listBox.addItemToSelection(item); // the 'ensureElementIsVisible' call moved the scroll in the listbox to show the // item (when you append an item this is inserted at the end of the listbox), // but you can restore it with the saved index: listBox.scrollToIndex(index); All this tested in: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:220.127.116.11) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
You need to log in before you can comment on or make changes to this bug.