Implement css resize property behaviour




9 years ago
7 years ago


(Reporter: enndeakin, Assigned: enndeakin)



Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(blocking2.0 beta2+)




(1 attachment)

Currently, in bug 442228, we implement -moz-resize which allows elements to be resizable. However, this is implemented just by changing the width/height style or attributes. The css 'resize' property requires that some internal scaling factor be used instead.


9 years ago
Depends on: 442228
Duplicate of this bug: 555024

Comment 2

9 years ago
So it looks like Safari is just setting style.width and style.height as we do, but using the 'resize' property. (as well as, oddly, all four margin properties) Maybe we should just use 'resize' instead of '-moz-resize' anyway and just make changing style.width and style.height the right way.

Comment 3

9 years ago
Reading the spec, the only place where our implementation is against it is that we don't reset the resize factor to 1.0 when the resize property is changed.  Here is an eample:


I think we can rename the property once we solve this.  We don't actually need to store a resize factor, we can just store the original computed width and height and then reset the dimensions when the resize property changes.

That said, I tested this in Chrome, and it has the same bug.

Comment 4

9 years ago
Sounds good to me. One thing that that struck me is that having a function to automatically switch back to the original size would be useful, as it might break the layout if it's resized in any way (and finding the original size manually, might be hard). We have a few options if we want to do that, that I can think of:

1. As soon as the resizer is used to change the size, a new option appears in the right-click menu of the form, or perhaps only the resizer itself.
2. Doubleclicking the resizer-grip restores the original size.

Out of these two, I prefer the second one, if only one had to be chosen, but a right-click menu option would be good to complete it.

No matter what, though, it probably belongs in a new bug. What do you think?

Comment 5

9 years ago
I think this blocks 1.9.3 because resizable text boxes need resize: none on lots of sites. See and, for example.
blocking2.0: --- → beta1+

Comment 6

9 years ago
I found bug 555482 just now, and has posted my last comment in there, instead.


9 years ago
Blocks: 555482
(In reply to comment #5)
> I think this blocks 1.9.3 because resizable text boxes need resize: none on
> lots of sites. See and, for example.

How does switching the mechanism we use for the resizing away from changing style.width and height affect these sites?
So if we're confident we're compatible with Safari, and Safari uses 'resize' rather than something prefixed, then I think it's fine for us to drop the prefix as well, since it's not spoiling any ability that the working group has to change the spec.
Bumping this to beta2 per beta re-triage with dbaron and sayre.  If this should indeed block beta1, please re-nom.
blocking2.0: beta1+ → beta2+
Assignee: nobody → enndeakin

Comment 10

9 years ago
Attachment #455740 - Flags: review?(dbaron)

Comment 12

9 years ago
Last Resolved: 9 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Keywords: dev-doc-needed
Duplicate of this bug: 577455

Comment 15

9 years ago
When I re-size the field that says: "What 's on Your mind?" in it, placed near the top of the page in, a large part of the page appears in blank and if I re-size the field to the left, the drag indicator gets to the middle of It. Is this bug about the one reported in here?


7 years ago
Depends on: 773741
You need to log in before you can comment on or make changes to this bug.