You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Adding traces on hover can cause infinite loops #1467
Ok. This problem is pretty tricky and is quite frankly (unless @cpsievert can prove otherwise) an edge case.
The infinite loop is triggered only when addTraces adds a trace containing similar enough coordinates to the one given in the plotly_hover event data. For example take http://codepen.io/etpinard/pen/xqrjza which adds traces outside the hover distance and does not trigger an infinite loop.
addTraces now leads to a Plots.rehover call (via Plotly.redraw),
Plots.rehover leads to a Fx.hover cal which then leads to
Fx.hover emiiting plotly_hover even though the mouse position hasn't changed (herehoverChanged(gd, evt, oldhoverdaa) is true as the curveNumber changed after the addTraces call)
and then the plotly_hover handler triggers addTraces
➿
Now, how to fix this problem?
In my opinion, I think the most robust solution would be to make rehover not trigger gd.emit('plotly_hover') while still updating gd._hoverdata and the visible hover labels.
Honestly I'm not sure if I would consider this a bug - yes it's an infinite loop, but you'd get an explosion of traces in a case like this anyway, at least for real data sets where you cause hundreds of hover events every time the mouse crosses the plot. And I do think we want rehover-hovers to emit an event so the more typical case of updating something outside the plot (or on a different subplot at least) will still happen.
Is there a more realistic use case for this? There are always going to be ways to trigger infinite loops when you modify a plot from inside an event handler, and I think at some level it's up to the user to avoid these, otherwise we'll be restricting what they can do.
@cpsievert just to clarify: the objective of #1304 is to update the hover state when the plot changes, e.g. streaming or animation and maybe a few other cases @alexcjohnson mentioned that were considered long-running issues where the hover state reflected outdated data until new mouse input triggered a new hover.
I think plotly_hoverupdate on rehover wouldn't be bad if it's not too bad to implement and if it's enough to disambiguate hover state changing as the result of input vs. reflecting new data.
I do a check to make sure I don't add the same trace twice. The example I linked to was a simplified version to help isolate the issue.
After that check do you still have a problem (and if so can you post it?), or were you just hoping not to need the check?
I wouldn't want to add a new event type for rehover, because then people would have to know that in the normal case they need to listen to both types. But we could certainly add something to the event to indicate whether it was triggered by a mouse event or something else like a rehover. Like... the mouse event itself? That could come in handy for other purposes too.
A community PR for this feature would certainly be welcome, but our experience is deeper features like this are difficult to complete without the Plotly maintainers leading the effort.
Sponsorship range: $5k-$10k
What Sponsorship includes:
Completion of this feature to the Sponsor's satisfaction, in a manner coherent with the rest of the Plotly.js library and API
Tests for this feature
Long-term support (continued support of this feature in the latest version of Plotly.js)
Hi - this issue has been sitting for a while, so as part of our effort to tidy up our public repositories I'm going to close it. If it's still a concern, we'd be grateful if you could open a new issue (with a short reproducible example if appropriate) so that we can add it to our stack. Cheers - @gvwilson
Activity
rreusser commentedon Mar 11, 2017
I think either 1.24.1 or 1.24.2 might already fix this. See: #1446
etpinard commentedon Mar 13, 2017
Thanks for posting @cpsievert !
#1446 fixed a
plotly_unhover->Plotly.Fx.hover->plotly_unhoverinfinite loop. But looks likeaddTracessuffers from another #1304 side-effect.We should fix this before releasing
1.25.0.etpinard commentedon Mar 13, 2017
Ok. This problem is pretty tricky and is quite frankly (unless @cpsievert can prove otherwise) an edge case.
The infinite loop is triggered only when
addTracesadds a trace containing similar enough coordinates to the one given in theplotly_hoverevent data. For example take http://codepen.io/etpinard/pen/xqrjza which adds traces outside the hover distance and does not trigger an infinite loop.In @cpsievert 's http://codepen.io/cpsievert/pen/dvWydK, an infinite loop is triggered since #1304 because:
addTracesnow leads to aPlots.rehovercall (viaPlotly.redraw),Plots.rehoverleads to aFx.hovercal which then leads toFx.hoveremiitingplotly_hovereven though the mouse position hasn't changed (herehoverChanged(gd, evt, oldhoverdaa)is true as thecurveNumberchanged after theaddTracescall)plotly_hoverhandler triggersaddTracesNow, how to fix this problem?
In my opinion, I think the most robust solution would be to make
rehovernot triggergd.emit('plotly_hover')while still updatinggd._hoverdataand the visible hover labels.@rreusser @alexcjohnson event data updates wasn't 🔒 ed down in the #1304 tests, so I guess this would be ok?
alexcjohnson commentedon Mar 13, 2017
Honestly I'm not sure if I would consider this a bug - yes it's an infinite loop, but you'd get an explosion of traces in a case like this anyway, at least for real data sets where you cause hundreds of hover events every time the mouse crosses the plot. And I do think we want rehover-hovers to emit an event so the more typical case of updating something outside the plot (or on a different subplot at least) will still happen.
Is there a more realistic use case for this? There are always going to be ways to trigger infinite loops when you modify a plot from inside an event handler, and I think at some level it's up to the user to avoid these, otherwise we'll be restricting what they can do.
cpsievert commentedon Mar 13, 2017
I'm using it to implement all of this -- https://cpsievert.github.io/plotly_book/linking-views-without-shiny.html
I do a check to make sure I don't add the same trace twice. The example I linked to was a simplified version to help isolate the issue.
rreusser commentedon Mar 13, 2017
@cpsievert just to clarify: the objective of #1304 is to update the hover state when the plot changes, e.g. streaming or animation and maybe a few other cases @alexcjohnson mentioned that were considered long-running issues where the hover state reflected outdated data until new mouse input triggered a new hover.
I think
plotly_hoverupdateon rehover wouldn't be bad if it's not too bad to implement and if it's enough to disambiguate hover state changing as the result of input vs. reflecting new data.alexcjohnson commentedon Mar 13, 2017
After that check do you still have a problem (and if so can you post it?), or were you just hoping not to need the check?
I wouldn't want to add a new event type for rehover, because then people would have to know that in the normal case they need to listen to both types. But we could certainly add something to the event to indicate whether it was triggered by a mouse event or something else like a rehover. Like... the mouse event itself? That could come in handy for other purposes too.
cpsievert commentedon Mar 13, 2017
Ooops -- I thought I had implemented that check, but it appears I haven't yet. Will work on it and report back if I still have issues, thanks!
etpinard commentedon Mar 13, 2017
Looks like this issue is up in the air.
Dropping from
1.25.0for now. Addingdiscussion needed.[-]Adding traces on hover causes infinite loop[/-][+]Adding traces on hover can cause infinite loops[/+]alexcjohnson commentedon Jul 7, 2017
This seems to have broken the last codepen on the hover event docs page https://plot.ly/javascript/hover-events/
https://codepen.io/plotly/pen/eJOyej
FYI @cldougl
jackparmer commentedon Sep 10, 2020
This issue has been tagged with
NEEDS SPON$ORA community PR for this feature would certainly be welcome, but our experience is deeper features like this are difficult to complete without the Plotly maintainers leading the effort.
Sponsorship range: $5k-$10k
What Sponsorship includes:
Please include the link to this issue when contacting us to discuss.
gvwilson commentedon Jun 10, 2024
Hi - this issue has been sitting for a while, so as part of our effort to tidy up our public repositories I'm going to close it. If it's still a concern, we'd be grateful if you could open a new issue (with a short reproducible example if appropriate) so that we can add it to our stack. Cheers - @gvwilson