window.sizeToContent sometimes fails if width >> height

NEW
Unassigned

Status

()

Core
DOM: Core & HTML
17 years ago
10 years ago

People

(Reporter: Martin Honnen, Unassigned)

Tracking

({dom0})

Trunk
Future
x86
Windows 95
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
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.
(Reporter)

Comment 1

17 years ago
Created attachment 24311 [details]
test case (periodically loads the page with a randomly size image and calls window.sizeToContent())
(Reporter)

Comment 2

17 years ago
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?
(Reporter)

Comment 4

17 years ago
M07 on Windows 95.
Reassigning, Ben, please reassign this to the right owner if it aint you.
Assignee: jst → ben

Comment 6

17 years ago
the testcase worksforme using a cvs build from around 4:15pm today on win2k.
Keywords: dom0

Comment 7

17 years ago
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.
Summary: window.sizeToContent fails to size the window to the content → window.sizeToContent sometimes fails if width >> height

Updated

17 years ago
OS: other → Windows 95

Comment 8

17 years ago
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.

Comment 9

17 years ago
Bug still exist, and I think it's a showstopper!

Moz 2001062904 under win95
not me. Merry Christmas. 
Assignee: ben → danm

Updated

16 years ago
Target Milestone: --- → mozilla1.1

Comment 11

15 years ago
Setting target milestone to 'Future' since 'mozilla1.1alpha' has already passed.
Target Milestone: mozilla1.1alpha → Future

Comment 12

15 years ago
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.

Comment 13

15 years ago
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

Comment 14

14 years ago
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

Updated

13 years ago
Assignee: danm.moz → nobody

Comment 15

13 years ago
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"
QA Contact: desale → general
You need to log in before you can comment on or make changes to this bug.