Bug 135335 – `resize` treats `width` and `height` as minimum dimensions

• Component: CSS
• Status: RESOLVED FIXED

[Lea Verou]

(Surprised this isn’t already reported but did a lot of searching and couldn’t find anything so filing just in case. Sorry if dupe!)

Yes, I know that this is technically allowed in css3-ui ("The user agent may restrict the resizing range to something suitable, such as between the original formatted size of the element, and large enough to encompass all the element's contents."), but this behavior is seriously crippling the usefulness of the resize property. 

A quick search reveals quite a few authors scratching their heads about this issue, for example (top 5):

http://stackoverflow.com/questions/12985133/resize-a-div-to-smaller-than-its-declared-size
http://stackoverflow.com/questions/18178301/how-can-i-use-css-resize-to-resize-an-element-to-a-height-width-less-than-init
http://stackoverflow.com/questions/15108716/how-to-resize-div-to-less-than-its-initial-width-height
http://stackoverflow.com/questions/7197136/using-css-to-resize-a-div-to-a-dimension-smaller-than-its-current-width-and-he
http://stackoverflow.com/questions/15766784/css-resize-min-width

Firefox only restricts it to the min-width/min-height, or if those are not set, to the dimensions of the resizer (roughly 15px by 15px).

Chrome does the same as WebKit, but it’s a confirmed bug they are about to fix: https://code.google.com/p/chromium/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Pri%20M%20Iteration%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort=&id=94583

[Sam]

This is still unfixed in Safari

[Radar WebKit Bug Importer]

<rdar://problem/55189847>

[Simon Fraser (smfr)]

Relevant chromium issue: https://bugs.chromium.org/p/chromium/issues/detail?id=94583

[Simon Fraser (smfr)]

And the final commit: https://chromium.googlesource.com/chromium/src.git/+/7e189bf28fd3f622943d7161e2fdc1f2568a6ea5

[Michal]

Hello, is this issue planned to fix it? I would really appreciate it. Thank you for your answer. :)

[Tim Nguyen (:ntim)]

I'll take this.

[Tim Nguyen (:ntim)]

Created attachment 456907 [details]
Patch

[Tim Nguyen (:ntim)]

Created attachment 456909 [details]
Patch

[Tim Nguyen (:ntim)]

Comment on attachment 456909 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=456909&action=review

> LayoutTests/fast/css/resize-orthogonal-containing-block.html:45
> +}, "Test for resizing the TEXTAREA below its initial size and with orthogonal containing block.");

It should say "the box"

[Simon Fraser (smfr)]

Comment on attachment 456909 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=456909&action=review

> Source/WebCore/rendering/RenderLayer.cpp:2760
> +    // Match Firefox and Chrome, you cannot resize below this value.
> +    int strictMinimumSize = 15;

Does this work if there are custom scrollbars with a larger width/height? Seems like this needs to be some minimum size plus non-overlay scrollbar width.

[Tim Nguyen (:ntim)]

Created attachment 456953 [details]
Patch

[Tim Nguyen (:ntim)]

Created attachment 456954 [details]
Patch

[Simon Fraser (smfr)]

Comment on attachment 456954 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=456954&action=review

> Source/WebCore/rendering/RenderLayer.cpp:2750
> +    auto resizerRect = ensureLayerScrollableArea()->overflowControlsRects().resizer;

If this element isn't scrollable we shouldn't trigger creation of a RenderLayerScrollableArea here. Also overflowControlsRects() exists on RenderLayer so we should just call that.

[Tim Nguyen (:ntim)]

Created attachment 456962 [details]
[fast-cq] Patch

[Tim Nguyen (:ntim)]

Comment on attachment 456962 [details]
[fast-cq] Patch

I'll land this myself

[Tim Nguyen (:ntim)]

Committed r292559 (249397@trunk): <https://commits.webkit.org/249397@trunk>

[Simon Fraser (smfr)]

*** Bug 72948 has been marked as a duplicate of this bug. ***