OK, It's a bit complicated so the best for you to find out what I mean is just to view the url,then pass over the text with the mouse (it should give a js error in the terminal) and then drag another window on mozilla so it'll have to re-draw the html. *poof* - the bg image of the table disapears. A better description: I use a <MARQUEE> with OnMouseOut="start()". mozilla doesn't seem to know the MARQUEE tag, but it also reports that: JavaScript error: line 0: start is not defined It happens only because of the 'start()' function, which causes the MARQUEE start moving in MSIE. Expected behaviour: Just ignore this start() function if it's unknown. The way mozilla behaves: For some reason it 'forgets' about the existance of the background image of the <TD>. It looks fine until it should redraw (if you moved another window over it, for example)- then it just doesn't display the background image. Tested on build 20010103 , linux.

Happening here too. Mozilla 2001010520 on Windows 2000/PC. BTW: marques is not HTML standard tag

Browser, not engine ---> DOM Level 0

Marking Invalid. The <MARQUEE> element IE-only. "Start" and "stop" are methods of the tag that in NN/Mozilla are not going to be recognized. Whenever a JavaScript identifier is not recognized, you will always get an error in the JavaScript console warning you about it. This can be helpful in correcting errors in scripts. The JavaScript engine cannot, however, distinguish between a coding error and unsupported IE functionality.

No matter what mozilla does with the start() function, it should not lose the background on the <tr> the way it does. Reopening and changing summary to reflect the problem.

I don't agree. The background issue is a side effect of the marquee element (for some strange reason) and we have much better to do than fix a non standard IE bug. Either re-mark invalid or push to M300 P5 severity trivial. Fabian.

You can reproduce this problem by using <span> instead of <marquee> and foo() instead of start() So it'll appear on any page on which an external JS file can't be fetched, for example...

I investigated some, and cropped the file down to a testcase. The mouseOver() is the problem here. When we drag select text *and* mouseOver the <i/span/marquee> (or some other tag) the image gets "forgotten". Also, we can get it removed all at once by doing a "Select All" after the image is forgotten. Marking NEW

jst's patch makes this bug disappear for me (linux cvs build from 2001-01-05 source)

The patch I just attached fixes the problem where background images (in tables or attached using css), the problem shows up in at least two cases, someone calls window.stop() or the user clicks the stop button. Also see resource:///res/samples/test2.html for a css sample of this bug, click on the stop button after loading that page and notice that the animated background image doesn't paint any more. I don't know enough about the image loading code in nsPresContext to say if this is an acceptable fix but it seems to fix the problem w/o bad side effects so far. Cc:ing Steve to get his input here, Steve, please have a look at the patch in this bug.

This patch works very well, why isn't it added to mozilla ?

jst, your changes are in a part of the code I've never looked at before. I suggest you get evaughan to review, because he wrote the code that you're modifying. After you convince him it's the right thing to do, I'll sr.

Over to Pavlov since he's rewriting all this code, Pav, make sure this works in the "new world".

I don't want to nag, but this bug is not too minor, and we have a working patch.. (And less than 10 days till 0.9 freezes)..

the patch won't work with the new imagelib.

this might actually be partially fixed.. some animations probably continue even after you hit stop.

Hmm, bugs seems to be fixed.

-> 0.9.4 per Pavlov

.

It's definitely WFM on Linux 2002012808 build