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
render function.
- 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.
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
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 inthis.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
renderfunction.Links:
tooltipsare rendered based onthis.data, but arcs are rendered based onapplyFilters. Thus, a tooltip can be drawn for an element that isn't really there!renderfunction.Other notes
The internal store of tooltip state also has some bugs: it is not always clearing the
has_tooltipannotation 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.