fix(modal): prevent ion-content collapsing at content-based heights - #31413
fix(modal): prevent ion-content collapsing at content-based heights#31413brandyscarney wants to merge 21 commits into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
| } | ||
|
|
||
| const height = getComputedStyle(modal).getPropertyValue('--height').trim(); | ||
| return CONTENT_SIZED_HEIGHTS.includes(height); |
There was a problem hiding this comment.
Yes this PR is still a work in progress! 🙂
thetaPC
left a comment
There was a problem hiding this comment.
Mainly waiting on the breaking change question to be resolved.
| * overlay, giving the wrapper's flex children something to shrink | ||
| * toward so `ion-content` scrolls instead of overflowing. | ||
| */ | ||
| --max-height: 100%; |
There was a problem hiding this comment.
Is this considered a breaking change since consumers are used to having it as auto?
There was a problem hiding this comment.
No, I wouldn't consider this a breaking change because auto was never a valid value for max-height in the first place.
auto isn't listed as a valid value in the docs for max-height. As a result, max-height: auto is invalid and the property fell back to its initial value, none. If you inspect any .modal-wrapper prior to this change you will see the max-height is computed as none:
That means the actual change is none → 100%.
From there, the cases where the computed value actually changes are all cases that were already broken:
--height: 100%(the default) and every built-in variant (calc(100% - 40px), sheet, card, inset heights) are all ≤ 100%, so the clamp has no effect and rendering remains identical.- The iOS card modal sets
--max-height: 1000pxexplicitly, so it's unaffected. - A
--heighttaller than the overlay (e.g.800pxin a600pxviewport, or a content-based height with tall content) previously overflowed the host. Since:hosthascontain: strict, that overflow was clipped at both the top and bottom, leaving some of the content unreachable. Clamping the height soion-contentscrolls instead is a fix.
Anyone who explicitly sets --max-height: auto still ends up with none, since their override is just as invalid as the old default was. And setting --max-height to anything else will still take precedence.
Additionally, CSS variable defaults are not tracked in the public API. api.txt records CSS custom property names only, so there are no generated docs or API diff changes.
ShaneK
left a comment
There was a problem hiding this comment.
Awesome work! Looks really good overall, and the test page covers a lot of ground. I did find a few cases where the content still collapses though. Setting --height from an ancestor rule, using --height: AUTO, and reconnecting across a height change all miss the class and leave a header-only modal, so the original bug is still reachable. Details in the comments, and let me know if I'm missing something!
| * Override the minimum height a flex item gets, which defaults to | ||
| * use the height of its own content. Without this, a modal sized |
There was a problem hiding this comment.
| * Override the minimum height a flex item gets, which defaults to | |
| * use the height of its own content. Without this, a modal sized | |
| * Override the minimum height a flex item gets, which defaults to | |
| * the height of its own content. Without this, a modal sized |
That fixes these two lines and the dropped word. There are 19 in total though, all in the new comment blocks, spread across this file, the new test page, modal.scss and the testing stylesheet. The root .editorconfig sets trim_trailing_whitespace, and nothing catches it since prettier's globs skip scss and css.
There was a problem hiding this comment.
Just FYI I found several other files with trailing whitespace by running npx editorconfig-checker -disable-indentation -disable-indent-size -disable-insert-final-newline -disable-end-of-line -disable-max-line-length -exclude components.d.ts src scripts. If this is something we want to enforce against we should have it covered by the linter.
There was a problem hiding this comment.
Makes sense to cover it by a linter if you want since the .editorconfig declares it. Ideally our linters would be aligned
4da3287 to
710ca95
Compare
|
|
||
| // The default --max-height keeps a content-sized modal inside the | ||
| // overlay. Rounded up by one, since the clamp lands on a sub-pixel. | ||
| expect(await getWrapperHeight(page)).toBeLessThanOrEqual(viewport.height + 1); |
There was a problem hiding this comment.
This one and the --max-height: 50% test below it only cap the height, they never floor it. A modal that collapsed back to a 44px header satisfies toBeLessThanOrEqual(viewport + 1), and scrollHeight > clientHeight is true at clientHeight: 0 as well, so the original bug passes both. Could they get a lower bound?
ShaneK
left a comment
There was a problem hiding this comment.
Oops, meant to send the last one as request changes. Really it's just that one blocking change and the others are 🤷♂️
Issue number: resolves #31149
What is the current behavior?
Setting
--heightto any of the following on anion-modalcontaining anion-contentresults in theion-contentcollapsing to0height:auto,fit-content,min-content, ormax-content.What is the new behavior?
--heightis set toauto,fit-content,min-content,ormax-contentand styles theion-content,ion-navand.ion-pageappropriately if so--heightonion-modalto dynamically add and remove the class that sizes theion-contentto its content--max-heightto100%which allows the content to scroll instead of overflowing and being clippedion-modalhas--heightset--heightscenariosDoes this introduce a breaking change?
Other information
Dev build:
9.0.1-dev.11788212611.154b1596Preview: Modal: Content Height
Docs PR: ionic-team/ionic-docs#4689