Floating tab groups move in nested dockview

[michaelsharpe]

Describe the bug
I am using nested dockviews. I have one controlling a tab system, and within the tab there are workspaces with tab windows. When I pop a group out and position it, switch parent tabs, and come back, the floating group is moved to the top right corner.

To Reproduce
This issue can be reproduced directly on the nested dockview demo on the site here https://dockview.dev/docs/components/dockview#nested-dockviews.

Steps to reproduce the behavior:

1. Go to https://dockview.dev/docs/components/dockview#nested-dockviews
2. Move the parent tabs into the same tab bar.
3. Pop out one of the tabs of the child and move it somewhere
4. Switch tabs
5. Return back to tab with nested dockview.

Expected behavior
Floating tab groups should stay where they are placed.

Screenshots

Screen.Recording.2023-09-28.at.3.30.16.PM.mov

Desktop (please complete the following information):

• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

[mathuo]

Nice find - thank you!

I've taken a look into this and the explaination is something like...

dockview dispatches most resize events through requestAnimationFrame calls for performance reasons. This means that the actual resize call doesn't necessarily happen immediately and in this case the callback isn't called until after the nested dockview has been unmounted from the DOM to make way for the newly focused panel. Since that element is no longer attached to the DOM when the internal resizing logic goes to measure this component it measures as zero in both dimensions and position causing the resetting of the floating panels position to the top left (0, 0).

To fix this issue the resizing logic should check that the element it is measuring is actually still present in the DOM and if it is not skip the resize call.

[michaelsharpe]

Thanks for the explanation! Stoked for this to be working. This is perhaps one of my favourite features of switching over to Dockview.

Out of curiosity, anything on the roadmap to pull a tab out into a totally new browser window?

[mathuo]

Released in version 1.8.4

[garyvh2]

Hey there @mathuo I've ran into an instance of this issue when applying display: none on the element containing the view.

Here's a video, not sure if you have any recommendations.

Screen.Recording.2023-12-14.at.15.23.54.mov

[fwhatley]

Any answer on @garyvh2 comment? I am seeing the same issue where when you use display:none, the library resets the floating windows position to 0,0.

[mathuo]

Any answer on @garyvh2 comment? I am seeing the same issue where when you use display:none, the library resets the floating windows position to 0,0.

Hey. - can you expand on what exactly you are doing please. Slightly unsure where the display: none is coming from?

[garyvh2]

In my case at least, we have a top level utility that works as a tab manager, each tab has an instance of Dockview, when the tab is not selected, the content gets applied display: none causing Dockview to recalculate its size over a non rendered view.

[mathuo]

In my case at least, we have a top level utility that works as a tab manager, each tab has an instance of Dockview, when the tab is not selected, the content gets applied display: none causing Dockview to recalculate its size over a non rendered view.

ah ok - so in your case you are setting a display: none on the entire dockview instance?

[garyvh2]

I think is on a div on top of it, but yeah, not sure if there's a workaround to make sure size is preserved when display none is applied.

[mathuo]

I think is on a div on top of it, but yeah, not sure if there's a workaround to make sure size is preserved when display none is applied.

nice, that makes more sense. I have a feeling it's probably something in the resizable.ts logic. I will need to check how this behaves with display: none, will open as a new issue. Thanks

[garyvh2]

Much appreciated, Mathuo