Autogrow QInput can fail in some cases
See original GitHub issueWhat happened?
I noticed sometimes my autogrow QInputs were not autogrowing, and would actually have the text half the height it should be (so it was chopped through the middle):
This is where we are using the QInput:
<QInput
ref="input"
v-bind="$attrs"
:model-value="modelValue"
type="textarea"
:input-style="$attrs['input-style'] || 'min-height: 100px'"
autogrow
bottom-slots
hide-hint
>
$attrs['input-style']
is set as min-height: unset; max-height: 320px;
in this particular case.
What did you expect to happen?
The auto grow should work and it should not be chopped off…
Reproduction URL
https://codepen.io/nicksellen-the-decoder/pen/jOzoWgX
How to reproduce?
- go to the codepen link in firefox and make sure there is enough vertical height in your browser not to need a scrollbar
- type in the top input box
- notice it doesn’t autogrow (for me anyway…)
- type in the bottom input box
- notice it does autogrow
Flavour
Quasar CLI with Webpack (@quasar/cli | @quasar/app-webpack)
Areas
Components (quasar)
Platforms/Browsers
Firefox
Quasar info output
Operating System - Linux(5.19.3-arch1-1) - linux/x64
NodeJs - 16.15.1
Global packages
NPM - 8.11.0
yarn - 1.22.19
@quasar/cli - undefined
@quasar/icongenie - Not installed
cordova - Not installed
Important local packages
quasar - 2.7.5 -- Build high-performance VueJS user interfaces (SPA, PWA, SSR, Mobile and Desktop) in record time
@quasar/app-webpack - 3.5.7 -- Quasar Framework App CLI with Webpack
@quasar/extras - 1.14.3 -- Quasar Framework fonts, icons and animations
eslint-plugin-quasar - 1.1.0 -- Official ESLint plugin for Quasar
vue - 3.2.37 -- The progressive JavaScript framework for building modern web UI.
vue-router - 4.1.2
pinia - Not installed
vuex - Not installed
electron - Not installed
electron-packager - Not installed
electron-builder - Not installed
@babel/core - 7.18.6 -- Babel compiler core.
webpack - 5.73.0 -- Packs CommonJs/AMD modules for the browser. Allows to split your codebase into multiple bundles, which can be loaded on demand. Support loaders to preprocess files, i.e. json, jsx, es7, css, less, ... and your custom stuff.
webpack-dev-server - 4.9.2 -- Serves a webpack app. Updates the browser on changes.
workbox-webpack-plugin - 6.5.3 -- A plugin for your Webpack build process, helping you generate a manifest of local files that workbox-sw should precache.
register-service-worker - 1.7.2 -- Script for registering service worker, with hooks
typescript - 4.5.5 -- TypeScript is a language for application scale JavaScript development
@capacitor/core - Not installed
@capacitor/cli - Not installed
@capacitor/android - Not installed
@capacitor/ios - Not installed
Quasar App Extensions
@quasar/quasar-app-extension-dotenv - 1.1.0 -- Load .env variables into your quasar project
Networking
Host - anna
wlan0 - 192.168.1.93
br-5e313df0f10f - 172.18.0.1
Relevant log output
No response
Additional context
It was introduced in this PR https://github.com/quasarframework/quasar/pull/13237
I think there two possible solutions:
1. always set overflow: hidden
on the input when using autogrow
using input-style="input: hidden;"
works for me locally and in the pen, maybe it can be set inside QInput component
2. change the ordering of the calls
I tried editing the quasar source locally, and in my application the issue was resolved by switching the order, so the call to set overflow hidden is done first, from:
parentStyle.marginBottom = (inp.scrollHeight - 1) + 'px'
inp.style.height = '1px'
inp.style.overflow = 'hidden'
to:
inp.style.overflow = 'hidden'
parentStyle.marginBottom = (inp.scrollHeight - 1) + 'px'
inp.style.height = '1px'
In my exploring I also noticed the issue was resolved when I put a console.log
line in various places in that bit of code, and it didn’t occur when the whole browser window could scroll… so I think there is a subtle timing issue in firefox with the browser redrawing/recalculating the scrollHeight…
I was consistently getting a height set of 15px, even when the scrollHeight was more when I logged it…
Issue Analytics
- State:
- Created a year ago
- Comments:10 (5 by maintainers)
Top GitHub Comments
Fix will be available in v2.8.3
Yes, in next release