The content are flash when I have a blank tab open and open another one. How to reproduce: 1. Command+t once 2. Command+t another time Result: The content are flash. As in turning from white to grey, then back to white again. The problem first occurred in the 2007.11.02 nightly build. This build is fine: 2007110101, while builds starting with this one flash: 2007110202 Unable to reproduce in Firefox trunk.

Area, not are

Seems to be a regression from bug 401312

This is specific to blank tabs as far as I can tell; new tabs with a normal page loading are immediately white.

I've been noticing this recently when opening a view-source window.

Just wanted to confirm that I see this as well. Also happens upon launching Camino if you have a blank homepage.

Kai, when you reported this, were you reporting it on 10.4 or on 10.5? Is anyone seeing this on 10.4 and/or Intel? I definitely see it on 10.5/PPC.

Still seeing this on 10.5/Intel, both with the STR in comment 0 and when opening a view-source window, as noted in comment 4.

I reported using 10.5/Intel, and I still see it using the 20080907 build

Like bug 313811, this is barely noticeable to me. If it's really bad on slower Macs, we can restore the 2.0 milestone if someone will own the bug.

I tracked this down, and it is, as I suspected, definitely a core bug. I don't know if it still exists on trunk or not; Josh, you should check, and file a new bug if so. The problem is that the first paint event when we open a blank tab ends up in the didResize case of http://mxr.mozilla.org/mozilla/source/view/src/nsViewManager.cpp#1039 That means that the next block, where painting would actually happen (which is conditional on !didResize) doesn't execute, and it simply stops without painting anything. Since ChildView is claiming to be opaque, it is not okay for it to simply refuse to handle a drawRect: like this. As a result, the window background shows through on that paint cycle. Since the chances of this getting fixed on 1.9.0 are probably really low, I'm going to leave this as a Camino bug to try to figure out a workaround. That case does say it ignores the event; maybe that's detectable in ChildView and we can mini-fork, or get an #ifdef block landed. Alternately, maybe I can find a way to avoid that case.

This should fix the bug (although I'm having trouble seeing the effect today). I didn't dig deep enough to find out if there's some magic way we can avoid this case, so it's a ChildView patch. We can either minibranch to take this, or we can try to get it landed in 1.9.0.later and take it for 2.0.x. Josh, in case we do decide to try to take this for 1.9.0.x (and/or in case you want to take something like it on trunk, since drawRect there still doesn't check to see if drawing actually happened), can you take a look?

Per discussion, we don't want to deal with minibranching just for this. Let's try for 1.9.0 instead (#ifdef'd if necessary, but this seems like something all clients would want)

Comment on attachment 408300 [details] [diff] [review] fix If this goes on 1.9.0 I want it ifdef'd Camino only. We need to be really conservative there. As for the patch's correctness, I'm OK with it if Markus is OK with it. He has looked at that code most recently. Markus - if you don't want to be the reviewer here let me know and I'll do it.

Comment on attachment 408300 [details] [diff] [review] fix I think this patch is fine.

Maybe this patch even fixes bug 519852.

Looking at the picture in bug 519852 again, probably not... there's more going wrong there.

I ran in to this tonight and it reminded me this bug was still here; can we get the dance started to get this patch in?

I'll post a patch with #ifdef. Josh, who should I tag for sr?

This doesn't need sr, it doesn't change any interfaces. Josh, do we want this patch on trunk? I think it makes sense to take it.

Markus - I'll take your word for it, you know as much about this as I do. Your peer review is fine for a trunk landing.

(In reply to comment #22) > http://hg.mozilla.org/mozilla-central/rev/6bcd0f69ca6c Don't forget to land it on cvs trunk, too, per comment 14, once approval is granted.

This exact patch isn't going on 1.9.0; see comments 14 and 19. When I post a patch, I'll request approval, and when that gets approval, I'll land it.

Same patch, but ifdef'd to be Camino-only per comment 14. (If it's too late for .16, please consider for .17 instead; I'm not sure what the schedule is)

Comment on attachment 411700 [details] [diff] [review] Branch fix Approved for 1.9.0.16. a=ss for release-drivers. Please land as soon as possible as we're already past code freeze.

Thanks; landed on CVS trunk for 1.9.0.16.