listbox.appendItem("abc", 123).value === undefined, ditto for .label property, if listitem never visible

NEW
Assigned to

Status

()

defect
15 years ago
7 months ago

People

(Reporter: gekacheka, Assigned: jst)

Tracking

(Blocks 1 bug)

Trunk
x86
Windows 2000
Points:
---
Bug Flags:
blocking1.9 -
blocking1.8.1 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

647 bytes, application/vnd.mozilla.xul+xml
Details
(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1

listbox.appendItem("label", value) creates a list item and sets its label and
value attributes, adds it to the listbox, and returns the listitem.

If the listitem is displayed in the visible rows at some point, then the
attributes are accessible in javascript with the .label and .value properties.

However, if the listitem is appended but never displayed (listbox has too few
rows and is never scrolled to show them), then the .label and .value properties
are undefined.


Reproducible: Always
Steps to Reproduce:
Original problem found in bug 231765 in listbox used in calendar eventDialog and
todo dialog, on Moz1.7, Firefox0.9.1, and Sunbird 20040701 (based on 1.8a2). 
Essence is the following:

1. Find XUL with <listbox id="mylistbox" rows="4">
2. in javascript, add more than 4 items with 
  var listbox = document.getElementByID("mylistbox");
  for (var i=0; i < 6; i++) { 
    var listitem = listbox.appendItem("mylabel"+i, i);
    dump("\n listitem.label: "+listitem.label);
    dump("\n listitem.getAttribute('label'): "+listitem.getAttribute("label");
    dump("\n listitem.value: "+listitem.value);
    dump("\n listitem.getAttribute('value'): "+listitem.getAttribute("value");
  }


Actual Results:  
After the 4 visible rows are filled, for the two invisible rows listitem.label
and listitem.value are the undefined value, even though
listitem.getAttribute("label") and listeitem.getAttribute("value") are the
expected values.

If the values are scrolled to become visible before accessing listitem.label and
listitem.value, then they are defined.

Expected Results:  
listitem.label and listitem.value work for all appended rows, even those never
made visible.

User workaround: scroll listbox to make all added items visible before operating
on them.


Code Workaround:  use
   listbox.ensureElementIsvisible( listbox.append("abc", 123"))
so that the added listitem must be made visible immediately after it is added.

Alternative code workaround:  access label and value attributes using
listitem.getAttribute("label") and listitem.getAttribute("value") instead of
listitem.label and listitem.value.

Updated

15 years ago
Assignee: jag → nobody
Component: XP Toolkit/Widgets → XP Toolkit/Widgets: XUL
QA Contact: jrgmorrison

Comment 1

13 years ago
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.
Flags: blocking1.9a2?
Flags: blocking1.8.1?

Comment 4

13 years ago
Yeah, as listbox doesn't create frames for hidden rows, and thus no XBL gets attached to them.

Comment 5

13 years ago
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?

Comment 7

13 years ago
No doubt.  Bring us a baked-on-trunk patch ;-)
Flags: blocking1.8.1? → blocking1.8.1-

Comment 8

13 years ago
Johnny any chance you could take a look at this?
Assignee: nobody → jst

Updated

13 years ago
Flags: blocking1.9a2? → blocking1.9-

Comment 9

13 years ago
Don't see any reason to fix this until XBL2

Updated

13 years ago
Blocks: 294029

Updated

11 years ago
Duplicate of this bug: 425271

Comment 11

11 years ago
Please make a note of this limitation in the docs.

Comment 12

11 years ago
I can second what J. Stritar said - there are also problems with adding to a selection when the element being added is off-screen.  

Updated

11 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.widgets

Updated

11 years ago
Duplicate of this bug: 448591

Updated

11 years ago
Duplicate of this bug: 437394

Comment 15

10 years ago
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.

Comment 16

9 years ago
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!

Comment 17

9 years ago
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:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4

Updated

6 years ago
Duplicate of this bug: 393373
You need to log in before you can comment on or make changes to this bug.