Closed Bug 26289 Opened 25 years ago Closed 25 years ago

Replaced-inline elements styled with width:x% do not resize properly

Categories

(Core :: Layout: Form Controls, defect, P3)

Product:
Core
Component:
Layout: Form Controls
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: roc, Assigned: buster)

Details

(Whiteboard: [PDT+] landing 2/10)

Attachments

(4 files)

This is a simple test case demonstrating the bug.
121 bytes, text/html
Details
A patch fixing the bug
2.37 KB, patch
Details | Diff | Splinter Review
An HTML file testing for a subtle case of style change that the patch may not cover
1.05 KB, text/html
Details
HANG ON - Re-open this bug???? Does not work with fixed widths.
320 bytes, text/html
Details
I have split this issue off bug #21834, which deals specifically with tables and SELECT elements. There is a simpler underlying problem which needs to be fixed: when a block is reflowed, lines containing elements whose width depends on the width of the block are not reflowed when they should be. My relevant comments from that bug: ------- Additional Comments From roc+moz@cs.cmu.edu 1999-12-23 16:34 ------- The problem is in the line reflow optimization code. In nsBlockFrame::PrepareResizeReflow, if the new line width is wide enough for the current width of the line frames, and several other conditions are satisfied, then the line is not marked dirty for reflow. One of the conditions that must be satisfied is !line->HasPercentageChild(), which would seem to cover this case ... except SetHasPercentageChild() is never called, anywhere, ever. I have attached a simpler test case that demonstrates this bug. Try opening the file with the window very wide, then gradually make the window narrower. The input box will not change width unless it is on a line by itself (in which case the line is marked as containing a single block and is always reflowed). IE5 handles this case correctly. -------------- I will attach a testcase and a patch.
The patch probably will not apply cleanly to the tree. It's over a month old, and I can't be bothered keeping my patches up to date with the tip while they languish in Bugzilla for weeks. However, the code should still basically work. The idea is to compute the correct value for a line's HasPercentageChild while reflowing the elements of the line. Just before each element is reflowed, we check if its relevant styles use percentage units, and SetHasPercentageChild(PR_TRUE) on the line if necessary. Since we're already going to reflow the element, this shouldn't represent much extra work. The result is that line->HasPercentageChild() will return the correct value whenever !line->IsDirty() ... good enough for the one place where HasPercentageChild() is used.
Reassigning to Kipp's bug list.
Assignee: karnaze → kipp
I will review your patch and (assuming it's the right thing to do) apply it to the tip. From a quick glance, it looks like you're right on target. Sorry it took so long to get to this. I'm on top of Kipp's bugs now, soon they will all just be reassigned to me. Lucky me :) Thanks for your patience.
Assignee: kipp → buster
Keywords: beta1
Target Milestone: M14
Need more info as to why exactly this is a beta 1 stopper please.
Whiteboard: [NEED INFO]
Jan: marked beta1 because this potentially effects the display of a large number of pages. It's a fundemental but managably small flaw in block/inline incremental reflow. The fix is low risk and will recieve a ton of testing before it goes in. Add to that, the submitter has been waiting way too long to get his patch merged into the source tree.
Status: NEW → ASSIGNED
The only effect of the patch is to cause additional line reflows. The only way I can imagine it introducing a regression would be if it exposes a previously hidden bug. I thought of one issue: This patch assumes that whenever a child frame changes style, the parent frame will be reflowed. (If not, the child frame could change the units of a style from fixed to %age, and the HasPercentageChild flag in its parent's line box could be incorrect.) I haven't done the digging to check whether this is true; I can imagine that if the child frame's actual size doesn't change, then the parent might not otherwise need to be reflowed. I will attach a test for this case.
Putting on the PDT+ radar for beta1.
Whiteboard: [NEED INFO] → [PDT+]
Whiteboard: [PDT+] → [PDT+] landing 2/12
merged the patch in, looks good. will check in asap, hopefully tonight. Thanks!
Whiteboard: [PDT+] landing 2/12 → [PDT+] landing 2/10
fixed and checked in. THANKS, roc+moz (who the heck are you, anyway?)
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
This looks great, and even works inside a table. I'm very impressed. However, I do have one question regarding the SELECT. Why does the pull-down arrow show up only as far right as the longest option in the SELECT? This is a minor problem, and it does not affect performance in any way, but it is strange when you have 3 elements sized the same, but you can't make them look the same. I am on Windows NT 4.0 in case anyone else is not seeing the same problem.
Status: RESOLVED → VERIFIED
That case works fine for me. What problem are you seeing? BTW Keith, did you roll your own build? The first nightly build with this patch only just appeared. Everything looks good to me. Thanks for checking this in! --- roc (a grad student avoiding his thesis)
My build is dated 2/13/2000 at 5:25 pm. I'm pretty sure that's the latest...the other things didn't work before. The problem I'm seeing is with the attachment I created...the INPUT only takes up about half of the TD which is specified at 350px.
Please download a build from 2/14/2000. I'm pretty sure Steve's checkin didn't make it into any of the 2/13/2000 builds.
Patch once again looks good to me! Sorry for the misunderstanding.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: