Build: 2001071303 Platform : Mac OS X Expected results: Qt movie should be repainted after scrolling occurs. What I got: Artifacts of the movie are painted all over the window. Window is not updated after scrolling is completed. Steps to reproduce: 1) Go to url: http://www.apple.com/macosx/theater/dock.html 2) When movie starts to displays, vertical scroll the window. 3) Notice the QT movie is repainted after scrolling window.

This problem isn't occuring under "Classic" mode with the Mac OS 9 build (2001071303).

Oops. Step 3 should have said: Notice the QT movie is "not" repainted after scrolling the movie.

changing QA to OS X guy: Petersen :-)

Mac plugin bug---->peterl

*** Bug 95925 has been marked as a duplicate of this bug. ***

This happens in IE 5.1 with Quicktime too which leads me to believe it's not completely our fault (we do worse that IE). It looks like an update/slowness issue and we don't correctly invalidate the dirty area left behind.

Yeah, our carbon code doesn't correctly invalidate when scrolling. See also bug 86729. I was lame, I need to make that code work for carbon. see nsWindow::ScrollBits();

smfr, i already rewrote scrollbits to use the os on osx and remove all our hacked code. i would assume you sr'd it ;)

I don't think the OS call deals with scrolling dirty regions as well. I'd be surprised if it did.

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)

*** Bug 121300 has been marked as a duplicate of this bug. ***

this still happens, but it happens on windows as well, this is not mac specific

this is easy to reproduce -- I will show you Peter when you want to see this

*** Bug 91906 has been marked as a duplicate of this bug. ***

*** Bug 160271 has been marked as a duplicate of this bug. ***

*** Bug 160271 has been marked as a duplicate of this bug. ***

Simon Fraser fixed a similiar problem in Chimera. Perhaps his fix there should be ported to the Mozilla tree?

See also bug 160435.

Just thought I'd comment that I tried the URL from the original description just now and this is still happening in Moz 1.4b.

testcase URL no longer valid

This bug has outlived it's usefulness.

I'm too embarrassed not to apologize for typing "it's" when I meant "its". Sorry for the spam!