-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
fix(form-textarea): improved computedHeight calculation when in auto resize mode #3012
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Codecov Report
@@ Coverage Diff @@
## dev #3012 +/- ##
========================================
+ Coverage 98.2% 98.2% +<.01%
========================================
Files 205 205
Lines 3685 3686 +1
Branches 1105 1105
========================================
+ Hits 3619 3620 +1
Misses 46 46
Partials 20 20
Continue to review full report at Codecov.
|
if (!isVisible(el)) { | ||
return null | ||
} | ||
|
||
// Remember old height (includes `px` units) and reset it temporarily to `auto` | ||
const oldHeight = el.style.height | ||
el.style.height = 'auto' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Part of the reason for using auto
was that it would trigger an immediate content reflow of the <textarea>
, as setting it to any other value may not trigger a reflow/recalculation until the next animation frame (which would generally happen after the rest of the computed property has completed executing) so the scrollHeight may not be actually be updated until well after the value is used.
@Istador do you have an example of where
|
Here is an example using the new code from this PR, with And the old code with the same text typed in (Also on chrome 72): Note the extra blanks line in the first example using the code from this PR that sets to So my suggestion would be to veto the change using the calculated |
Needed for proper reflow recalculation of the `scrollHeight`
The real issue with the extra line (or lack of in some situations) is due to the effect the scroll bar has on the maximum width of the content. i.e. when calculating the required height, there is no scrollbar taken into account. By adding |
|
For |
Description of Pull Request:
computedHeight
is used, whenmax-rows
is given to anb-form-textarea
to calculate the auto height.1. fix: not subtracting border width from scrollHeight
scrollHeight
contains only the padding and not the border.This resulted in an incorrect calculation of
contentRows
(float instead of int) and lead to an visible vertical scroll bar, even whenmax-rows
haven't been reached yet.2. fix: respecting boxSizing in height calculationDepending on boxSizing, the height of the element contains the padding and border (EDIT (by TM): Bootstrap CSS always sets every element tobox-sizing: border-box
) or not (box-sizing: content-box
).border-box
, so this extra test would only generate overhead that is not needed.3. fix: setting height temporary tominHeight
instead of'auto'
Setting it toauto
might result in a height that is bigger than 2 content rows.This is bad because when the content height is lower than this height, then
scrollHeight
is affected by this. It effectively results in theauto
-height being theminHeight
, therefore the textarea is bigger than it should be.I only tested chrome, firefox and waterfox on desktop. Because one of the lines I changed was marked as "browser dependant" it should better be tested thoroughly - especially on mobile browsers.
PR checklist:
What kind of change does this PR introduce? (check at least one)
Does this PR introduce a breaking change? (check one)
If yes, please describe the impact:
The PR fulfills these requirements:
dev
branch, not themaster
branchfixes #xxxx[,#xxxx]
, where "xxxx" is the issue number)and adding a new feature, break them into separate PRs if at all possible.
Conventional Commits naming convention (i.e.
"fix(alert): not alerting during SSR render", "docs(badge): Updated pill examples, fix typos",
"chore: fix typo in docs", etc). This is very important, as the
CHANGELOG
is generatedfrom these messages.
If new features/enhancement/fixes are added or changed:
package.json
for slot andevent changes)
keyboard only users? clickable items should be in the tab index, etc)
If adding a new feature, or changing the functionality of an existing feature, the PR's
description above includes:
suggestion issue first and wait for approval before working on it)