From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; 0.9) Gecko/20010302 BuildID: 2001030205 In case of new Mozilla window with (crtl+n with preset url in preferences or "Open Link in new Window" or possibly some other way) and quickly taskswitch/hide before anything is shown inside new window, with creat chance of that is when You taskswitch/get focus on this new window (after some time to let this page to load) You see blank page, but if You move something over this void mysteriously elements are appearing. Reproducible: Sometimes Steps to Reproduce: 1. Choose a webpage with slow connection to your machine (or disable cache) (http://www.neti.ee works fine for that purpose to me). 2. Set this page to Your homepage at preferences, and let Mozilla open this window at startup. 3. ctrl+n or similarly behaving procedure such as open link in new window. 4. After new Mozilla window appears but before it starts reading content of given URL, perform somesort of hiding this new window (taskswitch/minimize). Actual Results: When returning back to this new Mozilla window often this window is empty. (If You move mouse over this page, page elements start to show up.) Expected Results: Visible webpage. This behaviour is present in Mozilla daily buils for some time now, but I do not remember seeing it before Mozilla 0.8.
First le me say this is an excellent bug report. However I think this issue is covered in bug 66034. Could you please confirm that this is a duplicate of bug 66034? Thank you a lot!
Yes, bug 66034 seems to be similar. But why this "Viev Page Source" (ctrl+u) thing happens always? This Source window starts loseing window components (dragbars) as soon as this window goes outside of screen borders (when dragging this window around screen) but not content. As from this I started experimenting... I manage to get regular Mozilla window to lose dragbars but not the content with dragging Mozilla window dragbars outside of screen. This trick only work when I create a child window from demaximized parent window and then drag this new window outside of screen border. If after lose of dragbars I additionally minimize or switch to window which covers this first one, after turning back to it content of it is blank, but there is a exception. Mysteriously after all that if I rezise child window little larger (less than dragbar width) and perform the same dragging, minimize, refocusing this area of blanking is still the same size and part of dragbar does not disappear so area what is getting blanked is in size of parent window. All this brings up an idea that at some point Mozilla does not remember what part of Mozilla window must be redrawn or it some strange way founds there is phantom window on top of this window (only parts what are outside of it are redrawn). Maybe it is Windows problem after all?
I tested this resizing behaviour (it is not involved only to dragbars, but whole content of window) on View Page Source, and it does reveal it there - if source is large enough or source window is initially small, when minimizing this window and then refocusing to it, only blank area is initial source window size. So it is definitely not blank page what is shown, but window what is somewhat filled with white or this "not-knowing-this-part-of-window-must-be-redrawn-thing". (Testing reveals: it is not the size of parent window what is blanked, but it is this child window initial size.)
As it turns out all these "effects" on source window apply to normal Mozilla windows as well. Not only to this dragbar issue, but to whole page. Only trick is to get window lost dragbar at the first time: 1) start Mozilla 2) ctrl+n 3) demaximize it if possible, so there are both dragbars on this window, and it is possible to drag whole window around screen 4) ctrl+n 5) drag new window over the borders of screen 6) drag it back to fully visible 7) if dragbar is still visible go to 4 8) resize this window larger (lot larger) 9) minimize this window 10) maximize this window back 11) there should be white void (about) the size of original window, but other parts of window are shown For me this scenario works.
Not "maximize" but "regainfocus" in point 10.
Another scenario to get this behaviour to appear: 1) start Mozilla 2) ctrl+n 3) demaximize this window 4) ctrl+n 5) maximize this new window 6) minimize this new window (shrink to taskbar) 7) regainfocus this window from taskbar 8) there should be white void (about) the size of original window, but other parts of window are shown
This is what is covered in bug 66034 (although there is talk about the page source page it is really a bug that covers everything). Marking as duplicate *** This bug has been marked as a duplicate of 66034 ***