Closed Bug 155217 Opened 22 years ago Closed 22 years ago

Images created without height get incorrect height value...

Categories

(Core :: DOM: CSS Object Model, defect)

Product:
Core
Component:
DOM: CSS Object Model
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: kevin.cummings, Unassigned)

References

Details

Attachments

(1 file, 1 obsolete file)

Corrected testcase.
1.04 KB, text/html
Details
To the best of my knowledge img elements that are created without a default width or height property are supposed to get those values set based on the size of the image specified as the src. I have tested an img element that is hard- coded in the HTML page, an img element that is added to the document via document.write and an img element that is added via DOM calls and all three techniques return the same value and it is wrong. The image I am testing is 20px tall but Mozilla returns the value as 24px, I have also tested an image that is 11px tall and the height is still returned as 24px.. Here's the code: <html> <head> <title>Untitled Document</title> </head> <body style="margin:0"> <img id="imgTest1" border="0" hspace="0" vspace="0" src="./blue/preferences.gif" align="absmiddle"/> <script language="JavaScript"> var test = document.getElementById("imgTest1"); alert(test.offsetHeight); </script> <script language="JavaScript"> var html = "<table width='100%' border='0' cellpadding='0' cellspacing='0' id='imgTest2'><tr><td nowrap><img border='0' src='./blue/preferences.gif' align='absmiddle'/></td></tr></table>"; document.write(html); var test = document.getElementById("imgTest2"); alert(test.offsetHeight); </script> <script language="JavaScript"> var img = document.createElement("IMG"); img.setAttribute("border", "0"); img.setAttribute("id", "imgTest3"); img.setAttribute("align", "absmiddle"); img.setAttribute("src", "./blue/preferences.gif"); document.body.appendChild(img); var test = document.getElementById("imgTest3"); alert(test.offsetHeight); </script> </body> </html>
->DOM Style
Assignee: attinasi → jst
Component: Layout → DOM Style
QA Contact: petersen → ian
Attached file the HTML as an attachment (obsolete) —
Kevin, that testcase shows "58" over here, which is the correct height of the image in question... Is that what you see? In particular, do images that are shorter than 24px all show 24px for you while ones that are taller show different values? If so, what is your font size set to?
Boris, I tried again with an additional image that is 32X32 pixels and I still get 24 as the reported size for all 3 examples above. As for font, since I don't have any elements that use text I am not sure where I would specify a font. So, it would seem that both images larger than and smaller than 24px are always reported as 24px on my machine at home and at work using Mozilla 1.0.
Attached file Corrected testcase. —
Kevin, is that also what you're seeing with this attachment?
Attachment #90299 - Attachment is obsolete: true
Yup.. In IE I see 30, 58, 58. In Mozilla 1.0 I see 24, 24, 24. In NS 7.0 PR1 I see 24, 24, 24.. Is there a newer released version of Mozilla I should be using?
New development!!! If I hit the F5 key all of the values are reported correctly. The values although displayed incorrectly the first time are correct after the page is refreshed.
I consistently get 58 3 times here with the attached testcase, I don't see a problem here (trunk build, Win2k).
have you tried pasting the url of the testcase into the Address bar? If I click on the link above I get the correct values, if I paste the address of the above link into a new Mozilla window I get the incorrect values.
Same thing...
I've been able to produce the same results using build 20020530 on 3 XP machines and 1 2K machine. All of the systems seem to display the correct values when viewing the page through the URL above and similarly they display the incorrect values when I close the browser, clear the cache and paste this URL: http://bugzilla.mozilla.org/attachment.cgi?id=90445&action=view into the address bar. It seems that the processing of the page is continuing before any size information is known about the image. You may not be able to reproduce this error if you have the image cached, but that is the only restriction I can think of seeing as I have been able to reproduce this error with local images. I am going to try and add some code to pre-load the image before allowing the rest of the page to render but it would be nice if the browser could handle this for me.
Ah, there we go. If I clear the cache I get "24" -- the height of the placeholder image. You're correct that when we encounter an image we put in a placeholder and keep rendering the rest of the page -- otherwise processing would need to halt until the images loaded one at a time. As it is, the page reflows as the images come in, which is the behavior browsers have had since day 1 for images with no size specified.... Notice that the same thing happens in IE (see the first number in that set; I suspect the second number will do the same if it were the first test; the third one will likely be synchronous and hence always the image size in IE....). You may want to move whatever processing you're doing into the onload handler of the images. Also note bug 83774, which _may_ help this situation somewhat.
things are not looking good for me then.. I can consistently get the correct values from IE for any image of any size. I can't do this processing in the onload event of the image because there are lots of images that need to be loaded and the onload event doesn't seem to get called until the body has been completely parsed. Is there any way to stop the processing of the page until the image has been received? I know this seems horrible but in most cases I am talking about images that are around 50 bytes in size and most will be loaded over company networks not the internet so the load times should be next to nothing. I've tried creating a new Image() object and setting it's source to the image I want to load but since the script is in the body it just keeps on rendering while the image loads and I can't seem to stop it. You think it's feasible to wait until certain attributes of the image are known before rendering it's element? i.e. the size since this can cause the entire layout of the page to change once the correct values are obtained.
> You think it's feasible to wait until certain attributes of the image are known > before rendering it's element? It's certainly not feasible in the current implementation, and we would not want to do that in any case -- rendering content as quickly as possible is what a typical user wants. The fact the the onload event for the image is not being called till the body is completely parsed likely just means that the image does not finish loading till after the body is completely parsed... Putting the image "preloading" in the <head> _may_ help but is unreliable -- if the page is cached and the images are not it could break.... Perhaps a better question is "What are you trying to do with the image sizes?"
Well, the images are part of a toolbar for a web application. This application is skinnable so I will not know the size of the images beforehand. The entire interface is generated dynamically through DOM calls but I render a small piece of HTML that contains an image in order to get the size of the image and ultimately the size of the toolbar. I am going to work on trying to preload at least this one image in order to guarantee myself that I have the correct size in Mozilla and NS before I continue. Thanks for all your help!!
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
This has been "fixed" as a result of bug 83774. Now the image will have the right .width and .height as soon as we know them, and the onload event for the image should fire much earlier. Marking bug invalid, since the behavior has been correct all along.....
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Depends on: 83774
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: