I'm not sure if this belongs in imagelib, layout, or DOM, but here's the problem: Start the editor by either "-editor" command line switch or from the "Task" menu on apprunner. Insert an image element in an editor document. It can be inserted by placing caret in the page and clicking on Image toolbar button, enter a URL, and click OK. (Note that the image node does not have width and height explicitly set, so it uses the actual image size.) Select the image by clicking on it. Click on the image toolbar button again - it should show the current URL used for the SRC attribute. Edit the URL (you can use the "Choose File..." to get a local filename) to load a different image. After clicking on OK, the old image is replaced with the new one, but it uses the original image's width and height. Unless the width and height attributes are explicitly set (which we can't even do in the current image dialog), it should get the actual size data from the new image and resize it during layout.

Beth, whose the qa_contact for this kind of bug?

sujay, this failure is about the editor. It doesn't matter which component the defect is located. It could be in DOM, layout, or in the imagelib C++ API. Actually, we won't know that until the fix is in place. The fact is that the editor fails to resize an image. If you think I should be looking at this bug, please add my name to the qa_contact.

*** Bug 7023 has been marked as a duplicate of this bug. ***

*** Bug 7024 has been marked as a duplicate of this bug. ***

Well...this is an issue that I brought up in the DOM Working Group. For compatibility with Nav 4.x and IE 4.x, changing the SRC should retain the size of the original image. We have a couple of options: 1) Break compatibility. In most cases on the net, the images are the same size. Generally used for image rollovers. 2) Create a new property for changing the source and not retaining the original size. I proposed this in the DOM WG and didn't get much of a response. CCing ekrock to see if he has any thoughts on breaking compatibility.

Well...this is an issue that I brought up in the DOM Working Group. For compatibility with Nav 4.x and IE 4.x, changing the SRC should retain the size of the original image. We have a couple of options: 1) Break compatibility. In most cases on the net, the images are the same size. Generally used for image rollovers. 2) Create a new property for changing the source and not retaining the original size. I proposed this in the DOM WG and didn't get much of a response. CCing ekrock to see if he has any thoughts on breaking compatibility.

Interesting issue here. Given that we all know images reload much faster in 4.5 codebase when the width and height attributes are written whenever a file is saved after editing in Composer, we implemented that behavior. To get around this problem in 5.0 without breaking the DOM spec, we need a method to get the width and height of an image given only its URL. Then we would set those values in the editor and the image should display with that size.

After talking about it with Eric Krock and checking IE behavior (images are resized), my current thought is to break compatibility and have "src" property changes result in recomputation of the size of an image. I'll need to talk with Kipp about this one to see if there's a potential optimization for the case when the new and the old src are determined to have the same size (e.g. in the rollover button case).

Vidur: It's not clear to me what the consequences are of your last comment. Will we be able to get the intrinsic image size for an image in a page? We MUST have that for the editor. I understand that it should already be loaded from netlib.

Not for beta.

By the way, the resize doesn't happen in NS 4.61 (NT) either. It does happen in the IE browsers. Found another bug that this testcase shows as well (setting the .value property on a button doesn't display the new button text in the button, which DOES work on NS 4.61 (NT)), entering it separately.

*** Bug 15703 has been marked as a duplicate of this bug. ***

In an attempt to get my bug list in order again, marking all the bugs I have currently as ASSIGNED.

Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!

I just noticed this "problem" while exploring the DOM for the first time, and upon noticing this bug I figured I'd see if I could shed some light on it. Pardon me if I'm writing too much here. My system setup is Windows 98 (First Edition) with Mozilla M14 and IE5 (IE4 runs i "side-by-side mode"). I have created a test case and attached it. It consists of a single HTML file and two images. Let me know if the test case is too complicated and should be split. It's also perfectly ok if another bug is opened regarding the case, with me on the Cc: list of that one. :) The test case uses 3 images and a short paragraph. The first image will be created and inserted into the document when the user clicks the button "Create image #1". This is done through the DOM1 methods getElementById(), createElement(), setAttribute() and insertBefore(). The image can be removed by clicking the button "Remove image #1", done using the method removeChild(). Once inserted the image is named 'testImage1'. The second image says "About" and is straight HTML. Name & ID of that image is set to 'testImage2'. The third image is also "About", has name & ID set to 'testImage3' but has width & height specified. There's 6 buttons to manipulate the source of the images. Three using DOM0, document.images[imageName].src, and three using DOM1 (getElementById() and setAttribute()). There's also a button that appends "Hello world!" to the paragraph. It doesn't work untill image #1 is inserted into the document. The importance of this button will be apparent in a short while. The result of test case is as follows: IE4 will of course never do any of the DOM1 stuff. It will alter the source of image #2 and #3. It will resize image #2, but it will _not_ resize image #3 because it has width & height specified. IE5 will happily do most of the DOM1 stuff. It will _not_ let you alter image #1 using DOM0, even though the image has a name specified (and it's the right one). It will _not_ resize image #1 when the source is changed, something that is according to the DOM spec. It will resize #2, and not resize #3, the same behaviour that IE4 has, regardless of whether DOM0 or DOM1 is used to alter the image's source. Mozilla M14 does things slightly different. The behaviour depends on your prior actions before doing something. With the document in its initial state, you can change the source of image #2 & image #3 and neither will be resized, regardless of whether DOM0 or DOM1 is used. With the document in its initial state, create image #1 (another "About" image will appear). If you change the source using DOM0 it will not resize. Remove image #1 and create it again. If you change the source using DOM1 this time, it will not resize. Back to the initial state (e.g. "reload"). Create image #1, change its source (method doesn't matter), then hit "Say hello world". The text is appended at the end of the paragraph, and image #1 is resized! This behaviour does not happen with image #2 or image #3, even though, technically, image #2 and image #1 should share the same properties and thereby behaviour. Reload again. Create image #1, change it's source, then change the source of image #2. Notice that image #2 this time is resized to the size of the new image. If you try the same with image #3 it will not be resized. Regardless of method used to alter image #2 it will be resized. Reload again. Create image #1. Change the source of image #2, then change the source of image #1. The previous behaviour is repeated. Reload again. Create image #1. Change the source of image#3, then change the source of image #1. Notice that image #1 is _not_ resized this time. I think that about covers the variants I've noticed. Hope this helps somewhat. Sorry 'bout the long length.

*** Bug 32438 has been marked as a duplicate of this bug. ***

This is following up on Vidur's note of 1999-08-24 10:48. I would strongly suggest to follow IE behaviour to resize the IMG element when a new SRC is assigned (and WIDTH and HEIGHT had NOT been set in the IMG tag). I have seen numerous and repeated complaints that NN4 is not resizing the IMG elements but I have never seen anyone complaining that IE does resize. If people want a fixed size they can specify the WIDTH/HEIGHT, but give others the power to dynamically resize IMG elements on SRC swapping. That will make slide show and similar code a lot of easier then it is in NN4.

just out of curiousity I tested the new IE5 for Mac today, given the same testcase that I've uploaded. it seems that Microsoft have altered the behaviour of the browser. after I created image #1 I could alter the source through both DOM0 and DOM1, and the image would be resized to the size of the new image, regardless of method used. I don't have IE5.5 installed, so I can't say what kind of behaviour it has.

*** Bug 34254 has been marked as a duplicate of this bug. ***

The patch I just attached does fix at least part of this problem, I'll try to get that in for M16...

M16 has been out for a while now, these bugs target milestones need to be updated.

Adding PATCH keyword for easier querying. Is the patch checked in?

This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.

Mass update of qa contact

As of today, the attached patch has *not* been checked in. While I agree that this should be fixed as discussed above, this is not a problem for Composer any longer *if* (which is most of the time) we get the actual size of the image from imagelib. With that, we always set the "width" and "height" attributes on the image, which forces it to resize correctly.

QA contact Update

i fixed this when I landed the new iamge library. the attached testcase works as it should.

this would have been fixed for 0.9, so changing its milestone to reflect that.

Verifications. Tests (if necessary) were done with 2001052504 on Windows 2000. Please forgive the spam.