-
Notifications
You must be signed in to change notification settings - Fork 30
Description
Filtering operations allow controlling which elements are rendered.
However, an open tooltip will remain even after its parent element has been removed by a filter + re-render operation.
Steps to reproduce
See coaccessibility demo:
https://statgen.github.io/locuszoom/examples/coaccessibility.html
- Click on a loop with score = 0.5
- Using the textbox widget, apply a filter (score >= 0.9)
- See tooltip remain
Initial diagnosis
It appears that the rendering pipeline operates on this.data (the unfiltered set)- effectively, global state. When we re-render, the preserved internal state ("a tooltip was here") sees an annotation for an element with a matching entry in this.data, and concludes it is safe to redraw this element.
We'll need to refactor our rendering pipeline towards a more functional style so that tooltips are drawn based on the filtered set as determined by the render function.
Links:
tooltips are rendered based on this.data, but arcs are rendered based on applyFilters. Thus, a tooltip can be drawn for an element that isn't really there!
- When a datalayer is rendered, it decides whether to draw any "state" values that it remembers. This includes "show tooltip". State decisions are based on the full, unfiltered data
- When a data layer is rendered, it also decides whether to draw any arcs. This is a separate decision: the filtered dataset is known only to the
renderfunction. - The function that sets element status may be called more than once, before, or after, the render function.
Other notes
The internal store of tooltip state also has some bugs: it is not always clearing the has_tooltip annotation successfully, even when a tooltip is deselected. The best fix would probably to simplify and "linearize" the existing rendering pipeline- it's super tangled, and state is passed from many different places.