Closed
Bug 7019
Opened 26 years ago
Closed 24 years ago
Changing SRC url on IMAGE element doesn't resize image
Categories
(Core :: DOM: Core & HTML, defect, P3)
Core
DOM: Core & HTML
Tracking
()
VERIFIED
FIXED
mozilla0.9
People
(Reporter: cmanske, Assigned: pavlov)
References
Details
(Keywords: dom1, testcase, Whiteboard: [TESTCASE])
Attachments
(3 files)
(deleted),
application/zip
|
Details | |
(deleted),
application/octet-stream
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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.
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 5•26 years ago
|
||
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•26 years ago
|
||
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.
Reporter | ||
Comment 7•26 years ago
|
||
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.
Updated•26 years ago
|
Target Milestone: M11
Comment 8•26 years ago
|
||
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).
Reporter | ||
Comment 9•26 years ago
|
||
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.
Target Milestone: M11 → M14
Not for beta.
Updated•25 years ago
|
Whiteboard: [MAKINGTEST]douglemaire@yahoo.com
Comment 11•25 years ago
|
||
Updated•25 years ago
|
Whiteboard: [MAKINGTEST]douglemaire@yahoo.com → [TESTCASE]
Comment 12•25 years ago
|
||
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.
Updated•25 years ago
|
QA Contact: gerardok
Comment 13•25 years ago
|
||
*** Bug 15703 has been marked as a duplicate of this bug. ***
Comment 14•25 years ago
|
||
In an attempt to get my bug list in order again, marking all the bugs I have
currently as ASSIGNED.
Comment 15•25 years ago
|
||
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
Comment 16•25 years ago
|
||
Comment 17•25 years ago
|
||
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•25 years ago
|
||
*** Bug 32438 has been marked as a duplicate of this bug. ***
Comment 19•25 years ago
|
||
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•25 years ago
|
||
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•25 years ago
|
||
*** Bug 34254 has been marked as a duplicate of this bug. ***
Comment 22•25 years ago
|
||
Comment 23•25 years ago
|
||
The patch I just attached does fix at least part of this problem, I'll try to
get that in for M16...
OS: Windows NT → All
Hardware: PC → All
Target Milestone: M14 → M16
Comment 24•25 years ago
|
||
M16 has been out for a while now, these bugs target milestones need to be
updated.
Comment 25•25 years ago
|
||
Adding PATCH keyword for easier querying. Is the patch checked in?
Keywords: patch
Comment 26•25 years ago
|
||
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.
Target Milestone: M16 → Future
Updated•24 years ago
|
Component: DOM Level 1 → DOM HTML
Reporter | ||
Comment 28•24 years ago
|
||
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.
Assignee | ||
Comment 30•24 years ago
|
||
i fixed this when I landed the new iamge library. the attached testcase works
as it should.
Assignee: vidur → pavlov
Status: ASSIGNED → NEW
Assignee | ||
Comment 31•24 years ago
|
||
this would have been fixed for 0.9, so changing its milestone to reflect that.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Target Milestone: Future → mozilla0.9
Comment 32•24 years ago
|
||
Verifications. Tests (if necessary) were done with 2001052504 on Windows 2000.
Please forgive the spam.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•