Go to a page, say the nscp homepage Open a link in a new window from context menu notice the serious flashing. it appears double buffering is turned off. Now close the window and open the link just by clicking. No flashing. Copying the link and pasting it into a new window doesn't show any flashing either. it's something about using the context menu.

The double-buffering should only be disabled when the page contains a plugin. Peter, can you double-check to make were not turning the double-buffering off in other cases. Set a breakpoint in nsViewManager2::AllowDoubleBuffering and see if it gets called when opening the link from the context menu.

Nope, nsViewManager2::AllowDoubleBuffering is not being called and I don't even see the flashing.

oddly, i don't see this in current builds. Must have been a one-time fluke. *shrug* I'll try again with monday's builds (i can't seem to pull today's) and will try again. If not, i'll close it down.

ok, just tried this with a 1/29/01 build and it's fine. guess that early build was smoking crack and didn't give me any. invalid.

well well. it's happening again. 1/31/01 build.

this happens on _both_ my desktop and my powerbook with 1/31/01 build (classic skin, haven't tried others) so it's not just a random fluke. opt build, installed from sweetlou.

ok, it's not that double buffering is turned off. I've stepped through the view code and it appears that one of the passes we make to paint the views ends up drawing a chunk of the gray background into the content area, which is then painted over at a later time. The change from content --> gray --> content is what causes the (very) visible flashing, and also explains why the chrome is not visibly affected. Any ideas what this could be? Some weird layout state or something leftover from window loading? It goes away once you load another page in this window...but for that one page it's very annoying, especially with animated gifs (ugh!)

i traced this through (painfully) and it appears that in the case where we get flashing, there are two additional views that get painted. why? who knows. one does nothing, it seems, and the other blits gray bits when asked to draw. these views go away when the page is reloaded in the window. if anyone wants to see the exact steps we go through when painting, i've got them on paper ;) another interesting note, on mac there are 4 views involved in resizing the main window. on win32 (which doesn't exhibit this problem as i can tell), there are only _three_ views. Why do we have so many extra on mac? suggesting a milestone and nominating for beta. my brain hurts.

i've also noticed that opening a new window with a link (foxnews US news page) creates 29 views. on win32, only 20 are created. why the discrepancy?

good or bad, loading tinderbox on each platform creates 7 views. luckily they are the same. the bad news, why do we have to create 7? tinderbox has no text fields or form controls.

of course, this doesn't seem to happen in viewer. it still happens with the sidebar hidden.

(sorry for all the spam) this doesn't happen when the link has a TARGET set so that a new window opens with the url. It only happens with cmd-click or "open link in new window" context menu item.

Simon Fraser said on bug 66034 that he thinks 66034 is related to this bug.

Mike: how may viewmanagers do you see constructed? Every new document we open is loading an "about:blank" document and leaving it around in "SeaMonkey", but not in viewer. This is covered in bug 66034. This is the same bug as 66034 if the viewmanager that renders the grey rectangle over the top of the content was created by the about:blank document. To determine which viewmanager's was created for the about:blank document set a breakpoint on the nsViewManager2's constructor. Goto the stack frame where the document is being loaded and see if the channel url's mURI is about:blank. If it is record the ViewManager instance's address.

If someone could look at this with a .8 branch build it would help confirm its the same bug as 66034, as that was corrected on branch by a patch being backed out of the branch.

the 2/15/01 moz0.8 branch still shows this problem on macos

Reassigning to Waqar.

Setting milestone to 0.9.1 and priority to P3.

this is most certainly the reason i use IE at home.

I tried to reproduce this but I am do not see flashing, what I did was go to netscape.com and command click on a link, control click and chose open link in new window I do not see flashing. I pulled the tree this morning. I tested with and without sidebar. I paints just as if you click on a link. Mike can you try this with todays build and test?

ok no way. i'm going crazy. it does it in the 3/6 build, and it doesn't do it in today's build. what changed? did the new view manager land? did someone fix something? I find it hard to believe this one just went away, and I fear it will come back until someone gives me some good evidence. let's keep this open for a while longer....

jag pointed out that changing: edit navigator.js, replace appCore.setDefaultCharacterSet(aCharset) (at http:// lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/navigator.js#874) with |getMarkupDocumentViewer().defaultCharacterSet = aCharset;| makes the flashing return. sounds like the doc viewer is holding onto about:blank and that this bug is basically bug 66034. why is it mac-only?! who owns the charset stuff? probably not waqar.

I'm resolving it as a dup. The behavior of this bug is different between Mac, WIN32, and Linux probably because there a two view managers trying to render to the same window. The order in which the paint messages are dispatched will determine who's on top. On the Mac the about:blank viewmanager probably gets the paint first, followed by the viewmanager with the real content. On WIN32 they seem to fire in the opposite order, sine view source and other windows tend to be rendered blank, because the about:blank documents viewmanager gets the paint message after the content document's viewmanager. *** This bug has been marked as a duplicate of 66034 ***

verified dups