7019 - Changing SRC url on IMAGE element doesn't resize image

Status: VERIFIED FIXED

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

Description

[Charles Manske]

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.

Comment 1

[sujay]

Beth, whose the qa_contact for this kind of bug?

Comment 2

[gerardok]

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.

Comment 3

[gerardok]

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

Comment 4

[gerardok]

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

Comment 5

[vidur (gone)]

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.

Comment 6

[vidur (gone)]

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.

Comment 7

[Charles Manske]

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.

Comment 8

[vidur (gone)]

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).

Comment 9

[Charles Manske]

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.

Comment 10

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Not for beta.

Comment 11

[Doug Lemaire]

Attachment: Test case with one HTML file and two GIF files

Comment 12

[Doug Lemaire]

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.

Comment 13

[vidur (gone)]

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

Comment 14

[vidur (gone)]

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

Comment 15

[ekrock's old account (dead)]

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

Comment 16

[Morten Wang]

Attachment: Testcase #2

Comment 17

[Morten Wang]

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.

Comment 18

[Martin Honnen]

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

Comment 19

[Martin Honnen]

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.

Comment 20

[Morten Wang]

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.

Comment 21

[Johnny Stenback (:jst)]

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

Comment 22

[Johnny Stenback (:jst)]

Attachment: Proposed (partial) fix for this bug...

Comment 23

[Johnny Stenback (:jst)]

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

Comment 24

[Mike]

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

Comment 25

[Sebastian Späth]

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

Comment 26

[Johnny Stenback (:jst)]

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.

Comment 27

[Jan Carpenter]

Mass update of qa contact

Comment 28

[Charles Manske]

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.

Comment 29

[Prashant Desale]

QA contact Update

Comment 30

[Stuart Parmenter]

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

Comment 31

[Stuart Parmenter]

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

Comment 32

[Chad Austin]

Verifications.  Tests (if necessary) were done with 2001052504 on Windows 2000.

Please forgive the spam.