Hover Issue in One of Two Histograms with Same Column Type in UI Extension 1.5.5

·Aug 27, 2026 07:41 PM·

Hi, I was browsing the column explorer in the UI extension for 1.5.5 when I noticed that hovering only works in one of two histograms, even though both columns shared the same type (uint32). Is this expected (e.g. due to the wider bins), and if not is there anything I can look up or share to help identify the bug? I've verified the issue in both Chrome and Firefox (surprisingly the column order is different across both).

5 comments

· Sorted by Oldest

Kate R.
·
·
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.
👍1
Fabian
·
·
Are you also able to repro the reversed field order in Firefox, by any chance? (left: Chrome, middle: Safari, right: Firefox)
Kate R.
·
·
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.
Fabian
·
·
while Firefox ends up reversing it
Out of curiosity, were you able to tell why? I wonder if there's webcompat bug lurking here.
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).
👍1

Kate R.
·
·
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.
👍1
Fabian
·
·
Are you also able to repro the reversed field order in Firefox, by any chance? (left: Chrome, middle: Safari, right: Firefox)
Kate R.
·
·
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.
Fabian
·
·
while Firefox ends up reversing it
Out of curiosity, were you able to tell why? I wonder if there's webcompat bug lurking here.
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).
👍1