On: Ubuntu Karmic fresh install, Nvidia 185.18.36 proprietary driver, tested with both Flash 10.0 r42 and Flash 10.1 d51 beta drivers.
Pages with flash animations and flash videos are mostly broken for me on both trunk and the 3.6 branch, lots of repainting issues, especially when you scroll the page. Firefox 3.5.6 does not have this problem with the same shared plugin.
You can see an example here with a screencast:
Doing a binary search with regression.py I identified this regression window:
Last good nightly: 2009-10-01 First bad nightly: 2009-10-02
Hg log for that day indicate several checkins related to flash, plugins and video that may have caused the regression:
Bug 508908 - "ASSERTION: Configured widget is not a child of the right widget" with Flash and <select size=1> with scrollbar
Bug 508495. Let CSS borders and padding apply to plugin elements, and fix layout, painting and event handling to work with them.
hey pascal, what is the url for that screen cast or another one where you see the problem. we should try to get a reduced test case.
here is one:
But the problem is visible on almost all pages with big flash apps
Jeff, Joe: is this the same as the bug we talked about months ago? As I recall, I marked that one not-blocking, but it was more to do with Java, right?
cc'ing a bunch more layout and plugins people to see if anyone can identify the regressing patch. Pascal, if you could toss out a few more URLs, that'd help a lot, too.
David: are you seeing this as well? IIRC, you run Linux most of the time.
Sorry for bugspam: Pascal, are you also up to date with the latest Flash?
Mike, as indicated in my comment 0, yes I have the latest version of Flash for Linux, I also tried with the next beta version of Flash 10.1, same issue.
All of Deezer UI has repainting issues but I guess you need to create an account there:
Here is another example:
There is a cartoon-like moving character in the lower part of the page that says "suivez moi dans mon atelier" that has rendering problems, especially of you mouseover him.
Pascal: do you see this problem when using trunk? It may have been fixed by 518506.
Regression range in comment 0 is consistent with bug 526797 comment 5, suggesting that this is likely the same cause.
(In reply to comment #2)
> here is one:
I see weird painting behavior on this page on today's mozilla-central and mozilla-1.9.2 Linux x86_64 nightlies. It seemed fine in the mozilla-central nightly from September 17. I have Shockwave Flash 10.0 r42.
And, to clarify, I see weird flickery painting and missing (or only very briefly appearing) pieces of the flash UI even without scrolling at all.
(In reply to comment #8)
> Regression range in comment 0 is consistent with bug 526797 comment 5,
> suggesting that this is likely the same cause.
The appearance certainly seems consistent with problems handling partial invalidates.
@Jeff, I see this problem with latest trunk, the last trunk build without this bug is the October 1st one.
FWIW, I also see a form of this at the front page of http://jungledisk.com
On that page, the headings "Let the cloud free you from the limitations of local storage", "Already a Customer?", and "Latest news" are all flash objects. If I make the window short enough so that those aren't visible, and then slowly scroll them into the viewport (by gradually dragging the scrollbar), they don't immediately repaint (i.e. they're initially blank).
I'm pretty sure this is the same root issue -- at least, it has the same regression range. The 2009-10-02 mozilla-central nightly is the first one to be broken.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091002 Minefield/3.7a1pre
One thing to check is that all the problematic Flash instances are in windowless mode. The issues in bug 526797 only appear in windowless mode.
Karl, I think we could work around this by always repainting the whole Flash instance, right? That might be worth doing.
In particular the issues in bug 526797 seem to appear when the top-left of the invalid rect is not the top-left of the plugin instance rect. We could simply extend the invalid rect so they're always the same.
*** This bug has been marked as a duplicate of bug 526797 ***
(In reply to Jeff Muizelaar [:jrmuizel] from comment #7)
> Pascal: do you see this problem when using trunk? It may have been fixed by
I dont understand :(