I played around with window.sizeToContent() but it often fails as the following page which creates a randomly sized image as the content demonstrates <HTML> <HEAD> </HEAD> <BODY ONLOAD="window.sizeToContent(); setTimeout('location.reload()', 3000)"> <SCRIPT> var w = Math.floor(Math.random() * (screen.width - 150)) + 100; var h = Math.floor(Math.random() * (screen.height - 250)) + 100; document.write('<IMG SRC="http://www.mozilla.org/images/mozilla-banner.gif" WIDTH="' + w + '" HEIGHT="' + h + '">'); </SCRIPT> </BODY> </HTML> It looks as if the failure occurs more often when the image is much wider than high.
Created attachment 24311 [details] test case (periodically loads the page with a randomly size image and calls window.sizeToContent())
I forgot to tell that I filed this on DOM level 0 as the window object is DOM level 0. The sizeToContent method however is not DOM level 0 so please reassign if necessary
Reporter, testcase works perfectly for me (linux build 2001-01-30-10). What build/OS are you using?
M07 on Windows 95.
Reassigning, Ben, please reassign this to the right owner if it aint you.
the testcase worksforme using a cvs build from around 4:15pm today on win2k.
I see this problem on 2001 022311. By the way, I don't think untrusted webpages should be allowed to call this function -- see bug 60323.
Cc'ing Dan for comment. It seems like we sizeToContent() first and then change the img width/height, in which case it (expectedly) won't work.
Bug still exist, and I think it's a showstopper! Moz 2001062904 under win95
not me. Merry Christmas.
Setting target milestone to 'Future' since 'mozilla1.1alpha' has already passed.
Since not much has happened in this bug for quite some time, I'm submitting a democase. From the beginning, I have assumed that appearance, presence of scrollbars was why people were talking about "failure", "often fails" and was why this bugfile was filed in the first place.
Created attachment 108706 [details] Increase and decrease of an image and how sizeToContent resizes the window This demo is highly configurable. One can set all of the relevant values: Delay, StepOfSizeIncrementOrDecrement, etc... including the height attribute of the image. Only WindowResizingBorderWidth should not be changed. One can also remove the <p> </p> around the image element like in the initial testcase report but this does not change anything important in the current demo. The initial screenX/screenY values of 37 from the moveTo(37, 37) are just totally arbitrary values and therefore can be changed. I even tried with an height="100" attribute and IMO this demo convincingly show that sizeToContent() works even when width >> height. When this demo starts, if the horizontal scrollbar is already present, then scrollbars will be present in the first 2 passes (narrow-to-wide and wide-to-narrow). It seems that the first sizeToContent() call never resizes accordingly the window... so the horizontal scrollbar is maintained active, then creates a vertical scrollbar, etc... The bug is somewhere else in my opinion. The sizeToContent() must be calling another function which would be causing the scrollbar behavior. I'm convinced this bug depends on another - already filed - bug. Also, some kind of bad timing might be happening which would generate the creation of scrollbars before the actual call of sizeToContent. XP Pro SP1, Moz. 1.2.1 build 20021130, scr. res. 1024x768
Workaround: Calling sizeToContent repeatedly, makes the height increasingly closer to the desired result. Calling it a 100 times seems to do the trick :) for( var i = 0; i < 100; i++) window.sizeToContent(); Hey - don't shoot me, I KNOW it's butt ugly
still exists in: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050618 Firefox/1.0+
Filter on "Nobody_NScomTLD_20080620"