Table widget: tbody row indexing starts from 1 when there's a row in table header
Closed this issue · 4 comments
Reproduced on following table: https://gist.github.com/abalakh/277f5561ddd1a0bd010bb06104c515b0
I think it should be reproducible on following simplified table (haven't tried though):
<table>
<thead>
<tr>
<th><input type="checkbox"></th>
<th><span>RPM Name</span></th>
<th><span>Architecture</span></th>
<th><span>Version</span></th>
<th></th>
</tr>
</thead>
<tbody>
<tr>
<td><input type="checkbox"></td>
<td>walrus</td>
<td></td>
<td>Version 0.71-1</td>
<td>
<button type="button">
<span>Edit</span>
</button>
</td>
</tr>
</tbody>
</table>The table has only 1 row in <tbody>, but there's also a row in <thead>.
When i was using older widgetastic (0.21.1) table.rows() returned 1 row with row.index == 0 for such table, after upgrading to 0.21.6 there's still 1 row but row.index == 1.
I think it's most likely due to extra row inside <thead>, and the regression was introduced in #104
@mshriver unfortunately, now it's only worse :( That or maybe some next change introduced very weird regression.
Couple of details about that table: initially, when user opens the page, it has 1 row with 1 td with colspan=5. Then user hits 'Add rule' button, and one extra tr appears before mentioned one:
Previously (with 0.21.x) it was working ok. Now i can't figure out what's going on:
- table.read() returns empty list
- table[0][x] returns the message from that second row with colspan. Same after table.clear_cache()
- table[0].read() returns a dict with headers as keys and that message as values (would be ok if i was accessing [1] element)
- table[0][x].position == 0
- same with table[1][x].position == 0 and .text - it returns message from second row. So, basically, both [0] and [1] rows are pointing to second row
- attempt to use fill like table[0][4].widget.fill() actually tries to fill [0][0] widget (i guess since it thinks that [0] - is second row, and second row has colspan, so this behavior might be ok)
Original issue with wrong index can be worked around, but i can't find any workaround for this one, basically i need a way to fill that first row somehow.