Not with a dojo project, with a .NET project that would return a completely blank page after a postback. Turned out the proxy server was returning a 413 (Request Entity too large) error which IIS didn't know how to handle, so we were getting a correctly formatted but completely blank html page. We had to turn the viewstate off for our datagrids which reduced the viewstate from about 100,000 characters to less than 10,000 (I don't remember the exact numbers but it made a huge difference) and we never got that error again.

Not saying this is your exact problem, but first thing I would do is to check exactly what is getting passed back and forth between the server and your browser. You can try using Fiddler (it's how we figured out the 413 error message): http://www.fiddlertool.com/fiddler/.

The difference is that the page itself is not getting reloaded at all. I'm refreshing individual widgets via Ajax calls, so the only data coming to me from the server would at most populate subwidgets.

I'm experiencing very similar behavior in Firefox. First, I thought it was only happening when the Firebug pane was open, but I am now seeing it during browser window resizing as well as opening a dijit Dialog when a "footer" div (LayoutAlign="bottom") has a height greater than 1em.. :-/

This is with Dojo 1.0.2

Removed a rather long post which had a bunch of HTML code that had no real bearing on the actual problem (see solution below)

I believe I have this one solved: The CSS for the overall page wasn't set up quite properly. In figuring out how to get my tab container areas to fill 100% of the viewport, I added this to my CSS:

This resulted in both getting those tab areas to fill 100% of the screen, as well as apparently solving the various points at which my page was disappearing (opening that dialog, resizing the window, expanding the Firebug pane, etc)

And I think I might have figured out mine as well.

I have a "reload" interval which refreshes a tree periodically. However, sometimes it's called twice in a row. Because there's no way to refresh a tree other than destroying it and recreating it, apparently the interleaving of the two calls ends up with an widget which isn't really attached to its DOM node yet. For some reason, this causes the entire screen to disappear. I don't know why, but I think I can at least stop it from happening...

This bug is still happening. I took a look at Firebug when this was occurring on page load, and it looks like almost the entire DOM is gone (with the exception of a "loading" div at the top). Not even the original HTML is there any more.

I'm using 1.02 now (very leery of switching to 1.1 with all the changes that this would require... I have over 1000 lines of custom Dojo code).

Any ideas would be greatly appreciated. This only happens a small percentage of the time, but it's a killer.

...that includes using document.write somewhere in your code. If the entire DOM is being wiped, it's pretty likely that the code calling document.write is happening after DOMContentLoaded (what we use for dojo.addOnLoad functions); calling document.write like that will destroy the entire document as it opens a new stream for writing.

First thing I'd be looking for is where and how any document.writes are being done; and from your brief description I'd start looking somewhere around where your loading div is created.

I'd also suggest that the move to 1.1 should be pretty painless; the API did not change, it should be fully backwards compatible.

The APIs aren't changing, but in order to fix the bugs we had then, and to extend behavior correctly, I often had to go very deep into the code and extend very specific parts of various widgets. I doubt it'll be painless.

As for document.write, I am not using that anywhere in my own code. A search for it has only turned up results in Dojo itself. They include:
-Rich Text Editor - we don't use this at all, so it's not there.
-A bunch of test files.
-dojo.base.loader.hostenv_browser.js - but this only executes inside an "if (dojo.isIE)" block, and this bug is happening on Firefox as well.
-back.js - we're not using this either.
-Several dojox.* JS files (Flash, offline storage) which we also aren't using.

So it looks like it isn't a document.write problem. 8-\

...but at this point, without seeing the code there's not really any suggestions that come to mind. It just sounds to me like *something* is wiping out the DOM when it shouldn't be, and to date I haven't seen (or heard of anyone other than on this thread) the issue you're describing.

Usually that means there's something you've done that's causing it (whether or not you intended that), which is why I mention seeing the code.

If there's a way you can create a test case for us to try to use to reproduce it, that'd be awesome.

I wish. -_- Unfortunately the full code is enormous, and the problem only shows up intermittently at seemingly random intervals. There also might be copyright concerns with me posting it here.
My company has a Dojo group I might look into asking.

Thanks very much for your help. If anyone has any other ideas I'd love to hear them!

...if you happen to stumble on a test case that works consistently, let us know and we'll try to address it.