Closed Bug 112398 Opened 23 years ago Closed 21 years ago

No action when JavaScript changes SRC attribute of Image

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect)

Product:
Core
Component:
Layout: Images, Video, and HTML Frames
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
RESOLVED DUPLICATE of bug 130265
Milestone:
mozilla1.4alpha

People

(Reporter: michalsc, Assigned: jdunn)

References

(
URL
)

Details

Attachments

(7 files)

Simplified testcase. You may find it working on the following url http://www.imappa.pl/mozilla-example/index.html
2.88 KB, text/html
Details
simplified testcase
580 bytes, text/html
Details
New testcase, a little bit more sophisticated
885 bytes, text/html
Details
modified testcase with images from original reporter
994 bytes, text/html
Details
working testcase
1.01 KB, text/html
Details
testcase with alert replaced by a noop loop
1.14 KB, text/html
Details
simpler test case with working graphics that exhibts correct behavior under IE
705 bytes, text/html
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.2) Gecko/20010628 BuildID: 2001062815 and up!!! Click on the map - there is JS which changes image's src attribute. I worked properly with old mozilla builds (about 0.9.1) but it doesn't work with all Mozilla versions starting from 0.9.1 upto newest versions! In the newest version it doesn't work at all, in previous the solution was RMB click over the image. Reproducible: Always Steps to Reproduce: 1. Open the page. Use default (c=1) parameter or chose a city from the list (left side, green bar) 2. The city map displays. Move mouse to "skala" menu and change the scale, or LMB click on the map or use arrows to navigate. It should change (check with other browsers) but it doesn't. The image is not refreshed anymore! 3. That's all... Actual Results: No change, the image (city map) gets trashed as it's not refreshed anymore. Expected Results: Load new image (it's reloaded with document.getElementById("img_name").setAttribute("src","url")) and display it! The bug is present somewhere in core so exist on every single build of mozilla. It worked with (AFAIR) 0.9.1.
Michael, What do you mean by 2001062815 and up!!! What is worth for a developer is the latest build where the bug can be seen. just overviewing the page source, I have the following comments: 1. <style>...</style> should be in the <head> section 2. <ilayer> is a NS4 proprietary tag 3. W3C validator (http://validator.w3.org/file-upload.html) finds about 30 errors in this page 4. usually when one wants to switch an image it uses document.getElementByID("imgID").src="url"
Please attach a simplified testcase (with english comments :-).
You have to look at it on the url given (http://www.imappa.pl/mozilla-example/index.html) as our server checks the referer. This is the simplified testcase which demonstrates the BUG. You may test it with many different mozilla builds (it should exist since 0.9.1 or close to this version)
If you remove the anchor <a> </a> (which is useless by the way), your testcase works. This may be caused by the fact that the anchor is also a "client" of the click event. What I still don't understand is why the script enters the function that makes image switch and doesn't perform the switching. Will attach a simplified testcase.
Attached file simplified testcase —
In this testcase, which is a simplified version of the reporter page, you can see that the image switch is performed when there is an alert in the switchImage function. If this alert statement is commented, the image switching is not performed. jst ??????
I spent more time on this candidate bug. The attached testcase is the same as the previous one except that the alert statement can be skipped programmatically and that images toggle infinitely. It can be seen that when starting without the alert box (checkbox checked) the image never change. When starting with the alert box the image change. Then, if you check the checkbox (no alert box), most of the times the image continue to change. Weird!!!. Seems to be a timing problem and, after all, maybe it is a imglib issue not a Dom. I promise, this is my last post on this bug.
using the 2001-11-29-09 trunk build on win2k the images were swapped consistently with or without the checkbox checked ( http://bugzilla.mozilla.org/showattachment.cgi?attach_id=59837 )
Worksforme on 0.9.6 win2k. (with the latest attachment 59837 [details]) Seeing the same thing as Sivakiran.
The two testcases work for me under linux build 2001113021. The original page does NOT work. I guess the testcases are no good.
Confirming bug, adjusing severity to minor.
Severity: major → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
I'm puzzled that you, guys in the US, see the previous testcase working. Here in Europe, it still don't work with 2001120208. Since it seems to be a timing issue, I attach a new testcase with original reporter's image from Poland. Please, can someone (Fabian) retest the new testcase. By the way, my cache is set to Automatic (which doesn't change anything since image changed via the Dom are always refetched from the network bug #103558).
Attached file working testcase —
works for the me with the testcase i just attached.
Sivakiran, The purpose of my testcase is to show that the image doesn't change if no alert box is displayed and works most of the times when an alert box is raised. Your modified testcase always raises an alert box (alert(rval)). So obviously, it works (though this is not 100% for me).
I see the problem with attachment 60141 [details]. Maybe it's a server problem and not a DOM problem? (btw I live in Belgium, I don't think it has anything to do with your location)
the purpose of the alert box is to show the rval is changed to false.
ImageLib problem it seems, over to ImageLib. Pavlov, or whoever, the attachment http://bugzilla.mozilla.org/attachment.cgi?id=60141&action=view shows the problem, check the checkbox and click on the image, the image should change, but it doesn't. If the checkbox is not checked an alert() pops up (so we spin a modal event loop and who knows what) and the new image is correctly loaded.
Assignee: jst → pavlov
Component: DOM HTML → ImageLib
QA Contact: stummala → tpreston
Target Milestone: --- → Future
testcase mentioned by jst works fine for me, both if the checkbox is checked and if it's not. this is using 2002042007. can anybody still reproduce this problem?
Component: ImageLib → Image: Layout
Image in attachment 60141 [details] does not change when clicking on it, unless the checkbox is unchecked (i.e. alert shown). If clicking in the empty space to the right of the image, the image will change regardless of checkbox state. Current linux trunk cvs. .fi fwiw ;)
oh I have to click _on_ the image, not outside... in this case, I see this bug as well.
modified attachment 60141 [details], replacing the alert with a for loop, added input for adjusting number of delay loops. Using a value of 300000 the image does change (almost always) when clicking on the image; with say 30000 or smaller it doesn't.
same problem in the Phoenix 0.4
I'm seeing this problem w/ 2002101612 (on Linux Debian Woody). You can see another testcase here: http://131.215.22.207/admin/moz_img_src_bug.html This extremely simple test case demonstrates that the bug arises as soon as -- but not before -- a Javascript function attempts to assign a non-existent file to the 'src' attribute of the image.
Charlie, I see what you describe (comment 23), in a build from 2002-10-14, but not current cvs (2002-11-13); that issue seems to be fine now. As for this bug, I'm still seeing comment 21 in attachment 82213 [details] ~2/3 of the time
"mass" re-assigning of bugs from pav to myself
Assignee: pavlov → jdunn
updating target milestone
Target Milestone: Future → mozilla1.4alpha
I am not seeing this problem with mozilla 1.3b. comment #23 talks about a slightly different issue, when src is assigned a bad url (which is covered by bug 192237) I would like to close this as fixed, since it appears to be. comments?
Hi. I have just installed Mozilla 1.3, and the original testcase still does not work. Try this: left click on th image (nothing happens) right click on the image, the popup menu appears, do not choose anything from the menu just click somewhere to hide it when the menu disappears the image is updated. So it is too early to close this bug.
This test case also illustrates an interesting characteristic of this bug. Although the .src field update appears to run, it does not really change the value of the .src attribute
Forgot to mention - I tested this under 1.4 & 1.6b. Incidently, this bug is also exhibited in match.com personals (for the "see other photos" link) and (I suspect, though I have not verified it) may cause amazon.com "look inside this book" to not work properly under mozilla
This was fixed by fixing bug 130265 *** This bug has been marked as a duplicate of 130265 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
I confirm that the original testcase moved to http://www.ipoznan.pl/java/mozilla_m.html is working too.
Product: Core → Core Graveyard
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: