image.width and image.height return incorrect values




18 years ago
17 years ago


(Reporter: olivier.poupon, Assigned: jst)


({relnote, testcase})

Windows NT
relnote, testcase

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta2+][6/15][jst], URL)


(1 attachment)



18 years ago
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
In the page when i 
click on car image the window popup dont resize corectly

Reproducible: Always
Steps to Reproduce:
1.Use function javascript resizeto

Expected Results:  The window is resize in full screen

Mozilla must resize window with size in function parameter

Comment 1

18 years ago
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
Assignee: rogerl → vidur
Component: Javascript Engine → DOM Level 0
QA Contact: rginda → desale - are you still seeing this problem in recent builds 
of Mozilla?

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

Ever confirmed: true

Comment 4

18 years ago
Created attachment 8388 [details]
Testcase for the bug

Comment 5

18 years ago
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?
Depends on: 35450
Silvester - mail for Bugzilla permissions, quoting this 
bug's URL.

Adding testcase keyword.

Keywords: testcase
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.
Keywords: nsbeta2

Comment 8

18 years ago
ekrock...your call.
Whiteboard: [NEED INFO]
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 

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.
Summary: javascript the function resize dont resize window corectly → image.width and image.height return incorrect values
Whiteboard: [NEED INFO] → [nsbeta2+][6/15]

Comment 10

18 years ago
Taking this bug off Vidurs list.
Assignee: vidur → jst
Adding nsbeta3 keyword - ekrock says it's a stopper.

Keywords: nsbeta3

Comment 12

18 years ago
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.
Whiteboard: [nsbeta2+][6/15] → [nsbeta2+][6/15][jst]

Comment 13

18 years ago
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.
Component: DOM Level 0 → DOM Level 1
Keywords: relnote

Comment 14

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

Comment 15

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

Marking fixed.
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 16

18 years ago
Marking Verified.
You need to log in before you can comment on or make changes to this bug.