fix(modal): use resizeobserver#2969
Conversation
lubber-de
added
type/bug
| overscroll-behavior: @overscrollBehavior; | ||
| } | ||
| .modals.dimmer { | ||
| scrollbar-gutter: stable; |
There was a problem hiding this comment.
Why is this needed, will it imply scrollbars always shown? In the PR description there is mentioned something with detachable: false, is this related?
There is mentioned "The dimmers scrollbar will now also not trigger content movement anymore". I tried the demo (in Firefox) and when the textarea is resized, the content is unexpectedly always scrolled to the top when resized.
There was a problem hiding this comment.
Why is this needed, will it imply scrollbars always shown? In the PR description there is mentioned something with
detachable: false, is this related?
No, the scollbars are not always shown. This will occupy a possible shown scrollbar margin, but will not show an empty scrollbar in case the element is not body and no overflow happens
See example at #679
The problem with "detachable:false" in case context is body, is that body does not support this feature (scrollbar-gutter) (firefox+safari don't care at all, because those have their own implemented "overlay scrollbar feature")
Because of this the parent element would need to get scrollbar-gutter:stable instead. This basically works, but as the html element does not have any dimmer color set, it would display a white empty scrollbar in case the modal fits the screen. It also left a second scrollbar when closing the modal...very ugly
If you want to see/try my hack:
The jsfiddle does only barely show the issue as jsfiddle has a black parent background which the html element inside the iframe inherits (so the permanent occupied right scrollbar area is black, but still not the "dimmer black"
https://jsfiddle.net/lubber/cyjnta1d/3/
I also tried messing around with the dimmer animation to also make the html element inherits that, but the transition was not in sync and the code bloated away as we would need to support every possible dimmer variation just for that.
We would also need to support non body context elements... lots of code and cases for, IMHO, little benefit
@supports (scrollbar-gutter: stable) and (selector(:has(.f))) {
html:has(body.undetached.dimmable) {
overflow: auto;
}
html:has(body.undetached.dimmable.dimmed) {
overflow: auto;
scrollbar-gutter: stable;
}
body.undetached.dimmable.dimmed.dimmed {
overflow: hidden;
}
}There is mentioned "The dimmers scrollbar will now also not trigger content movement anymore".
What was meant by this is #679 (comment)
I tried the demo (in Firefox) and when the textarea is resized, the content is unexpectedly always scrolled to the top when resized.
mmh, thats the in between discussion where i was not able to reproduce this.
The modal is only put to the top when the it detects the current modals size would not fit (thus adds the scrolling class). Whenever i am able to reproduce this, i take a look again and prepare a separate PR as some browser (firefox) measurements seem to provide questionable values inside module.can.fit() in some situations
There was a problem hiding this comment.
Thank you for your detailed explanation and your work on this topic.
I tried the demo (in Firefox) and when the textarea is resized, the content is unexpectedly always scrolled to the top when resized.
mmh, thats the in between discussion where i was not able to reproduce this.
I meant the demo of/from this PR - https://jsfiddle.net/lubber/drb6fpog/1/
Steps to reproduce:
- open the https://jsfiddle.net/lubber/drb6fpog/1/ in Firefox
- resize the textarea vertically by dragging the right bottom corner to make the modal larger than the viewport
- scroll down the modal
- now try to resize the dropdown by dragging the right bottom corner
- the modal is unexpectedly scrolled to the top immediately - I would expect no scroll/jump
- also notice when you click the textarea resize corner and have F12 "Inspector" tab open,
div.dimmer div.modaldiv in the inspector tab flashes yellow meaning something has changed, but I did not noticed/see any real css/class changes, meaning some same value is set from a mutation observer or even possibly worse, some value is set and immediatelly changed back
There was a problem hiding this comment.
i take a look into this
lubber-de
added
the
state/awaiting-docs
# Conflicts: # src/definitions/modules/modal.less
# Conflicts: # src/definitions/modules/modal.less
lubber-de
added
lang/javascript
# Conflicts: # src/definitions/modules/modal.js
| if (getScrollingMargins) { | ||
| if (module.can.useFlex()) { | ||
| $module.addClass(className.scrolling); | ||
| scrollingTop = parseInt($module.css('top').replace(/[^\d.]/g, ''), 10) || 0; |
There was a problem hiding this comment.
Is the top css set by us - if yes, we should know the format and something like .replace(/px$/, '') would be much more cleaner.
|
I have tested the JS and the CSS from the jsfiddle and it does indeed fix the "resize textarea issue in Firefox". @lubber-de might you update jsfiddle (https://jsfiddle.net/lubber/drb6fpog/1/ ATM) to represent the latest compiled CSS? I am unable to review this PR at the code level, but I would be happy to test all of my reported issues. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughModal layout handling now observes element resizing, avoids refreshes for hidden modals, incorporates scrolling margins into fit calculations, and refines dimmer sizing, cleanup, positioning, and scrolling styles. ChangesModal layout behavior
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant ModalElement
participant ResizeObserver
participant ModalModule
participant Dimmer
ModalElement->>ResizeObserver: report resize
ResizeObserver->>ModalModule: call refresh()
ModalModule->>ModalElement: recalculate cached layout
ModalModule->>Dimmer: update height and positioning
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
3 participants
Description
This PR changes the refresh behavior of modals to recalculate their dimensions. The previous logic was checking for DOM-Nodes only, but the only need was to know when the modal gets resized.
This now works in Firefox as well.
The dimmers scrollbar will now also not trigger content movement (#679) anymore when used in modern browsers. However this does not nicely work when
detachable: falseis used (tried a lot dealing with complicated tricks using the html tag as the scrollbar-gutter property does not work for the body element out of the box but it always left a white scrollbar even if the modal fitted into the viewport, so i decided to live with that limitation for now)As this feature will always occupy a possible scrollbar width (even if a scrollbar won't appear), only modals which are supposed to be scrollable (by interaction or application logic while the modal is shown) should be given a new css class
scrollableto gain the fix. Otherwise every modal wouldnt be centered anymore.I also adjusted the dimmer positioning and close icon appearance when
detachable:falsein a custom context is usedTestcase
Resize the textarea, a scrollbar should appear to the modals dimmer
https://jsfiddle.net/lubber/drb6fpog/4/
Closes
#679
#2476
#2920
Summary by CodeRabbit
Summary by CodeRabbit
scrollbar-guttersupport, and improved scrolling modal overflow/spacer handling for better browser compatibility.