30249 - image.width and image.height return incorrect values

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect, P3)

Description

[olivier.poupon]

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

Comment 1

[rogerl (gone)]

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

Comment 2

[Gervase Markham [:gerv]]

[e-mail] - are you still seeing this problem in recent builds 
of Mozilla?

Gerv

Comment 3

[Gervase Markham [:gerv]]

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

Gerv

Comment 4

[slipszi]

Attachment: Testcase for the bug

Comment 5

[slipszi]

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?

Comment 6

[Gervase Markham [:gerv]]

Silvester - mail [e-mail] for Bugzilla permissions, quoting this 
bug's URL.

Adding testcase keyword.

Gerv

Comment 7

[ekrock's old account (dead)]

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.

Comment 8

[leger]

ekrock...your call.

Comment 9

[ekrock's old account (dead)]

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.

Comment 10

[Johnny Stenback (:jst)]

Taking this bug off Vidurs list.

Comment 11

[Gervase Markham [:gerv]]

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

Gerv

Comment 12

[Johnny Stenback (:jst)]

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.

Comment 13

[Johnny Stenback (:jst)]

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.

Comment 14

[Johnny Stenback (:jst)]

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

Comment 15

[Johnny Stenback (:jst)]

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.

Comment 16

[Prashant Desale]

Marking Verified.