Adding traces on hover can cause infinite loops

[cpsievert]

MRE of the problem (hover on any of the markers) -- http://codepen.io/cpsievert/pen/dvWydK

FYI this was working pre-1.24.0 -- http://codepen.io/cpsievert/pen/qrmBVx

[rreusser]

I think either 1.24.1 or 1.24.2 might already fix this. See: #1446

[etpinard]

Thanks for posting @cpsievert !

#1446 fixed a plotly_unhover -> Plotly.Fx.hover -> plotly_unhover infinite loop. But looks like addTraces suffers from another #1304 side-effect.

We should fix this before releasing 1.25.0.

[etpinard]

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.

In @cpsievert 's http://codepen.io/cpsievert/pen/dvWydK, an infinite loop is triggered since #1304 because:

• 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 (here hoverChanged(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.

@rreusser @alexcjohnson event data updates wasn't 🔒 ed down in the #1304 tests, so I guess this would be ok?

[alexcjohnson]

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]

Is there a more realistic use case for this?

I'm using it to implement all of this -- https://cpsievert.github.io/plotly_book/linking-views-without-shiny.html

you'd get an explosion of traces in a case like this anyway

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]

@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.

[alexcjohnson]

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.

[cpsievert]

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?

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]

Looks like this issue is up in the air.

Dropping from 1.25.0 for now. Adding discussion needed.