By default the Width and Height of the SplitPane are NaN. So for a SplitPane docked to the top/bottom, it's width is governed by the available width of the dockmanager (or whatever horizontal room is left after measuring the SplitPanes that are closer to the outside edge than it). However since the Height is unspecified the SplitPane measures the content with the available size and then returns whatever is the desired size resulting from that. However once you assign a Height (implicitly or explicitly) to that root SplitPane then that is the height of the element - actually regardless of what you measure an element with the WPF framework will provide that constrained extent. By default we don't assume what Height you want for a SplitPane so it was in essence auto sizing for you. Had you set a Height on the root split pane or dragged the adjacent splitter bar (which would set the Height to an explicit height) then that is the height that would have been used to arrange the contained panes. Similarly when you drag a floating window to be docked to the dockmanager, it is the size of the window that is used to calculate the extent of the splitpane created and so that splitpane has a fixed extent (at least when it is a root splitpane). So in theory you could enumerate the panes provided to the PaneDragEnded, walk up to the root splitpane and clear its extent (assuming it is a new root split pane) but then the drop rect won't accurately reflect what the target size/location will be (as that will be based on the size that we would want to make the splitpane based on the floating size) and also the end user could still drag the adjacent split pane and cause an explicit extent to be set.