Open Bug 709619 Opened 13 years ago Updated 3 years ago

Resizing and restoring elements' size when default width/height is not represented in px

Categories

(Core :: XUL, defect)

x86
All
defect

Tracking

()

People

(Reporter: spammed.user, Unassigned)

References

()

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20100101 Firefox/9.0 Build ID: 20111206234556 Steps to reproduce: Resize and double-click the resizer of an element with a "width" or "height" attribute represented in percents. Actual results: The current width/height is set to default. Resizing the element again and double-clicking the resizer will set width and height to these values. Expected results: width/height should have been restored to it's original value, represented in %.
Severity: normal → minor
Yeah, looks like a bug in nsResizerFrame::ResizeContent. I assumes that he resizeInfo contains either a number followed by "px" or just a number, and appends "px" if it can't find "px" at the end already. Which is just wrong for percentage sizes. Why is it doing that?
Status: UNCONFIRMED → NEW
Component: General → XUL
Ever confirmed: true
QA Contact: general → xptoolkit.widgets
ccing the author of this code too. ;)
Blocks: 555482
> I assumes that he resizeInfo "It assumes that the resizeInfo". I need a new keyboard, clearly!
> resizeInfo contains either a number followed by "px" or just a number, and > appends "px" if it can't find "px" at the end already. [The string code that tries to find "px" is dire anyway...] > Which is just wrong for percentage sizes. And indeed for all other non-px units!
OS: Windows 7 → All
Summary: Restoring elements' size after resizing when default width/height is represented with % → Resizing and restoring elements' size when default width/height is not represented in px
Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.