[GH-ISSUE #842] table.SetWrapSelection(true, false) always set selectedRow to 0 even if the first row is not selectable #614

New issue

Closed

opened 2026-03-04 01:06:27 +03:00 by kerem · 2 comments

kerem commented

2026-03-04 01:06:27 +03:00

Owner

Originally created by @quantonganh on GitHub (Apr 21, 2023).
Original GitHub issue: https://github.com/rivo/tview/issues/842

Hi,

As the title says, if we enable vertically wrapping selections, on the UI, it jump from the last selectable row to the first selectable row, but selectedRow is always set to 0 even if the first row is not selectable.

You can reproduce by running something like this:

package main

import (
	"fmt"
	"strconv"

	"github.com/rivo/tview"
)

var headers = []string{"id", "value"}

func main() {
	app := tview.NewApplication()
	table := tview.NewTable().SetBorders(true)
	table.SetSelectable(true, false)

	textView := tview.NewTextView()
	textView.SetTitle("log").SetBorder(true)

	table.SetSelectionChangedFunc(func(row, col int) {
		fmt.Fprintf(textView, "row: %d\n", row)
	})
	table.SetWrapSelection(true, false)
	for col := 0; col < 2; col++ {
		table.SetCell(0, col, tview.NewTableCell(headers[col]).SetSelectable(false))
	}

	for row := 1; row < 4; row++ {
		table.SetCell(row, 0, tview.NewTableCell(strconv.Itoa(row)))
		table.SetCell(row, 1, tview.NewTableCell(fmt.Sprintf("row %d", row)))
	}

	flex := tview.NewFlex().SetDirection(tview.FlexColumn).
		AddItem(table, 0, 1, false).
		AddItem(textView, 0, 1, false)

	if err := app.SetRoot(flex, true).SetFocus(table).Run(); err != nil {
		panic(err)
	}
}

I think that we have a bug here: https://github.com/rivo/tview/blob/master/table.go#L1445

Originally created by @quantonganh on GitHub (Apr 21, 2023). Original GitHub issue: https://github.com/rivo/tview/issues/842 Hi, As the title says, if we enable vertically wrapping selections, on the UI, it jump from the last selectable row to the first selectable row, but `selectedRow` is always set to 0 even if the first row is not selectable. You can reproduce by running something like this: ```go package main import ( "fmt" "strconv" "github.com/rivo/tview" ) var headers = []string{"id", "value"} func main() { app := tview.NewApplication() table := tview.NewTable().SetBorders(true) table.SetSelectable(true, false) textView := tview.NewTextView() textView.SetTitle("log").SetBorder(true) table.SetSelectionChangedFunc(func(row, col int) { fmt.Fprintf(textView, "row: %d\n", row) }) table.SetWrapSelection(true, false) for col := 0; col < 2; col++ { table.SetCell(0, col, tview.NewTableCell(headers[col]).SetSelectable(false)) } for row := 1; row < 4; row++ { table.SetCell(row, 0, tview.NewTableCell(strconv.Itoa(row))) table.SetCell(row, 1, tview.NewTableCell(fmt.Sprintf("row %d", row))) } flex := tview.NewFlex().SetDirection(tview.FlexColumn). AddItem(table, 0, 1, false). AddItem(textView, 0, 1, false) if err := app.SetRoot(flex, true).SetFocus(table).Run(); err != nil { panic(err) } } ``` I think that we have a bug here: https://github.com/rivo/tview/blob/master/table.go#L1445

kerem closed this issue

2026-03-04 01:06:28 +03:00

kerem commented

2026-03-04 01:06:28 +03:00

Author

Owner

@quantonganh commented on GitHub (Apr 21, 2023):

Btw, if we have some header rows (that cannot be selected) as the above example, then vertically wrapping selections won't jump from first selectable row to the last selectable row, because this condition never happens: https://github.com/rivo/tview/blob/master/table.go#L1463

@quantonganh commented on GitHub (Apr 21, 2023): Btw, if we have some header rows (that cannot be selected) as the above example, then vertically wrapping selections won't jump from first selectable row to the last selectable row, because this condition never happens: https://github.com/rivo/tview/blob/master/table.go#L1463

kerem commented

2026-03-04 01:06:29 +03:00

Author

Owner

@rivo commented on GitHub (Jun 18, 2023):

Thanks for letting me know. This was much harder to do right than I initially thought. The latest commit should fix it. Let me know in case you still find a bug in there somewhere.

@rivo commented on GitHub (Jun 18, 2023): Thanks for letting me know. This was much harder to do right than I initially thought. The latest commit should fix it. Let me know in case you still find a bug in there somewhere.