firstname.lastname@example.org - 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 email@example.com 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.
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.