Fix DataTable tooltip position on paginated pages - #3928
Open
saket3395 wants to merge 1 commit into
Open
Conversation
Fixes plotly#1848. Tooltip row index was resolved against the virtualized (page-local) row twice: once when handling the mouse event, and again when matching the tooltip condition/data lookup. On page 1 these two resolutions coincide, masking the bug; on later pages they diverge, so tooltips render using the wrong row's position/data. Ports the fix from plotly/dash-table#906 (pre-merge into this repo): - cellEvents.ts: store the raw virtualized idx in currentTooltip.row instead of pre-resolving it, matching how handleMoveHeader already behaves for header tooltips. - tooltip.ts: resolve virtualized.indices[row - offset.rows] once, at lookup time in getSelectedTooltip, instead of relying on a pre-resolved value. Manually verified the diff is a faithful port of plotly#906 and consistent with the surrounding code (handleMoveHeader already stores the raw idx). Not yet run through the JS build/test suite locally.
saket3395
requested review from
KoolADE85,
T4rk1n,
camdecoster and
ndrezn
as code owners
July 31, 2026 06:38
|
Collaborator
|
Hi @saket3395 Thanks for the PR! I tested it locally, and it looks like the original solution you ported over from # 906 doesn't quite fix the issue. You can use the minimal app from the issue to reproduce it. When I run that app with your branch, the tooltip is now positioned correctly on both pages, but on page 2 it displays the tooltip text from page 1 instead of the correct text. import dash
from dash import html, dash_table
data = [
{"ID": i, "Name": f"Item {i}", "Description": f"This is item {i}."}
for i in range(1, 11)
]
app = dash.Dash(__name__)
app.layout = html.Div([
dash_table.DataTable(
id="simple-table",
columns=[
{"name": "ID", "id": "ID"},
{"name": "Name", "id": "Name"},
{"name": "Description", "id": "Description"}
],
data=data, # All data
page_size=5, # Page size is 5
page_current=0, # Initial page is the first one
tooltip_data = [
{
'Description': {
'value': row['Description'],
'type': 'markdown'
}
} for row in data
],
tooltip_delay=0,
tooltip_duration=None,
),
])
if __name__ == "__main__":
app.run(debug=False)
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



Summary
Fixes #1848 — DataTable tooltips render in the wrong position (top-left) on pages other than page 1 when pagination + tooltips are combined.
Root cause: the tooltip row index was resolved from the virtualized (page-local) index in two separate places — once in the cell event handler (cellEvents.ts), and again when matching the tooltip condition/data (tooltip.ts). On page 1 both resolutions happen to agree, hiding the bug. On later pages they diverge, so the tooltip looks up the wrong row.
This ports the fix originally proposed in plotly/dash-table#906 (opened against the standalone dash-table repo before it was merged into dash), applied to the current file paths — the line-level context still matched exactly:
As noted on the issue by @alexcjohnson: "should be relatively straightforward to bring it over here and finish it."
Test plan