- scrollable list box
- list item
- another list item
- the next list item
- list item
- another list item
- the next list item
- list item
- another list item
- the next list item
- list item
- another list item
- the next list item
- the next list item
- list item
- another list item
- the next list item
- the next list item
- list item
- another list item
- the next list item

- scrollable list box
- list item
- another list item

- scrollable list box
- list item
- another list item
- the next list item
- list item
- another list item
- the next list item
- list item
- another list item
- the next list item
- list item
- another list item
- the next list item
- the next list item
- list item
- another list item
- the next list item
- the next list item
- list item
- another list item
- the next list item

- scrollable list box
- list item
- another list item
- the next list item
- list item
- another list item
- the next list item
- list item
- another list item
- the next list item
- list item
- another list item
- the next list item
- the next list item
- list item
- another list item
- the next list item
- the next list item
- list item
- another list item
- the next list item

In the above testcase: reinitialising jScrollPane (either via the api or simply by re-calling .jScrollPane() on the original element) strips out the width of the div.jspPane and causes a rendering issue: the absolutely-positioned div renders only as wide as its text content. The expected behavior is that it'll fill the available width, as it does on page load after the first call to .jScrollPane().

UPDATE: this is fixed for scrollable content in v2b2, but when the content is not scrollable there's still undesired rendering on first load.

Additionally, padding calculations might need some tweaks. The third list box here is identical to the first two except for an added 5px of padding all the way around: note how the jspVerticalBar is partially pushed out of view.