From Bugzilla Helper: User-Agent: Mozilla/4.5 [fr] (WinNT; I) BuildID: 2000022820 When javascript function resizeto is use. The window is resize in full screen. In the page http://www.procar.com/asp/D_ap/vo/special_promos/accueil.asp when i click on car image the window popup dont resize corectly Reproducible: Always Steps to Reproduce: 1.Use function javascript resizeto 2. 3. Expected Results: The window is resize in full screen Mozilla must resize window with size in function parameter

Kind of hard to figure out what's happening since it's an asp page - you can see that the mouseDown calls javascript to call a function 'openMyWindow'. The open call produces weird looking windows with totally messed up title bars. Mo' better test case would sure help, but it seems most likely a dup of the other resize problems like bug 17311, bug 7888

olivier.poupon@fisystem.fr - are you still seeing this problem in recent builds of Mozilla? Gerv

It's still happening as of 20000418 (M15) on W95. Confirming. Gerv

I'm using Build 2000050513 on Win98SE, and I'm still seeing the problem. I've attached a testcase. There are three problems: 1. image.width and image.height return 15*actual size in pixels. Is this a feature? 2. window.resizeTo is confused by those values (a 9000x870 window???) and resizes itself randomly. 3. window.resizeTo has problems with repainting (this is bug 35450). Btw: how am I supposed to participate in Bug-a-thon if I cannot update the keywords field?

Silvester - mail asadotzler@netscape.net for Bugzilla permissions, quoting this bug's URL. Adding testcase keyword. Gerv

Nominating nsbeta2. We have to start drawing a line on DOM0 backward compatibility; these bugs are supposed to be a high priority for nsbeta2 per the beta2 criteria.

ekrock...your call.

Changing Summary from "javascript the function resize dont resize window corectly" to "image.width and image.height return incorrect values" because I'm assuming that window.resizeTo is the innocent victim of the bogus out-of-bounds values here, and that we should start by fixing the image.width and image.height problems. Silvester, could you please check the following: if you send window.resizeTo reasonable values (e.g. within the actual screen size), does it work correctly? If not, and there's not already a bug open on this, could you please open a separate bug report on that? You've done a very nice job of identifying and separating the three issues here (and even finding the related bug). Thanks! Setting to [nsbeta2+][6/15]. If it doesn't make nsbeta2, stopper for nsbeta3.

Taking this bug off Vidurs list.

Adding nsbeta3 keyword - ekrock says it's a stopper. Gerv

Well, I had a look and I know what's going on here, there are two problems here: 1. img.width and img.height in mozilla is the width/heigh in twips, not pixels 2. img.width and img.height (plus a few other properties) in mozilla are, as stated by the DOM spec, strings, and not numbers. I have a fix for the twips problem in my tree, however... The testcase (and the original url here) does something like this: self.resizeTo(img.width + 30, img.height + 30); the result of this, if we assume that the image size is 640x480, is that we the resizeTo call is equivalent of calling resizeTo("640" + 30, "480" + 30); which, because of the string type, results in resizeTo(64030, 48030); !!! Both NS 4.x and IE 5 have the HTMLImageElement properties width, height, border, hspace, and vspace defined as numbers, whereas the DOM spec defines those properties as strings. Erik, do you have some ideas on what we should do here, follow the spec, or be backwards compatible, any ideas on how frequently we'd run into this? Changing the type of the properties, should we decide to do it, is quite straight forward.

Ok, discussed this with Eric and Vidur, and we decided to go with backwards compatibility here, Vidur suggested that we'd leave the C++ nsIDOMHTMLImageElement API as is but change the type of the properties when accessed from JS. That should keep everyone happy :) The reason that the DOM defines the properties as strings is probably so that it would be possible to get/set values with units, this will still be possible from JS if the getAttribute and setAttribute methods are used to get/set the properties in stead of accessing the properties directly on the node.

I have this fixed in my tree, will do some more testing and get the fix reviewed before checking in.

The fix for this is checked in, the testcase still doesn't work properly in mozilla (the original URL does) but that's due to other bugs (probably bug 9606). Marking fixed.

Marking Verified.