Closed Bug 44480 Opened 25 years ago Closed 25 years ago

Resizing window to smaller size does not resize DIVs

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: sea, Assigned: waterson)

Details

(Whiteboard: [nsbeta3+] FIX IN HAND)

Attachments

(7 files)

Reporter's Testcase
1.17 KB, text/html
Details
another test case
541 bytes, text/html
Details
another test case that illustrates the problem
477 bytes, text/html
Details
diffs, which would be appropriate to apply if we move width & height to NSHTMLDocument
1.23 KB, patch
Details | Diff | Splinter Review
proposed fix
27.03 KB, patch
Details | Diff | Splinter Review
cleanup: leave XULDocument.[width|height], use GetBodyContent() and mBodyContent
28.36 KB, patch
Details | Diff | Splinter Review
updated patch for nsHTMLDocument.cpp
3.41 KB, patch
Details | Diff | Splinter Review
Included it the code I used. To reproduce: 1) Load my code. It's a simple DIV stretched to document.width. There should be no scrollBar at the bottom. 2) Resize window to a bigger size. There should be no ScrollBar at the bottom. 3) Resize the window back to a smaller size. A Scrollbar now exists and the DIV has not resized. I'm not sure if this is a JavaScript engine(Event Handling) or a DOM problem. ----------Code used ----------------------------------------- <HTML> <BODY BACKGROUND=""#DFF8C8" > <script LANGUAGE="Javascript"> <!-- function Test() { document.getElementById('HEADER').style.width = document.width - 5; document.getElementById('HEADER').style.height= 50; } window.onload = Test; window.onresize=Test; //--> <DIV ID="HEADER" STYLE="BACKGROUND:#FFF3CA;HEIGHT:0;WIDTH:0;BORDER:1 solid BLACK; POSITION:ABSOLUTE; LEFT:0; TOP:0; OVERFLOW:HIDDEN;">&nbsp;</DIV> </BODY> </HTML> -------------END OF CODE USED ------------------
I was able to duplicate the problem, but the testcase needs a </script> tag to work.
Confirmed on Linux 2000070708. About to attach a cleaned up version of the reporter's testcase. Also cleaned up summary.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Resiing Window to smaller size does not resize Divs → Resizing window to smaller size does not resize DIVs
Attached file Reporter's Testcase —
Not Engine; reassigning to Event Handling
Assignee: rogerl → joki
Component: Javascript Engine → Event Handling
QA Contact: pschwartau → janc
I also know this problem (mostly appears with nested tables and relative sized form controls). Happens also without any JavaScript. OS is NT.
May be a dupe of 42650
I just looked at bug 42650 and this does appear to be a dupe. The means are different but it seems that the exact same effect is happening. Auto resizing doesn't fire it either case when the window is shrunk. I was going to resolve this and place a dupe on it, but I feel that's not my place, because there is still a possiblity that it isn't.
Attached file another test case —
I'm slightly usurping the meaning of this bug, but I'm pretty convinced that this is a problem with interaction between the XUL box and HTML block layout engines. See 2nd test case. Note that the div's size (which is now 50 units less than the document.width) tracks the size of the window until the window's size reaches the minimum size of the top toolbar. At which point, the div will refuse to shrink any further. cc'ing dbaron and evaughan, who have seen these sorts of box-vs.-block battles before. Stealing bug from joki, because it is clearly not an event problem.
Assignee: joki → waterson
Component: Event Handling → Layout
Keywords: correctness, nsbeta3
Target Milestone: --- → M18
nsbeta3: correctness, standards support.
Status: NEW → ASSIGNED
Ok, talked to hyatt about this. The behavior that I was seeing in navigator is a red herring because of the way that boxes worked. Dug a bit further and I see this: setting "style='overflow:hidden'" on the <body> *and* removing the absolute positioning from the <div> make this example work right. So...there are two issues here: 1. Absolute positioning is screwey, which I think 42650 covers 2. GFX scrollframe and box-to-block adaptor cause goofy things to happen to the width. I guess this bug can cover (2).
In bug 42650, setting "position: absolute" on the div, and then trying to size it to the current browser's width, causes it to "spill over" a bit. At least, that's what I make of it. Bad math.
The containing block for the absolutely positioned DIV is the content edge of the root element (CSS2 10.1). BODY has an 8px margin (ua.css). BODY is not the root element. The absolutely positioned element has its 'left: auto' converted to 'static-position' (CSS2 10.3.7 + CSS2 errata), which places its left edge against BODY's margin. This means the absolutely positioned DIV should stick out on the right edge of the root element by 8px, plus its right and left border widths. [Citations from memory - may be wrong.]
In other words, "it's right"? :-)
[nsbeta3+]
Whiteboard: [nsbeta3+]
At least one problem is that nsDocument::GetPixelDimensions() is returning the dimensions of the <html> element, not the <body> (which appears to be what 4.x does in this case). Since html.css has a rule "body { margin: 8px }", and the test case repeatedly sets the width of the <div> to "document.width", we end up with a feedback loop that causes the div to grow forever! For example, - intial document.width fetches 620px for <html> element - set <div> to 620 - 5 = 615px. - apply 8px margins - next document.width fetches 615 + 8 + 8 = 631px for <html> element - set <div> to 631 - 5 = 626px. - apply 8px margins (ad infinitum...) jst suggested moving the document.[width|height] APIs to the NSHTMLDocument IDL (that is, netscape-specific extensions to HTML doc, rather than generic doc). Alternatively, I could apply the 8px margin to the <html> element and achieve the same effect. N.B. that this doesn't fix the bug all the way, but it does kill the feedback loop. (With the margin moved to the <html> element, the div's size will track growth, but will never shrink...) I need some advice. Should I pursue jst's fix. Should I move the margin to the html element? Neither? Both? -
Never mind re: moving the 8px border to the <html> element. I was smoking something. The test case I just attached proves it.
I vote for "fix bug 35681", which, AFAICT, would fix this automatically without you doing any work.
The attached fix would be appropriate to apply in NSHTMLDocument (because we know that the root element is <html>, and that it will have a <body> child). It's inappropriate otherwise. So if people agree with jst's suggestion to move width and height attributes to NSHTMLDocument, I'll go ahead and code this up. Comments? FWIW, this fixes the bug completely (AFAICT).
Attached patch proposed fix — — Splinter Review
Proposed fix: - move width & height attributes to NSHTMLDocument from NSDocument - move implementation from nsDocument to nsHTMLDocument - change GetPixelDimensions() to grovel for <body> tag - remove Get[Height|Width] methods from nsXULDocument
Whiteboard: [nsbeta3+] → [nsbeta3+] FIX IN HAND
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
verified: 2000-10-23-13-MN6 : linux
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: