Last Comment Bug 442228 - Implement CSS property to control element resizability
: Implement CSS property to control element resizability
Status: RESOLVED FIXED
: css3, dev-doc-complete
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
: -- enhancement with 10 votes (vote)
: mozilla1.9.3a4
Assigned To: Neil Deakin
:
: Jet Villegas (:jet)
Mentors:
http://www.w3.org/TR/2004/CR-css3-ui-...
Depends on: 553986 1186140 553796 554810
Blocks: 410988 1280920 167951 553576 553937
  Show dependency treegraph
 
Reported: 2008-06-27 04:51 PDT by Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)
Modified: 2016-06-20 07:38 PDT (History)
36 users (show)
roc: blocking1.9.2-
roc: wanted1.9.2-
roc: blocking1.9.1-
roc: wanted1.9.1-
enndeakin: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
part 1: implement css resize property (16.14 KB, patch)
2009-12-24 08:10 PST, Neil Deakin
no flags Details | Diff | Splinter Review
part 2: implement <resizer> as part of the scroll frame (27.12 KB, patch)
2009-12-24 08:15 PST, Neil Deakin
no flags Details | Diff | Splinter Review
implement -moz-resize property (16.22 KB, patch)
2010-02-05 10:46 PST, Neil Deakin
dbaron: review+
Details | Diff | Splinter Review
nsGfxScrollFrame.cpp and css changes as well as tests (26.21 KB, patch)
2010-02-05 10:49 PST, Neil Deakin
no flags Details | Diff | Splinter Review
nsResizerFrame.cpp changes (6.24 KB, patch)
2010-02-05 10:52 PST, Neil Deakin
neil: review+
Details | Diff | Splinter Review
updated scrollframe and tests patch (26.11 KB, patch)
2010-02-17 11:47 PST, Neil Deakin
roc: review+
dbaron: superreview+
Details | Diff | Splinter Review
updated resizerframe patch, already reviewed (6.24 KB, patch)
2010-02-17 11:48 PST, Neil Deakin
enndeakin: review+
Details | Diff | Splinter Review

Description Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m) 2008-06-27 04:51:16 PDT
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 [:mwargers] (not working for Mozilla) 2009-06-24 09:46:35 PDT
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 2009-06-25 07:57:54 PDT
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 2009-12-24 08:10:04 PST
Created attachment 419124 [details] [diff] [review]
part 1: implement css resize property
Comment 4 Neil Deakin 2009-12-24 08:15:11 PST
Created attachment 419126 [details] [diff] [review]
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] 2009-12-24 10:31:11 PST
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 2009-12-24 11:12:59 PST
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 2010-02-05 10:46:25 PST
Created attachment 425495 [details] [diff] [review]
implement -moz-resize property

Decided to just -moz-resize property due to differences.
Comment 8 Neil Deakin 2010-02-05 10:49:35 PST
Created attachment 425499 [details] [diff] [review]
nsGfxScrollFrame.cpp and css changes as well as tests
Comment 9 Neil Deakin 2010-02-05 10:52:22 PST
Created attachment 425502 [details] [diff] [review]
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 11 David Baron :dbaron: ⌚️UTC-10 2010-02-05 10:53:52 PST
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 neil@parkwaycc.co.uk 2010-02-06 13:59:05 PST
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) 2010-02-07 15:02:15 PST
+    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 neil@parkwaycc.co.uk 2010-02-08 02:15:47 PST
(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 2010-02-17 11:47:22 PST
Created attachment 427391 [details] [diff] [review]
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 2010-02-17 11:48:49 PST
Created attachment 427392 [details] [diff] [review]
updated resizerframe patch, already reviewed
Comment 17 David Baron :dbaron: ⌚️UTC-10 2010-03-12 12:25:12 PST
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 2010-03-18 04:02:59 PDT
Shouldn't this be checked in?
Comment 20 Neil Deakin 2010-03-19 06:37:07 PDT
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 2010-03-19 11:11:30 PDT
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 neil@parkwaycc.co.uk 2010-03-20 17:56:22 PDT
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 2010-03-21 07:59:26 PDT
You should be able to use in resizer.css:

  html|textarea resizer { ... }
Comment 24 Boris Zbarsky [:bz] (still a bit busy) 2010-03-21 09:41:24 PDT
Can that use the '>' combinator instead?  Or is the resizer not a direct child of the textarea?
Comment 25 Neil Deakin 2010-03-21 09:55:06 PDT
Yes, that what I had intended.
Comment 26 Ben Turner (not reading bugmail, use the needinfo flag!) 2010-03-24 15:36:05 PDT
Oh goodness, can we get this on 1.9.2?
Comment 27 d 2010-03-24 16:01:40 PDT
(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] 2010-06-14 13:54:01 PDT
Documented:

https://developer.mozilla.org/en/CSS/-moz-resize
Comment 29 David Baron :dbaron: ⌚️UTC-10 2011-08-19 15:10:16 PDT
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-10 2011-08-19 16:20:26 PDT
Reftest fails on Android:
https://hg.mozilla.org/integration/mozilla-inbound/rev/1b73567f747b
I think because it assumes native theme support.
Comment 31 :Ms2ger (⌚ UTC+1/+2) 2011-08-21 11:36:08 PDT
http://hg.mozilla.org/mozilla-central/rev/1b73567f747b

Note You need to log in before you can comment on or make changes to this bug.