Steps to reproduce: 1. Create some profiles 2. Choose rename and/or delete Actual results: profile manager exits Expected results: profile renamed and/or deleted and return to profile manager. Build 2000010208 and build 2000010308 on Linux only Build 2000010208 on Win is ok, Mac to be tested next

Bhuvan, we need to look at this to see how serious it really is.

Grace, Can you check if we can reproduce this...? Thanks.

I am still seeing this on today's Linux build (2000010408) I do not see on the others Come by if you want to view.

Seth, If you have good build on Linux....Will you be able to find out the code segment that's closing the app. I'm thinking the Close or quit operations are just cloing everything on Linux which was never the case in the past. Thanks. Bhuvan.

build 200010516 : running ./mozilla -installer and using Profile Manager to create a new profile, rename or delete current profiles - causes me to exit - not return to Profile Manager after creation or rename/delete activity. Note-profile does get created and can be used next launch, profiles do get renamed/deleted but there is a disconnect before coming back to Profile Manager to press start

There is an assertion in redrawing the profileManager window. When we are in profiel manager, we open separate windows to create a profile, rename and delete a profile. Once any of these operations is done, we try to redraw the profile manager window to reflect the changes just made. HTML reflow mechanism seems to be missing a rendereing content in this context. Adding troy and travis to the cc list. NOTE : This happens only on Linux. Here is the console log... /home/cck/mozilla/dist/bin> ./mozilla -ProfileManager .//run-mozilla.sh ./mozilla-bin -ProfileManager MOZILLA_FIVE_HOME=/home/cck/mozilla/dist/bin LD_LIBRARY_PATH=/home/cck/mozilla/dist/bin SHLIB_PATH=/home/cck/mozilla/dist/bin LIBPATH=/home/cck/mozilla/dist/bin MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= nsNativeComponentLoader: autoregistering begins. nsNativeComponentLoader: autoregistering succeeded nNCL: registering deferred (0) nsUnixToolkitService: Using 'gtk' for the Widget Toolkit. nsUnixToolkitService: Using 'gtk' for the Gfx Toolkit. NS_SetupRegistry() MOZ_TOOLKIT=gtk, WIDGET_DLL=libwidget_gtk.so, GFX_DLL=libgfx_gtk.so initialized appshell GFX: dpi=96 t2p=0.0666667 p2t=15 depth=24 WEBSHELL+ = 1 ProfileName : root ProfileDir : /root/.mozilla/root Note: styleverifytree is disabled Note: frameverifytree is disabled Note: verifyreflow is disabled WEBSHELL+ = 2 WEBSHELL+ = 3 calling loadpage... startPage:: newProfile1_1 got a request got a request WEBSHELL+ = 4 warning: property locale.all.ET_ET already exists ProfileName : cool ProfileDir : /root/.mozilla/cool WEBSHELL- = 3 WEBSHELL- = 2 nsWidget::~nsWidget() of toplevel: 14 widgets still exist. WEBSHELL- = 1 ###!!! ASSERTION: no rendering context: 'nsnull != aRenderingContext', file nsHTMLReflowState.cpp, line 49 ###!!! Break: at file nsHTMLReflowState.cpp, line 49

Reassinging the bug to troy (please reassign if there is a rightful owner), as I could not find anything that profile manager did lately to cause this behavior.

I have no idea what this has to do with layout. Marking INVALID...

troy, this bug is not invalid. it may not be a layout bug, true, but that doesn't make it invalid. just re-assign it, if it isn't yours.

re-assign to racham, add troy to the cc list. racham, I see the bug, and I'll investigate.

re-assign to racham

Seth, Please look at the console log in one of the bug updates. An assertion is getting caused by HTML reflow. But why this is happenig with only Linux is still a question.

it's a crash. we are calling ComputeLineHeight() in nsHTMLReflowState.cpp with a null nsIRenderingContext. the assertion that racham reported happens before this, and is related (as the nsIRenderingContext is null there, too. ###!!! ASSERTION: no rendering context: 'nsnull != aRenderingContext' I'm investigating.

ok, I have some sort of clue what's going on. the reason it's linux only is we eventually fail nsRenderingContextGTK::Init() using the debugger, I'm seeing that eventually, nsRenderingContextGTK::Init() returns NS_ERROR_NULL_POINTER both GdkDrawable *win = (GdkDrawable*)aWindow->GetNativeData(NS_NATIVE_WINDOW); and GtkWidget *w = (GtkWidget *) aWindow->GetNativeData(NS_NATIVE_WIDGET); have failed to return something non-null, so we return. here's the stack at the point right before we return a failure. #0 nsRenderingContextGTK::Init (this=0x834c2a0, aContext=0x8124088, aWindow=0x82c3120) at nsRenderingContextGTK.cpp:120 #1 0x40027bd6 in DeviceContextImpl::InitRenderingContext (this=0x8124088, aContext=0x834c2a0, aWin=0x82c3120) at nsDeviceContext.cpp:221 #2 0x40027a77 in DeviceContextImpl::CreateRenderingContext (this=0x8124088, aView=0x82c30b8, aContext=@0xbfffeb00) at nsDeviceContext.cpp:188 #3 0x40b428e3 in nsDeviceContextGTK::CreateRenderingContext (this=0x8124088, aView=0x82c30b8, aContext=@0xbfffeb00) at nsDeviceContextGTK.h:45 #4 0x40f2910a in PresShell::CreateRenderingContext (this=0x827c478, aFrame=0x82843a0, aResult=0xbfffecd4) at nsPresShell.cpp:2044 #5 0x40f267ec in PresShell::InitialReflow (this=0x827c478, aWidth=6120, aHeight=4335) at nsPresShell.cpp:1126 #6 0x40a8e81d in nsXULDocument::StartLayout (this=0x8358cf0) at nsXULDocument.cpp:3474 #7 0x40a95471 in nsXULDocument::ResumeWalk (this=0x8358cf0) at nsXULDocument.cpp:4791 #8 0x40a9a46c in nsXULDocument::CachedChromeStreamListener::OnStopRequest (this=0x8355d18, aChannel=0x8355228, aContext=0x0, aStatus=0, aErrorMsg=0x0) at nsXULDocument.cpp:5681 #9 0x40c827ce in nsDocumentOpenInfo::OnStopRequest (this=0x83551e8, aChannel=0x8355228, aCtxt=0x0, aStatus=0, errorMsg=0x0) at nsURILoader.cpp:243 #10 0x40b24eba in nsCachedChromeChannel::Notify (this=0x8355228, aTimer=0x82941d8) at nsChromeProtocolHandler.cpp:287 #11 0x4070a127 in nsTimerGtk::FireTimeout (this=0x82941d8) at nsTimerGtk.cpp:38 #12 0x4070a516 in nsTimerExpired (aCallData=0x82941d8) at nsTimerGtk.cpp:154 #13 0x408708a4 in g_timeout_dispatch () #14 0x4086fa86 in g_main_dispatch () #15 0x40870041 in g_main_iterate () #16 0x408701e1 in g_main_run () #17 0x407997a9 in gtk_main () #18 0x406b99c7 in nsAppShell::Run (this=0x8099740) at nsAppShell.cpp:304 #19 0x4058f07d in ?? () from /builds/seth/seamonkey/mozilla/dist/bin/libnsappshell.so #20 0x40afe4f3 in nsProfile::LoadDefaultProfileDir (this=0x812ab68, profileURLStr=@0xbffff7ec) at nsProfile.cpp:297 #21 0x40afe07e in nsProfile::StartupWithArgs (this=0x812ab68, cmdLineArgs=0x8077ae8) at nsProfile.cpp:215 #22 0x804bad2 in main1 (argc=2, argv=0xbffff9b4) at nsAppRunner.cpp:564 #23 0x804c3c7 in main (argc=2, argv=0xbffff9b4) at nsAppRunner.cpp:709 #24 0x402ddcb3 in ?? () from /lib/libc.so.6 adding blizzard and pavlov to the cc list. I have a patch to prevent the crash, and properly propogate the nsresult. if I check it in, the new behaviour will be a blank window, instead of a crash. I'll get it reviewed by troy. racham, I think this is now a bug for pavlov or blizzard.

my patch is in, and now you'll see a blank window, instead of a crash.

ok...I am ressigning the bug to pavlov. The patch is in the routine authored by pavlov. (#0 nsRenderingContextGTK::Init (this=0x834c2a0, aContext=0x8124088, aWindow=0x82c3120) at nsRenderingContextGTK.cpp:120).

agreed, blank window comes up now after create new/rename or delete in profile manager. I have to ctrl-c out and restart to use a new/renamed profile

Changing the component to widgets.

heads up, this bug is going to become invalid once ben and I land his changes. with his new set of changs, he's re-worked this and this bug doesn't happen. it would still be worth fixing, as it will probably resurface somewhere else. we are landing tonight. so to fix this, you'd have to have a tree from today.

good news, ben goodger's recent checkins have made this bug go away. bad news, it was a valid bug, and unless you use a tree from before Wed Jan 12 20:53:47 PST 2000, I don't know how to reproduce it. for now, I'm going to mark this invalid, and if the blank window bug (which is what this bug is) comes back, we can reopen.

build 2000011313