56067 - Image Swap Issue

Status: RESOLVED DUPLICATE of bug 68955

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

Description

[Jonathan Shore]

There seems to be an issue with the page layout engine regarding image 
updates.  The problem will occur consistently in the following scenario tested 
on NS 6P3 on windows 2000 and linux (likely to occur in head version as have 
not seen a similar bug/feature reported). 

Assume the following code:

   ...
   function nop() {}

   function swapother() { document.images["other"] = "<image-url-B>"; }

   ...
   <img name="other" src="<image-url-A>">
   <a href='javascript:nop()' onClick='swapother()'>
     <img name="trigger" src="<trigger image>">
   </a>

The behavior of the above when the "trigger" image is clicked is to call 
swapother(), as it should.  The "other" image is not changed however, as I 
believe the layout engine decides that since there is a HREF target there is no 
need to further update the page.

Taking out the dummy HREF target causes the above code to work correctly.  
Unfortunately, due to irregularities in netscape 4.x, people use this technique 
(of dummy hrefs) to enable onMouseOver and onClick events.

I think the above "bug" is a more of a "feature".  On the other hand, I don't 
see any reason why the above dummy href should not be supported.

If anyone would like HTML and images for the example send me some mail.

Thanks

JS

Comment 1

[Doron Rosenberg (IBM)]

dom 0 issue I believe.

Comment 2

[Johnny Stenback (:jst)]

A simplified testcase would be appreciated, thanks!

Comment 3

[Jonathan Shore]

Attachment: Tar of a Test Case: Includes a HTML file and supporting images

Comment 4

[Asa Dotzler [:asa]]

Jonathan Shore, what are the steps to reproduce this problem? what are the
expected and actual results in this testcase?

Comment 5

[Jonathan Shore]

Do you not see the behavior I mentioned in the bug report?  

Load the test page, click on the image and observe that the image doesn't 
change.  Removing the HREF attribute in a <A> tag will solve the problem, 
however removing this breaks the behavior in netscape 4.x browsers (rollovers 
will not activate unless there is a href tag).

I suppose one could write or generate a separate html page for mozilla - but 
would be more convenient if this is fixed.

Comment 6

[Cyril Bortolato]

Using the provided testcase, the top image is replaced by jshore-full-framed.jpg
when I click on the thumbnail image. But it does not display correctly. See
attachment below.
I'm using 11/02 build on Linux.

Comment 7

[Cyril Bortolato]

Attachment: Screenshot

Comment 8

[Jonathan Shore]

The results you are seeing are consistent with what I saw.  Either the image 
never appeared or partially appeared.  I assumed that the rendering engine 
decided to punt as the HREF target would normally cause a diff page to load.

Does this now confirm the bug.  Thanks.

Comment 9

[Johnny Stenback (:jst)]

This is indeed a valid bug, looks like the image download is incorrectly
canceled by the link click, I'll see if I can fix this...

Comment 10

[Johnny Stenback (:jst)]

Rick, I know I've talked to you about this but it was quite some time ago. The
reason this doesn't work is that loading a javascipt: URL calls StopLoad() even
if evaluation of the javascript: URL doesn't return a value. So here's what
happens when the lower image in the testcase is clicked on:

  - We call the onclick handler on the link, the onclick handler sets the .src
of an image which kicks off a load of that image.

  - The URL of the link is loaded, this is the javascript: URL and now, before
we know that this javascript: URL doesn't return a value we wanto show in the
browser we cancel all loads targetted at the current window, this will stop the
image load we just initiated.

It seems like the whole stopping of loads targetted at the current window should
only happen once new data is on it's way to the new window and not immediately
when someone clicks on a link on the window. Reassigning to you, Rick, since
this is IMO part of the window targetting cleanup you'll start working on.

Comment 11

[rpotts (gone)]

It appears that the patch checked in for bug #65777 has fixed this issue.

I've tried running the snippet of javascript that was attached to swap the
images based on an OnClick event (with a dummy href) and it seems to be working
fine.

Comment 12

[Prashant Desale]

Re-opening this bug.
I tested this with win-95 with builds 2001-06-05-09 & I tested with the web-site 
mentioned above. "http://www.e-shuppan.com".
First it loads picture & if you click on picture it goes away.
It is supposed to keep rolling pictures one after another after specific 
interval of time [Thats what it is doing in IE], but it does not show second 
picture for long time & even after that it shows blank screen.

STEPS TO REPRODUCE:
1] Visit "http://www.e-shuppan.com".
2] Observe the Main image on screen. 

EXPECTD RESULTS:
Images should keep swapping.

ACTUAL RESULTS:
After first image you see blank screen. Second image is never loaded.

Comment 13

[selmer (gone)]

Doesn't look like this happens to many people -> 092.

If that's wrong, put it back on 091 and give us more info.

Comment 14

[rpotts (gone)]

hey johnny,

I've looked more closely at the code being executed on the
http://www.e-shuppan.com site and I can't find where a javascript: URL is being
used...

It really looks as if the onLoad is not firing for the frame containing the
slideshow ...  I'm guessing this because the page always loads up with the
White-Dreads-ii.jpg image...  And it never changes...

It looks like all that the JS is doing is loading up an array of Images and then
changing the Image.src on the Image element named 'Slide'.

Any ideas what might be failing?
-- rick

Comment 15

[Jonathan Shore]

Hi - since I posted the original bug, allow me to comment.  I'm not looking for 
mozilla to render http://www.e-shuppan.com/ correctly.  I know there are 
compatibility issues with this site (though it does render on both netscape 4.7 
and IE4 and up).

The original problem was detected in a web application designed around 
mozilla.  It's been a long time since I looked at this, so if you get the test 
working than I wouldn't worry about e-shuppan.com.

Jonathan

Comment 16

[rpotts (gone)]

Ok...  I'll focus on the test case, rather than http://www.e-shuppan.com.  If 
the test case becomes fixed, i'll open a separate bug on www.e-shuppan.com (if 
necessary)...

Unfortunately, i'm not able to unzip the attached test case using WinZip :-( How 
should I open it?

Comment 17

[rpotts (gone)]

moving out to 0.9.3 because I cannot open the test case :-(

Comment 18

[lchiang]

Prashant, can you open the test case successfully?
rpotts - would you consider this bug to be a stopper type of bug?

Comment 19

[rpotts (gone)]

well... since I can't see the test case, its hard to know if it is a "common" 
problem or not :-(

-- rick

Comment 20

[lchiang]

I cannot unzip the file attachment either.  Jonathan Shore, can you send rpotts
or desale the zip file via email?  Thank you.

per PDT team triage, for now, we will remove the PDT+ until we have a test case
that can be looked at.

Comment 21

[rpotts (gone)]

Removing dependency on bug #65777 - so I can close it out :-)
-- rick

Comment 22

[Jacob Kjome]

Attachment: Here's the zip file. I opened the other with WinRAR

Comment 23

[Jacob Kjome]

The zip file I just uploaded contain the same contents as the first testcase
attached to this bug.  I was able to open it up with WinRAR.  Not sure why
Mozilla displays "showattachement.cgi" when I try to download it???  I uploaded
it as a custom mimetype "application/zip".  Not sure if that has anything to do
with it???

Anyway, if you save it as a zip file, it will open in Winzip now.  

FYI, I tried the testcase and it seems to work exactly the same in IE5.5 as it
does in Mozilla build 2001062804

jake

Comment 24

[rpotts (gone)]

I believe that this testcase is a dup of test1 in bug #68955.

See my comments there about the interactions between the image cache and onClick
handlers :-)

Basically, unless the image being loaded in the onClick handler is already in
the image cache, the load will fail (actually it will be cancelled when the
javascript URL is loaded).

I believe that this behavior is consistant across IE Nav 4.7 and Mozilla (post
0.9.1)

Let me know if you think my assessment is incorrect...
-- rick

*** This bug has been marked as a duplicate of 68955 ***