Dialog add-padding-to-html technique for scrollbar is problematic and there's no way to control it #1319

firxworx · 2022-04-11T01:33:38Z

Package: @headlessui/react
Version: v1.5.0 (latest at time of writing)
Chrome + Windows 11 (this issue affects many others as well; see description + case)

Reproduction URL

Any example of the Dialog component is a valid reproduction: open DevTools and monitor the HTML element while opening a Dialog.

Refer to the implementation in dialog.tsx where the issue behaviour is implemented in a useEffect() preceded by the comment line // Scroll lock:

https://github.com/tailwindlabs/headlessui/blob/main/packages/@headlessui-react/src/components/dialog/dialog.tsx#L247-L270

Issue Description

The current Dialog implementation makes less-than-ideal assumptions re scrollbars + project CSS and when a Dialog/modal is open, it applies a technique that adds an inline overflow: hidden and padding-right (with value based on a calculation of scrollbar width) to the document's <html> tag.

This results in undesired behaviour / jank in different cases especially on Windows PC's where scrollbars are rather visually imposing.

The lack of control for this behaviour (especially the padding) leaves devs without the ability to more elegantly handle scrollbars and/or handle corner cases or conflicts caused by other styles in a given project.

Why is this important?

Scrollbars are a notoriously fickle beast between different OS's and browsers (see: one example among many articles on the subject).

I would argue a good reason to check/switch between Mac + PC when working on front-end projects are the differences in scrollbars between these OS's. Our traffic doesn't always have the same taste in computers vs. many of us web devs :D

Example case:

The following breaks down a single case that is part of a wider issue; refer to linked issue + discussion for related cases.

A straightforward cross-platform-friendly technique to avoid jank during loading + transitions that is particularly gross on Windows is to add overflow-y: scroll to the body tag. This causes browsers on PC's to always display a scrollbar even when the content fits within the viewport (in this case the scrollbar is present but is presented as disabled/inactive).

This technique is in the tailwind-preset.js on several projects I work on and is compatible with many packages/libraries/frameworks to help avoid "jumps" and overall "jank".

However in this case Dialog is the cause of the very problem it is attempting to prevent:

Content behind the Dialog noticeably "jumps" to the left by the width of the scrollbar.

In the screenshot we see padding-right jumping the content by the width of the scrollbar in both of the following cases: when the content is taller than the viewport (i.e. case for y scrollbar), and when it is shorter (i.e. nothing to scroll).

Confirming:

when overflow-y: scroll is removed from the body then Dialog behaves the way that the devs presumably intended (tested on Chrome+PC): no padding or jump is present in the content-fits-window case (no scrollbar visible), and in the content-taller-than-window case (scrollbar visible) the added padding compensates for the scrollbar disappearance resulting from Dialog's addition of overflow: hidden.

The presumably-intended behaviour isn't particularly elegant in the content-taller-than-window-case on PC either:

Windows' imposing scrollbar suddenly disappears and this can result in users' "wtf just blinked"/"jank detection" neurons firing. While a content "jump" is prevented the sudden replacement of the scrollbar with a solid vertical block that doesn't match the app layout isn't much better.

At present, devs have no way to control any of this behaviour if they wish to use Dialog --

Before Dialog is rendered (imposing Windows scrollbar is visible):

With Dialog modal showing (scrollbar suddenly disappears and it ain't pretty):

Expected/Desired Behaviour

Developers require the ability to control the overflow+padding behaviour of Headless Dialog (e.g. exposed via props)

Dialog is making an assumption that depends on other CSS in the project being a certain way that may not always hold true
Devs may disagree with an opinionated technique (e.g. jump avoided but jarring swap of scrollbar may not be desired) and wish to override, but still leverage all the other benefits of Headless + Dialog.

Depending on maintainers' perspective re the presumably-intended behaviour + based on screenshots of it on PC they may wish to classify it as a bug and revisit.

Different technique(s) or additional case handling (e.g. scrollbar, PC, etc.) could be implemented to improve Dialog in this area

Related Ideas & Discussions:

The text was updated successfully, but these errors were encountered:

youssefm · 2022-05-11T17:17:46Z

I just filed this related issue that seems to further support your reasoning:

#1436

RobinMalfait · 2022-05-18T09:53:44Z

Hey! Thank you for your bug report!
Much appreciated! 🙏

This should be fixed by #1457, and will be available in the next release.

You can already try it using:

npm install @headlessui/react@insiders.
npm install @headlessui/vue@insiders.

Can you double check that this is fixed for you if you install the insiders build?

RobinMalfait · 2022-08-22T13:56:59Z

Hey!

Doing some cleanup and haven't heard back from you so therefore going to close this issue. If this is still an issue for you, please open a new issue with a reproduction repo that we can clone and run and I'm happy to take a look!

missouak · 2022-10-06T14:27:41Z

Package: @headlessui/react Version: v1.5.0 (latest at time of writing) Chrome + Windows 11 (this issue affects many others as well; see description + case)

Reproduction URL

Any example of the Dialog component is a valid reproduction: open DevTools and monitor the HTML element while opening a Dialog.

Refer to the implementation in dialog.tsx where the issue behaviour is implemented in a useEffect() preceded by the comment line // Scroll lock:

https://github.com/tailwindlabs/headlessui/blob/main/packages/@headlessui-react/src/components/dialog/dialog.tsx#L247-L270

Issue Description

The current Dialog implementation makes less-than-ideal assumptions re scrollbars + project CSS and when a Dialog/modal is open, it applies a technique that adds an inline overflow: hidden and padding-right (with value based on a calculation of scrollbar width) to the document's <html> tag.

This results in undesired behaviour / jank in different cases especially on Windows PC's where scrollbars are rather visually imposing.

The lack of control for this behaviour (especially the padding) leaves devs without the ability to more elegantly handle scrollbars and/or handle corner cases or conflicts caused by other styles in a given project.

Why is this important?

Scrollbars are a notoriously fickle beast between different OS's and browsers (see: one example among many articles on the subject).

I would argue a good reason to check/switch between Mac + PC when working on front-end projects are the differences in scrollbars between these OS's. Our traffic doesn't always have the same taste in computers vs. many of us web devs :D

Example case:

The following breaks down a single case that is part of a wider issue; refer to linked issue + discussion for related cases.

A straightforward cross-platform-friendly technique to avoid jank during loading + transitions that is particularly gross on Windows is to add overflow-y: scroll to the body tag. This causes browsers on PC's to always display a scrollbar even when the content fits within the viewport (in this case the scrollbar is present but is presented as disabled/inactive).

This technique is in the tailwind-preset.js on several projects I work on and is compatible with many packages/libraries/frameworks to help avoid "jumps" and overall "jank".

However in this case Dialog is the cause of the very problem it is attempting to prevent:

Content behind the Dialog noticeably "jumps" to the left by the width of the scrollbar.

In the screenshot we see padding-right jumping the content by the width of the scrollbar in both of the following cases: when the content is taller than the viewport (i.e. case for y scrollbar), and when it is shorter (i.e. nothing to scroll).

Confirming:

when overflow-y: scroll is removed from the body then Dialog behaves the way that the devs presumably intended (tested on Chrome+PC): no padding or jump is present in the content-fits-window case (no scrollbar visible), and in the content-taller-than-window case (scrollbar visible) the added padding compensates for the scrollbar disappearance resulting from Dialog's addition of overflow: hidden.

The presumably-intended behaviour isn't particularly elegant in the content-taller-than-window-case on PC either:

Windows' imposing scrollbar suddenly disappears and this can result in users' "wtf just blinked"/"jank detection" neurons firing. While a content "jump" is prevented the sudden replacement of the scrollbar with a solid vertical block that doesn't match the app layout isn't much better.

At present, devs have no way to control any of this behaviour if they wish to use Dialog --

Before Dialog is rendered (imposing Windows scrollbar is visible):

With Dialog modal showing (scrollbar suddenly disappears and it ain't pretty):

Expected/Desired Behaviour

Developers require the ability to control the overflow+padding behaviour of Headless Dialog (e.g. exposed via props)

Dialog is making an assumption that depends on other CSS in the project being a certain way that may not always hold true

Devs may disagree with an opinionated technique (e.g. jump avoided but jarring swap of scrollbar may not be desired) and wish to override, but still leverage all the other benefits of Headless + Dialog.

Depending on maintainers' perspective re the presumably-intended behaviour + based on screenshots of it on PC they may wish to classify it as a bug and revisit.

Different technique(s) or additional case handling (e.g. scrollbar, PC, etc.) could be implemented to improve Dialog in this area

Related Ideas & Discussions:

[Bug]: Cannot properly center Headless UI Dialog/Modal due to scrollbar padding #839

Allow to control adding of right padding in Dialog #877

you can fix it by adding to your main stylesheet file the following :
html{
overflow-y: auto!important;
}

willemmulder · 2022-11-09T19:32:13Z

This problem still exists. My page jumps and there is a gap on the right side of the screen. I had this

overflow-y: scroll;

And had to change it into this to fix the problem

overflow-y: scroll !important;
padding: 0px !important;

Anu-cool-007 · 2022-11-12T10:00:00Z

I added the margin to the body instead of HTML which solved the issue.

body {
    margin-left: calc(100vw - 100%);
    /* overflow-y: auto !important; */
}

imclint21 · 2022-11-14T14:17:12Z

Yes the problem still exists:

<html lang="en" style="overflow: hidden; padding-right: 15px;">

It looks like this:

To fix it I did this below, but I would prefer don't have this to do:

html
{
    padding: 0 !important;
}

amaroyche · 2022-11-16T13:42:53Z

Same here, just not having a control over Dialog's addition of overflow: hidden. This is what is the culprit.
Suggesting to solve this and related issues by giving devs a choice to modify this behavior (leaving default as is).

{
    modifyScrollUnderModal: true,
    modifyScrollUnderModalTag: 'html',
    modifyScrollUnderModalStyles: { overflow: 'hidden' }
}

imclint21 · 2022-11-16T13:51:03Z

Same here, just not having a control over Dialog's addition of overflow: hidden. This is what is the culprit.

Suggesting to solve this and related issues by giving devs a choice to modify this behavior (leaving default as is).
{

    modifyScrollUnderModal: true,

    modifyScrollUnderModalTag: 'html',

    modifyScrollUnderModalStyles: { overflow: 'hidden' }

}

Good suggestion

EliBates · 2022-11-21T14:25:33Z

Would also like a way to control this.

dbstjddbwls · 2023-01-26T08:29:51Z

I think this is one of the urgent issues for developers who use headlessui. Has anyone solved this issue?

firxworx · 2023-01-26T14:37:19Z

@RobinMalfait given the comments + activity I think its grounds to reopen this issue?

RobinMalfait · 2023-01-26T14:41:08Z

Can anyone running into this issue open a new issue with a minimal reproduction repo attached that showcases the problem so that we can take a look?

hymair · 2023-02-02T15:05:05Z

Had the same issue on 1.7.4 but upgrading to 1.7.8 fixed it.

aaroncemery · 2023-02-02T23:44:57Z

I'm on 1.7.8 and just ran into this issue.

What i see happening is that the issue is not present for me, but it is for some of the people who were testing.

maximedotair · 2023-02-07T08:37:02Z

Hello ! 1.7.10 and same here

RobinMalfait · 2023-02-07T11:26:47Z

Alright, going to lock this issue. For the people running into this, please open a new issue with a minimal reproduction repo so that we can take a look. Otherwise it is impossible for us to debug what's going on.

RobinMalfait self-assigned this May 18, 2022

RobinMalfait added the Needs more info label May 18, 2022

crezra mentioned this issue Aug 9, 2022

Scroll native on close oneduo/nova-file-manager#4

Closed

RobinMalfait closed this as completed Aug 22, 2022

tailwindlabs locked as resolved and limited conversation to collaborators Feb 7, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Dialog add-padding-to-html technique for scrollbar is problematic and there's no way to control it #1319

Dialog add-padding-to-html technique for scrollbar is problematic and there's no way to control it #1319

firxworx commented Apr 11, 2022 •

edited

Loading

youssefm commented May 11, 2022

RobinMalfait commented May 18, 2022

RobinMalfait commented Aug 22, 2022

missouak commented Oct 6, 2022 •

edited

Loading

willemmulder commented Nov 9, 2022

Anu-cool-007 commented Nov 12, 2022

imclint21 commented Nov 14, 2022

amaroyche commented Nov 16, 2022

imclint21 commented Nov 16, 2022

EliBates commented Nov 21, 2022

dbstjddbwls commented Jan 26, 2023

firxworx commented Jan 26, 2023

RobinMalfait commented Jan 26, 2023

hymair commented Feb 2, 2023 •

edited

Loading

aaroncemery commented Feb 2, 2023 •

edited

Loading

maximedotair commented Feb 7, 2023

RobinMalfait commented Feb 7, 2023

Dialog add-padding-to-html technique for scrollbar is problematic and there's no way to control it #1319

Dialog add-padding-to-html technique for scrollbar is problematic and there's no way to control it #1319

Comments

firxworx commented Apr 11, 2022 • edited Loading

youssefm commented May 11, 2022

RobinMalfait commented May 18, 2022

RobinMalfait commented Aug 22, 2022

missouak commented Oct 6, 2022 • edited Loading

willemmulder commented Nov 9, 2022

Anu-cool-007 commented Nov 12, 2022

imclint21 commented Nov 14, 2022

amaroyche commented Nov 16, 2022

imclint21 commented Nov 16, 2022

EliBates commented Nov 21, 2022

dbstjddbwls commented Jan 26, 2023

firxworx commented Jan 26, 2023

RobinMalfait commented Jan 26, 2023

hymair commented Feb 2, 2023 • edited Loading

aaroncemery commented Feb 2, 2023 • edited Loading

maximedotair commented Feb 7, 2023

RobinMalfait commented Feb 7, 2023

firxworx commented Apr 11, 2022 •

edited

Loading

missouak commented Oct 6, 2022 •

edited

Loading

hymair commented Feb 2, 2023 •

edited

Loading

aaroncemery commented Feb 2, 2023 •

edited

Loading