Right now when we hide or show tracks, it can resize the Timeline. We have various WithSize components or other listeners for sizing that need to measure the available space, and these break when the timeline size is changed.
OverflowEdgeIndicator STR:
- View a profile with a long list of visible timeline tracks.
- Scroll all the way to the top of the timeline.
- Hide tracks so that only a few are visible.
- The shadow at the bottom is still visible
- Scroll or resize the browser to make it go away
ChartCanvas STR:
- View a profile with a long list of visible timeline tracks and the Flame Graph
- Select a track that will still remain visible
- Hide other tracks to shrink the timeline header size
- The Flame Graph's chart will not take up the available space until a resize event is fired.
There might be some others. There are two strategies here. Either we invalidate each component by subscribing to changes in the store, possibly a timelineHeaderSizeGeneration type of value that increments on any timeline header change, or we fire a resize event in the action creators. My preference would be to fire a resize event, even though it is a bit of a side effect, as it should fix every case here, and any new ones introduced.
Right now when we hide or show tracks, it can resize the Timeline. We have various
WithSizecomponents or other listeners for sizing that need to measure the available space, and these break when the timeline size is changed.OverflowEdgeIndicator STR:
ChartCanvas STR:
There might be some others. There are two strategies here. Either we invalidate each component by subscribing to changes in the store, possibly a
timelineHeaderSizeGenerationtype of value that increments on any timeline header change, or we fire aresizeevent in the action creators. My preference would be to fire a resize event, even though it is a bit of a side effect, as it should fix every case here, and any new ones introduced.