Closed Bug 93558 Opened 23 years ago Closed 23 years ago

some UI windows are initially blank when you first start them

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: grylchan, Assigned: dbaron)

References

(
URL
)

Details

(Keywords: regression, smoketest, topembed, Whiteboard: fixed-on-trunk)

Attachments

(4 files)

Screenshot of garbled download window
110.26 KB, image/png
Details
Screenshot showing screwed font instalation dialog (see my post just above)
31.30 KB, image/jpeg
Details
possible patch (is bug 70258 still fixed?)
2.65 KB, patch
Details | Diff | Splinter Review
possible patch (but I can't figure out how to test the original bug)
3.01 KB, patch
Details | Diff | Splinter Review 
Using commercial trunk builds:
2001-08-03-10-trunk/ NT 4.0
2001-08-03-08-trunk/ linux 2.2, redhat 7.0
2001-08-03-08-trunk/ mac 9.0.4

Not sure if I got the right product/component set. If not,
I apologize in advance.

When you visit a pop up/stand alone window
for the first time, they appear blank (white). If you cancel
the window and revisit it again, it appears normal.

Noticed this in both classic and modern themes and on all
platforms. But maybe this is tied to some UI bug out there.

In order to replicate you have to create a brand new profile 
each time. Using an existing profile didnt work (at least for me).

Test 1.
1.Install trunk build.
2.Bring up profile manager
3.Click on 'Create profile'

result: Create Profile Manager window is blank
        The only button that works is 'cancel'.
        -If you click cancel and retry, the screen
         is filled out correctly.

Test 2.
1.After creating a profile from test 1, browser starts
2.Click on mail icon
3.Account wizard and IM Manager window pops up

result: Account wizard window is blank. 
        Click cancel and repeat, Account wizard window is fine.
Test 3.
1.after setting up your imap mail account from test 2.
2.Click on the mail account server in Messenger in order
  to bring up Account Central page

result: Account Central Page has lost the icons and links.
        Click cancel and repeat, it will look fine.

Test 4
1.From Test 3 in Messenger, go to File|Offline|Download and Sync Now
2.Click the "select" button

result: 'Items for Offline Use' window is blank
        Click cancel and repeat, it will look fine.
Link to screen captures of the various windows that I am seeing.
(internal link)
http://blues.mcom.com/users/gchan/publish/93558/test.html

I can confirm this with win2k build 20010803.. (CVS)
I got a browser window without any toolbars, only the window title and my loaded 
homepage. (a restart fixed it)
I got also a near blank ProfileManager..
Severity: normal → major
Keywords: regression
Whoops, that was a cookie manager window, not a download window.  I've seen that
on the mail/news account manager also.
I'm also seeing a blank window when trying to install the Aqua theme 
(http://www.simweb.net/eric/projects/Aqua) using the 080508 nightly & a cvs 
build on win2k.
I see this behaviour on Win98SE Moz build 2001080508 when the "download font
dialog pops-up on http://microke.myrice.com/
By the way, I just noticed looking to my screenshot that the dialog window
doesn't have a Title and that the "s" at the end of the word "components" is
halfway off the window. does anyone knows where to report this ?
*** Bug 93954 has been marked as a duplicate of this bug. ***
CC brendan who made the fastload stuff
I know it's disabled by default but this bug starts after his checkin and it's
maybe a regression from his checkin - sorry if I'm wrong !
Someone will have to debug a bit more before pointing the finger at the pref'd
off FastLoad landing.  It could be, but until someone debugs and finds new data
to discuss, what can be done?  I'm not going to try to back out my FastLoad
changes, now entangled with others, to see if that treats a symptom.

/be
Has anyone observed this in a build prior to 8/03? It seems to me that was when 
this first was observed, and in the case of the profile manager blank window, 
it is 100% for me on win2k with 8/03, and 0% with 8/02. 

That mostly absolves fastload, since nothing for fastload landed in 8/02->8/03
(never, say never, but ...).

I've attached the list of checkins for that interval, although nothing leaps 
out at me. 

Can anyone reproduce the blank createprofile iframe in a debug build? I can't 
believe there isn't some kind of assertion being tripped.
URL: http://bonsai.mozilla.org/cvsquery.cg...
Possibly other related bugs?:
 bug 93476, bug 93488, or bug 93562 
as they all mention blank windows.
For the specific case of profilemanager, I can see that the XUL for that 
inner iframe is not successfully loaded from the JAR file on the first 
attempt (never calls nsJARChannel::OnStopRequest). On the second attempt
(do cancel, and try again) it is loaded OK [and on subsequent references,
it is pulled out of the XUL cache].

The rest of the defects are consistent with a failure to load a resource
from a jar file.
*** Bug 93476 has been marked as a duplicate of this bug. ***
*** Bug 94497 has been marked as a duplicate of this bug. ***
*** Bug 94528 has been marked as a duplicate of this bug. ***
Most of the time I'm also getting a blank window starting mozilla -mail. Happens
whether starting offline or online, but haven't figured out why it comes up OK
once in a while. I haven't checked a build from 8/3, but it has happened on the
win32 builds I tried from 8/4, 8/5 and 8/8. I don't see any problems of this
nature on the 8/2 build. The New Account window comes up fine the first time in
8/2, but is blank in the other builds.
*** Bug 94696 has been marked as a duplicate of this bug. ***
Darin, can you (or someone) have a look at this. I believe this is failing to 
pull certain resources out of Jar files, and that horks these dialogs.
Keywords: nsBranch
*** Bug 94878 has been marked as a duplicate of this bug. ***
This happens for me in W2K build 2001080110. Windows such as "connection
refused" and "text not found" open blank, apart from OK/cancel-buttons, which
are not working. Shutting down mozilla, closing quicklaunch and restarting
mozilla makes it go away.
*** Bug 94992 has been marked as a duplicate of this bug. ***
This is causing all kinds of problems (likely including bug 93889 ).  There are
workarounds for most of these problems so technically it isn't a blocker but I'm
flagging it as such to keep the tree closed until we get some traction on this. 

--Asa
Severity: major → blocker
Keywords: smoketest
Adding people that have checked in in the last few days.
I am also seeing this in mailnews account manager when you are trying to 
add a new account. 
Note that this started happening with builds of 8/03 (i.e., 8/02 checkins).
In particular, the create new profile missing the first panel has been that
way all this time (so, we're not looking for a checkin in the last couple of 
days :-]
waterson's checkin for bug 70258 looks like a possible suspect, given the
8-2/8-3 time frame.  The two parts of the change should be independent (I
think).  I've only seen this bug occasionally (is there a particularly reliable
way to reproduce?), so I can't really test this guess.
OK, I finally realized jrgm was talking about "Create Profile", not the profile
manager in general, and undoing waterson's checkin does seem to fix that case
(well, I tried one attempt each way, but if jrgm says it's pretty much 100%...).

->waterson
Assignee: pchen → waterson
Component: XP Apps → XP Toolkit/Widgets: XUL
*** Bug 94960 has been marked as a duplicate of this bug. ***
Dbaron, nice catch! I just verified that backing out waterson's checkin for
nsCSSFrameConstructor.cpp makes the profile manager show up correctly.
QA Contact: sairuh → jrgm
I think the reason we're seeing a problem is that the frame returned from GPPF
is one frame too high in the hierarchy, so docParentFrame ends up null.
QA Contact: jrgm → sairuh
Yeah, GPFF is returning the Box here:

Viewport(-1)@0x83c2f00 [view=0x83a9948] {0,0,12,12} [state=00042004]
[content=(nil)] [sc=0x83c2e2c]<
  RootBox(-1)@0x83c2f3c {0,0,12,12} [state=01840004] [content=(nil)] [sc=0x83c3004]<
    Box@0x83c33fc {0,0,12,12} [state=01840004] [content=0x83ae640] [sc=0x83c325c]<

GPFF...what?
GetPrimaryFrameFor
QA Contact: sairuh → jrgm
With fastload enabled, the first time Chatzilla is loaded in a Mozilla session,
the chrome seems fubar.  I think that may be a test for this bug?
In bug 70258, we expected the XUL's root frame hierarchy to appear like this:

RootBoxFrame(window)<
  GfxScroll<
    ScrollBoxFrame(window)<
      ScrollPortFrame(window)<
        (etc.)
      >
    >
  >
>

Has that changed?
To test the original bug (bug 70285), try to load a directory listing in viewer
or gtkEmbed.
dbaron seems to have this in control.
Assignee: waterson → dbaron
Testing in gtkEmbed shows that the bug 70258 is still fixed (and when I comment
out the loop in my fix it is broken, so the fix is still needed).
Patch seems to fix all blank window problems i have seen: "mozilla -mail",
cookie dialog, download dialog and "mozilla -chrome
chrome://embed/content/mini-nav.xul"

Linux is still missing download dialog if you select "Save Link
As..." from context menu. Maybe that is other bug?

r=jst
Please apply these changes to MOZILLA_0_9_2_BRANCH, as well. Thanks!
Tomi: The context menu problem you see is bug 94990 (6 dups in one day - no idea
why not a blocker)
Fix checked in to trunk -- lowering to critical.  However adding topembed since
this may need to go on the branch as well (since I think the fix that caused it
is on the branch).
Severity: blocker → critical
Keywords: topembed
Linux note: please try testing embed stuff with TestGtkEmbed,
gtkEmbed should go away at some point since it's not getting
much attention.

*** Bug 94960 has been marked as a duplicate of this bug. ***
*** Bug 94682 has been marked as a duplicate of this bug. ***
*** Bug 95185 has been marked as a duplicate of this bug. ***
Whiteboard: fixed-on-trunk
jrgm@netscape.com, has it beeen verified on the trunk? If yes, please change the
status whiteboard to verified-on-trunk and let's land on the 0.9.2 branch.
verified on on commercial trunk builds:

windows 2001-08-14-06-trunk
linux 2001-08-14-08-trunk
mac 2001-08-14-04-trunk
Whiteboard: fixed-on-trunk → verified-on-trunk
david, can you land it on the branch?
Whiteboard: verified-on-trunk → fixed-on-trunk
Checked in on branch, 2001-08-15 17:29:52 PDT (rev 1.601.2.6).
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Even better news! This also fixes the fast theme switching which was broken.
(I know that it's not currently being used but that's no excuse to break it).
*** Bug 94682 has been marked as a duplicate of this bug. ***
verified...I have not seen this problem on branch
Status: RESOLVED → VERIFIED
I see #100700 on the trunk (Mac-specific).

Are bug 100551 and bug 100244 related to this bug? Can someone verify?
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: