The default bug view has changed. See this FAQ.

Implement CSS property to control element resizability

RESOLVED FIXED in mozilla1.9.3a4

Status

()

Core
CSS Parsing and Computation
--
enhancement
RESOLVED FIXED
9 years ago
9 months ago

People

(Reporter: Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m), Assigned: Neil Deakin)

Tracking

(Depends on: 2 bugs, Blocks: 2 bugs, {css3, dev-doc-complete})

Trunk
mozilla1.9.3a4
css3, dev-doc-complete
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.2 -
wanted1.9.2 -
blocking1.9.1 -
wanted1.9.1 -
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments, 4 obsolete attachments)

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.
Flags: wanted1.9.1?
Flags: wanted1.9.1?
Flags: wanted1.9.1-
Flags: blocking1.9.1-
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.
Flags: blocking1.9.2?

Comment 2

8 years ago
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?
Flags: wanted1.9.2-
Flags: blocking1.9.2?
Flags: blocking1.9.2-
(Assignee)

Updated

8 years ago
No longer blocks: 167951
(Assignee)

Comment 3

7 years ago
Created attachment 419124 [details] [diff] [review]
part 1: implement css resize property
(Assignee)

Comment 4

7 years ago
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.
(Assignee)

Updated

7 years ago
Blocks: 167951
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

7 years ago
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.
(Assignee)

Comment 7

7 years ago
Created attachment 425495 [details] [diff] [review]
implement -moz-resize property

Decided to just -moz-resize property due to differences.
Assignee: nobody → enndeakin
Attachment #419124 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #425495 - Flags: superreview?
Attachment #425495 - Flags: review?(dbaron)
(Assignee)

Updated

7 years ago
Attachment #419126 - Attachment is obsolete: true
(Assignee)

Comment 8

7 years ago
Created attachment 425499 [details] [diff] [review]
nsGfxScrollFrame.cpp and css changes as well as tests
Attachment #425499 - Flags: superreview?(dbaron)
Attachment #425499 - Flags: review?(roc)
(Assignee)

Comment 9

7 years ago
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
Attachment #425502 - Flags: review?(neil)
(Assignee)

Comment 10

7 years ago
Builds are at https://build.mozilla.org/tryserver-builds/neil@mozilla.com-resizerany2/
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
Attachment #425495 - Flags: review?(dbaron) → review+
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?
Attachment #425502 - Flags: review?(neil) → review+
+    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.
(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").
(Assignee)

Updated

7 years ago
Attachment #425495 - Flags: superreview?
(Assignee)

Comment 15

7 years ago
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.
Attachment #425499 - Attachment is obsolete: true
Attachment #427391 - Flags: superreview?
Attachment #427391 - Flags: review?(roc)
Attachment #425499 - Flags: superreview?(dbaron)
Attachment #425499 - Flags: review?(roc)
(Assignee)

Updated

7 years ago
Attachment #427391 - Flags: superreview? → superreview?(dbaron)
(Assignee)

Comment 16

7 years ago
Created attachment 427392 [details] [diff] [review]
updated resizerframe patch, already reviewed
Attachment #425502 - Attachment is obsolete: true
Attachment #427392 - Flags: review+
Attachment #427391 - Flags: review?(roc) → review+
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.)
Attachment #427391 - Flags: superreview?(dbaron) → superreview+

Comment 18

7 years ago
Shouldn't this be checked in?
(Assignee)

Comment 19

7 years ago
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
Status: ASSIGNED → NEW
Flags: in-testsuite+

Updated

7 years ago
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a4

Updated

7 years ago
Keywords: dev-doc-needed
(Assignee)

Comment 20

7 years ago
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.
Blocks: 553576
Summary: Implement CSS3 'resize' property → Implement CSS property to control element resizability

Comment 21

7 years ago
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!

Updated

7 years ago
Depends on: 553796
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?
(Assignee)

Comment 23

7 years ago
You should be able to use in resizer.css:

  html|textarea resizer { ... }
Can that use the '>' combinator instead?  Or is the resizer not a direct child of the textarea?
(Assignee)

Comment 25

7 years ago
Yes, that what I had intended.

Updated

7 years ago
Blocks: 553937

Updated

7 years ago
Depends on: 553986
Oh goodness, can we get this on 1.9.2?

Comment 27

7 years ago
(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?

Updated

7 years ago
Depends on: 554810
Documented:

https://developer.mozilla.org/en/CSS/-moz-resize
Keywords: dev-doc-needed → dev-doc-complete
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
Reftest fails on Android:
https://hg.mozilla.org/integration/mozilla-inbound/rev/1b73567f747b
I think because it assumes native theme support.
http://hg.mozilla.org/mozilla-central/rev/1b73567f747b

Updated

2 years ago
Depends on: 1186140
Blocks: 1280920
You need to log in before you can comment on or make changes to this bug.