Happens to the composer too if you want something else to be annoyed about ![]()
The problem is that fixed elements are positioned relative to the viewport width, and scrollbars change the viewport width.
Like @Canapin mentions, this is compensated for on <HTML> with an extra margin (looks like magnific popup behavior?)… since fixed elements aren’t relative to <HTML> the composer and header would need an additional fix.
What we’d need to do is take the width of scrollbar and then when the popup is activated we’d add some inline styles like:
.d-header {
left: -15px; /* 15px wide scrollbar in this example */
width: calc(100% + 30px); /* add 2x scrollbar width to compensate for shift & width */
}
Implementing this is a little beyond me… I think scrollbar width is probably calculated by comparing the width of the page before & after the popup? Not 100% sure.
All that being said… this will be slightly less of an issue if we move to position: sticky after dropping IE11 support this year. The shift would no longer happen, but there might be a gap to the right of the header where the scrollbar used to be.