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

Textinput: height not correctly calculated in Firefox #6179

Closed
jhogervorst opened this Issue Jul 16, 2013 · 2 comments

Comments

Projects
None yet
1 participant
@jhogervorst
Contributor

jhogervorst commented Jul 16, 2013

Textareas are automatically resized (in height) to prevent scrollbars from appearing, using this code (lines 61-65 in js/widgets/forms/autogrow.js):

this.element.css({
    height: "auto"
}).css({
    height: this.element[0].scrollHeight + 15 + "px"
});

The scrollHeight property of an element is expected to be the height of the content of the element (text in the textarea) and the padding before and after the content (padding-top and padding-bottom of the textarea). The problem is that, in Firefox, padding heights are not included in the scrollHeight if no scrollbar is visible.

This calculated height is assigned to the element using the jQuery .css() method, by directly updating the CSS height property. Because of the border-box box-sizing method, the element is displayed as if the height included the border + padding + content.

This means that we're assigning the content height (from scrollHeight) as if it were the border + padding + content height (thus removing the border and padding height from the content height, making the element taller than intended).

This is a known problem:

@jhogervorst

This comment has been minimized.

Show comment
Hide comment
@jhogervorst

jhogervorst Jul 16, 2013

Contributor

I'll submit a PR as soon as PR #6180 is accepted (that solves issue #6178), as the fix for this issue would conflict with the fix for the other issue (if they're submitted at the same time).

Contributor

jhogervorst commented Jul 16, 2013

I'll submit a PR as soon as PR #6180 is accepted (that solves issue #6178), as the fix for this issue would conflict with the fix for the other issue (if they're submitted at the same time).

@jhogervorst

This comment has been minimized.

Show comment
Hide comment
@jhogervorst

jhogervorst Aug 6, 2013

Contributor

I'll submit a PR as soon as PR #6290 is accepted (that solves issue #5688), as the fix for this issue would conflict with the fix for the other issue (if they're submitted at the same time).

Contributor

jhogervorst commented Aug 6, 2013

I'll submit a PR as soon as PR #6290 is accepted (that solves issue #5688), as the fix for this issue would conflict with the fix for the other issue (if they're submitted at the same time).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment