442228 - Implement CSS property to control element resizability

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, enhancement)

Description

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

CSS3 'resize' property:
http://www.w3.org/TR/2004/CR-css3-ui-20040511/#resizing
The document is in "Candidate Recommendation" state.

I add Bug 410988 and Bug 167951 as dependent from this bug, because if resize property will be implemented probably the behaviour described in those bugs should be off by default.

Comment 1

[Martijn Wargers (dead)]

Bug 167951 just got blocking1.9.2+, it would be great if this bug would be fixed, it would automagically fix bug 167951 and bug 410988 too.

Comment 2

[chAlx]

Isn't it easier and more convenient way to add firstly the textarea resizer itself (bug 167951) and to attach then the CSS property to control it?

Comment 3

[Neil Deakin]

Attachment: part 1: implement css resize property

Comment 4

[Neil Deakin]

Attachment: part 2: implement <resizer> as part of the scroll frame

This implements the resize, but it may be better as -moz-resize, as this implementation uses a <resizer> which just adjusts the style.width and style.height on the element when it's resized. The spec says that the resize should adjust an internal scaling factor instead.

Some things still remain:

- I couldn't get the minimum width/height to work for html elements (so that the resize can't adjust below the resizer's size), so I just set a min-width/min-height on the textarea. This isn't ideal.
- there aren't any images provided for the horizontal or vertical only resizers.

Comment 5

[Nochum Sossonko [:Natch]]

One weird thing I noticed, go to http://jsbeautifier.org/ and drag the resizer all the way to the left, the text in the box shifts all the way to the right weirdly even though the actual textbox doesn't change...

Comment 6

[Philip Chee]

Natch, If you look at it in the DOM inspector it's actually <fieldset><div><textarea/></div></fieldset> plus some funky CSS. So the textbox is actually changing width but what you are seeing are the borders of the containing <div>.

The same behaviour occurs with an un-patched build and the Resize Text Area extension.

Comment 7

[Neil Deakin]

Attachment: implement -moz-resize property

Decided to just -moz-resize property due to differences.

Comment 8

[Neil Deakin]

Attachment: nsGfxScrollFrame.cpp and css changes as well as tests

Comment 9

[Neil Deakin]

Attachment: nsResizerFrame.cpp changes

This patch makes several fixes:
 - use the dir attribute for all resizes
 - don't allow a resize smaller than the <resizer> size
 - skip over native anonymous nodes when looking for a parent to resize

Comment 10

[Neil Deakin]

Builds are at https://build.mozilla.org/tryserver-builds/[e-mail]-resizerany2/

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 425495 [details] [diff] [review]
implement -moz-resize property

It's not intuitively clear to me that the dynamic change handling requires frame reconstruction rather than just reflow, although I certainly don't object to it requiring frame reconstruction if that makes the implementation simpler.

r=dbaron

Comment 12

[[e-mail]]

Comment on attachment 425502 [details] [diff] [review]
nsResizerFrame.cpp changes

>+    nsIContent* parent = mContent;
>+    // skip over native anonymous content
>+    while ((parent = parent->GetParent()) && parent->IsInNativeAnonymousSubtree());
>+    return parent;
Should this be using FindFirstNonNativeAnonymous?

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

+    if (kid != mScrolledFrame &&
+        (!hasResizer || kid != mScrollCornerBox)) {

This would be a bit clearer if you wrote
    if (kid == mScrollCornerBox && hasResizer) {
      // skip, this will be drawn later on top of the scrolled content
      continue;
    }

+      case NS_STYLE_RESIZE_HORIZONTAL:
+        dir.AssignLiteral("right");
+        break;

This should probably be "left" if the vertical scrollbar is on the left?

Do we really need nsGfxScrollFrameInner::GetResizerSize? Can't we just assume that the resizer is exactly a square the width of a scrollbar?

+    if (aContentArea.x != aScrollArea.x || scrollbarOnLeft) {

Then we wouldn't need to change this, I guess...

+      // scrollbar (if any) on top
+      r.y = aContentArea.y;
+      r.height = PR_MAX(resizerSize.height, aScrollArea.y - aContentArea.y);
+      NS_ASSERTION(r.height >= 0, "Scroll area should be inside client rect");

We probably should just replace this with NS_ERROR since we never place the scrollbar on top.

Comment 14

[[e-mail]]

(In reply to comment #13)
> +      case NS_STYLE_RESIZE_HORIZONTAL:
> +        dir.AssignLiteral("right");
> +        break;
> This should probably be "left" if the vertical scrollbar is on the left?
Better still, make resizers support "end" (c.f. RTL-aware "bottomend").

Comment 15

[Neil Deakin]

Attachment: updated scrollframe and tests patch

> Do we really need nsGfxScrollFrameInner::GetResizerSize? Can't we just assume
> that the resizer is exactly a square the width of a scrollbar?

I adjusted the code a bit. I could assume the width and height are equal but it only saves line of code, so I'm not sure it's worthwhile. 

> +    if (aContentArea.x != aScrollArea.x || scrollbarOnLeft) {
> 
> Then we wouldn't need to change this, I guess...

It's still needed in the case where a resizer is present but no scrollbar.

Comment 16

[Neil Deakin]

Attachment: updated resizerframe patch, already reviewed

Comment 17

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 427391 [details] [diff] [review]
updated scrollframe and tests patch

sr=dbaron.  Sorry for the delay getting to this.

(I'm actually not sure why this patch needs sr.)

Comment 18

[d]

Shouldn't this be checked in?

Comment 19

[Neil Deakin]

Checked in:

http://hg.mozilla.org/mozilla-central/rev/98f0a163b0fe
http://hg.mozilla.org/mozilla-central/rev/c7e2dc67f36b
http://hg.mozilla.org/mozilla-central/rev/1f70f80b8a7e

Comment 20

[Neil Deakin]

This isn't actually fixed. I haven't implemented the css3 resize property. But I've filed a new bug 553576 to cover that instead and will change this one into what has been implemented.

Comment 21

[d]

If "-moz-resize" will be in a proper release, it will need some documentation at https://developer.mozilla.org/en/CSS_Reference/Mozilla_Extensions.

Good work on getting this implemented!

Comment 22

[[e-mail]]

The "square" resizer on an empty textarea looks odd!

I was trying to update the Modern CSS to work with this. Obviously the first hurdle (which was readily resolved) was that it hasn't been updated for -moz-locale-dir. I then noticed that the size oddly changed when the textarea gained focus. I was able to work around this by specifying minimum dimensions for scrollbars. I did however have one final problem, and that is that resizers and scrollcorners have different background colours; in fact resizers are normally transparent, so how can I give them a background colour but only when they are in a textarea?

Comment 23

[Neil Deakin]

You should be able to use in resizer.css:

  html|textarea resizer { ... }

Comment 24

[Boris Zbarsky [:bzbarsky]]

Can that use the '>' combinator instead?  Or is the resizer not a direct child of the textarea?

Comment 25

[Neil Deakin]

Yes, that what I had intended.

Comment 26

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Oh goodness, can we get this on 1.9.2?

Comment 27

[d]

(In reply to comment #26)
> Oh goodness, can we get this on 1.9.2?

Since Firefox.next will bring major UI changes, it's would be wise to wait with it. Also, in my opinion, the resizer for Mac should be redesigned (same one as on Windows perhaps?). It looks good classic white forms/textareas, but as soon as you use any background colors, it looks really bad. It also seems to separate from the border of the form itself when certain CSS is applied. The native Mac resizer works great in the edges of windows, but not where it's mixed with a non-white background color.

I think the resizer should always try to blend in with it's background somehow, which can be achieved with opacity or half-transparent colors. This is already the case with the Windows-version (or at least it doesn't cover a whole square). I'd almost say we should not include this by default on Mac if the style isn't changed. I might file a separate bug on this, but, do you agree?

Comment 28

[Eric Shepherd [:sheppy]]

Documented:

https://developer.mozilla.org/en/CSS/-moz-resize

Comment 29

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This patch added a new reftest directory in layout/xul/base/reftest/ but didn't add those reftests to the toplevel manifest, so they were never run in our automated testing.  I just did that:
https://hg.mozilla.org/integration/mozilla-inbound/rev/139eed687d77

Comment 30

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Reftest fails on Android:
https://hg.mozilla.org/integration/mozilla-inbound/rev/1b73567f747b
I think because it assumes native theme support.

Comment 31

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

http://hg.mozilla.org/mozilla-central/rev/1b73567f747b