WebListBox: visible row height resize on load

Targets Web
1

When I load my WebListBox with data, the rows briefly are justified to fill the entire height, then a few milliseconds later, they snap back into being the expected height, as shown in this video:

WebListBox Row Height Video

Is there any way to prevent this? I’ve tried hiding / showing the listbox, but this doesn’t help, I still see the row height resizing.

[Edit to add: seeing this with 2021 R3, but I don’t think this is a new behavior]

2

Same behavior any browser?

3

Good question: yes, I am seeing it in both Safari and Chrome.

Interesting:

  1. If I make the browser window very short (so there are more listbox rows than can be displayed at once in the listbox ) then I don’t see the problem.
  2. However, if I then stretch the browser window, the rows jump back to filling the listbox height again, and I can’t get them to go back to normal.
  3. And, the behavior in #2 only happens if I start with a small window. If I start with a large window, make it small, then make it big again, it doesn’t happen.
  4. [Edit to add]: actually, sometimes I do see the behavior in #2, even when starting with a large window. It’s somewhat random.

It looks like it’s happening when the listbox says “I need to load another row”.

I’ll see if I can put together a demo project.

1 Like
4

Very easy to reproduce:

5

Tested in Vivaldi - confirm the row size effect.
Now, I was able to eliminate that effect:
add to Shown event of Listbox:

Var s As New WebStyle
s.Value("height") = "50px"
Style =s
6

That will break the bottom lock, no?

7

Just tested with less and multiple rows - no issues.

8

Here is the issue, at least on my mac with Chrome, Safari and Firefox.

Original code, lock bottom correct:

image
image591×798 30.2 KB

With your code, lock bottom wrong:

image
image591×798 29.3 KB

9

After experimenting some more (I already added information to case 66621), I have a “fix” but it needs to be executed after the listbox Shown event. It looks like JavaScript style changes in the shown event is replaced by Xojo, maybe needs to evaluate Shown changes to create the final listbox (I don’t know).

Here is the proof of the concept, see how the height is wrong when the webpage is resized and correct after applying the fix:
wlhfix.2021-11-20 09_00_51

Basically what the Fix does is:

  • set style=“height: 48px;” for each row
  • remove “line-height” for the buffer row

I don’t know if Greg thinks this is easier to implement or to update the “line-height” for the buffer row when the webpage is resized (as I mentioned in the case).

For case 66622 it looks like the WebListbox first is drawn without the buffer row, then drawn again with the buffer row. Maybe sending all rows with style height and draw the listbox with a buffer row without line-height will make sense to fix that problem too. But I don’t know exactly how the WebListbox works.

I hope this helps.

10

This was not visible at first so I don’t have access to the sample code. Can you share it again, it is still a problem with 2022R3?

1 Like
11

@AlbertoD - I just had my own software release, so my brain is fried, but I have uploaded the sample project to The Case - can you test ?

1 Like
12

Yes, the problem of a locked WebListbox (top/bottom) still exists when the browser window is very small/short and then resized to a larger/taller window. I even created a case for this that I guess is a duplicate of your case: #70399

3 Likes
13

Marked as fixed.