If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Browser/page elements are not (re)drawn after regainfocus in case of window was loaded at background/hidden.

VERIFIED DUPLICATE of bug 66034

Status

SeaMonkey
General
VERIFIED DUPLICATE of bug 66034
17 years ago
13 years ago

People

(Reporter: ivo, Assigned: asa)

Tracking

Trunk
x86
Windows 98

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: DUPEME)

(Reporter)

Description

17 years ago
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.

Comment 1

17 years ago
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!
Whiteboard: DUPEME
(Reporter)

Comment 2

17 years ago
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?

(Reporter)

Comment 3

17 years ago
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.)
(Reporter)

Comment 4

17 years ago
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.
(Reporter)

Comment 5

17 years ago
Not "maximize" but "regainfocus" in point 10.
(Reporter)

Comment 6

17 years ago
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

Comment 7

17 years ago
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 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Comment 8

17 years ago
verified
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.