storybook: [Bug]: Docs story wrapping issue with fixed positioned elements

if it’s not a breaking change

You are of course welcome to make whatever decision you want about prioritization, but FWIW I think it would be reasonable to argue that the original change in v7.1.0 was a breaking change. It didn’t change any programmatic API contract, but in a way it did change the UI contract.

You might also consider mentioning it in the migration file for anyone who still hasn’t migrated across the v7.1.0 boundary.

I’m upgrading from v6.5.13 to v7.6.7 for a relatively large design system that uses Storybook to generate a documentation site for internal usage, and I’m finding this issue to be a major headache during this upgrade. Lots of different types of components used to overflow their canvas bounds in our docs: dropdowns, menus, tooltips, modals, takeovers, dialogs, etc. For any component that uses any of these features, we must now specify a hardcoded larger height for the story. These hardcoded values have to then be hand-tuned for nearly every story, to ensure that the story contents fit in the canvas without excessive extra whitespace in our docs. We also can no longer test modals and takeovers full-screen to properly see behavior like the background page scroll becoming disabled.

Please consider reverting this change or adding some way to allow stories to overflow their canvas bounds to allow us to opt out of this hassle.

Thanks for an otherwise-great product!

@vanessayuenn would you consider having a more fine-grained control of zooming feature for docs, so people could disable it in elements like popovers and context menus, that fixed positioning is a frequent use case

Hi all and @konsalex , you can use this css in storybook

.docs-story div[scale="1"] {
  transform: none;
} 

working fine for me

@Luk-z added this also as a feature request: https://github.com/storybookjs/storybook/discussions/23699

@vanessayuenn would you consider having a more fine-grained control of zooming feature for docs, so people could disable it in elements like popovers and context menus, that fixed positioning is a frequent use case

@konsalex can you please write an example about how you expect to use the “fine-grained control of zooming feature for docs”.

I’m totally agree with @valentinpalkovic, the correct behavior of the docs container is to simulate a separate viewport. Consider this scenario: a Modal stories with a lot of fixed/absolute modals in the docs, all modals will be rendered on top of each other.

If you have a story with fixed element you have to consider the height and the position of that fixed element to be correct displayed in the docs.

This bugfix has introduced the current behavior: https://github.com/storybookjs/storybook/pull/21303

I’m honestly a little conflicted. On the one hand, I understand your problem, but on the other hand, I believe the container inside the docs page should be decapsulated from the environment, and elements should not break out of it. Now, you could adjust the height of the container on the Docs page so that modals find a place there as soon as they are triggered. What do you think? Do I overlook something?

cc @vanessayuenn, @shilman WDYT?