Kate R.

Nothing to file with Mozilla on this one, the bug is on our side. The "Default" option in the column list passes a comparator to Array.prototype.sort that returns a positive value for every pair. The reference linked here is an example from MDN of the class of issue that's occurring: Sorting with a non-well formed comparator (Chrome & Safari keep column order, Firefox produces a reversal).

Hi Fabian, thank you for the follow up! I have also been able to reproduce this issue, your instinct was right that it's separate from the hover bug. I've filed this internally with the repro and root cause as well. The trigger is the column list's default sort which ultimately allows each browser's sort implementation to order the list however it likes - Chrome and Safari happen to keep the table's own column order, while Firefox ends up reversing it. As a workaround, switching the sort selector from Default to Name or Type gives you consistent ordering across browsers.

Hi Fabian, thank you for bringing this to our attention! I have been able to replicate this on my end. The trigger turned out to be the x-axis, I'm seeing that hover breaks on any numeric histogram whose axis starts at exactly 0 due to a bounds check in the mouse handler, so at 0 it reads every cursor position as outside the plot and silently does nothing. As a workaround, you can use the following to get bin edges and counts as a result set as a substitute for the tooltip:

SELECT * FROM histogram(your_table, change_seq, bin_count := 20);

Today I've filed an issue internally with a repro and the root cause, so nothing further needed on your end. Happy to follow up here once it ships.