Closed Bug 44480 Opened 24 years ago Closed 24 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).

    
    

    
  
What's issue (1)?

    
    

    
  
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"? :-)

    
    

    
  
Looks perfect to me.

    
    

    
  
[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: 24 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.