From Bugzilla Helper: User-Agent: Mozilla/4.73 [de]C-CCK-MCD DT (Win98; U) BuildID: 2000060820 On the specified page, you can see several animated gif graphics in front of each list item. These are combined with a "MouseOver" effect to be replaced by another graphic while the user's mouse pointer is over the graphic itself or the related list item (linked text). Whenever I quickly move the mouse pointer over the list items while the page is still loading, Mozilla replaces the elements with the "alt" description of the graphic (as regular text on the page!) instead of keeping the current state until the graphic (original or the replacement on MouseOver) was fully loaded. As soon as all graphic elements are successfully loaded, this behaviour does no longer occur. That's why I'm quite sure it is a problem of handling not-yet-loaded graphics. The description text which replaces the graphic on the page stays there until the page is completely reloaded (if the page is not in the internal cache! - maybe the text (alt-description replacing the original graphic) is actually included in the internally parsed HTML code since it survives a "reload" command!). Reproducible: Sometimes Steps to Reproduce: 1. Load the specified page. 2. While the little graphic elements before each list items are loaded, move the mouse quickly over the list items. 3. The graphic elements (as long as they are still in the process of being loaded) will be replaced by their "alt" description (as plain text on the page, replacing the graphic). Actual Results: Destroyed layout Expected Results: Nothing should happen if the graphic needed for a "MouseOver" replacement was not yet fully loaded. On the other hand, if the original graphic was not yet loaded, the replacement graphic should stay after the first "MouseOver" until the original graphic is fully loaded...

This doesn't seem to be a Javascript Engine problem rather that layout. Very closely related to bug 41924 "Change how layout handles broken images". Changing component, reassigning to owner of that bug, cc Ian.

I could not reproduce this; I guess my connection is too fast. The bug seems to be that when an image's 'src' attribute is replaced by another dynamically, it is not assumed to be _loading_ if the image is not yet available. This triggers our alternate text behaviour (which is correct) but then we probably fall into bug 22820 (Broken IMG 'src' cannot be changed to valid 'src' dynamically).

Using Mozilla build 2000062708, I could not reproduce the bug. I am connecting to the internet using a 33.6 modem and my connection is slower than that at the time of the testing. I've had the images load slowly, but no "alt=" text.

I just tried to reproduce the bug with the latest nightly build (2000062720) and it is still there! The problem was that my first attempt did not reproduce the bug as well: I moved the mouse pointer over all the animated graphics while the page was loading but everything worked fine. Then I found out that the JavaScript support was extremely slow, so the buttons didn't react at all when passing them too fast... This is how I finally could reproduce the bug: 1. load the site fully (http://www.artanic.com) 2. click in the right frame containing the animated "NEU" graphic to activate the frame 3. position the mouse pointer over one of the "NEU" graphics 4. right click, hold down the SHIFT key and choose "Reload Frame" from the popup menu 5. while the page is completely reloading, move your mouse slowly left and right, always over the "NEU" graphic The result in my Mozilla build: _All_ occurences of the "NEU" graphic are replaced by their "ALT" description, which cannot be undone once it has happened. See attached graphic "artanic_failure_20000628.gif".

Just reproduced it with 2000061820 and Win98. If it is in the cache once, it will be displayed correctly. To reproduce it disable mem and disk cache (Edit, Settings, Debug) and try to avoid using a proxy so that the frame will be reloaded from the server every time you hit reload...

setting bug status to New

Since this is in Layout component, changing QA Contact accordingly -

I'm gonna have to future this one, Alexander. You have put in a lot of effort into this bug and I feel bad doing this, but there are just too many other much higher visibility and severity bugs that we have on our plate. Sorry!

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.

This bug might be the same as bug 32269.

dupe of 32269 i believe *** This bug has been marked as a duplicate of 32269 ***