because of http://bugzilla.mozilla.org/show_bug.cgi?id=26958 you can't tell, but we never try to load the start page specified in the prefs file. the webshell tries to load "about:blank" instead.
*** Bug 26971 has been marked as a duplicate of this bug. ***
Marking as regression; this was working in 2000-02-07-08 and every known build beforehand on WinNT, but not in 2000-02-08-08.
Assignee: nobody → travis
Priority: P3 → P1
Target Milestone: M14
I checked in the fix for this. You either need to delete your components.reg file and re run OR you need my fix. The category manager was returning an error in the init method for the http handler which it was passing back to the caller. As a result we never created a http protocol handler. DP is looking into why the category manager was throwing an error.
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
Reopening. See this on today's linux commercial build 2000020908m14.
Status: RESOLVED → REOPENED
OS: Windows NT → Linux
Resolution: FIXED → ---
Problem fixed on windows build 2000020908.
I see the problem also on linux 20908. Clean build, clean profile, even wiping out the component.reg that is pre-packaged with the release build.
Putting on PDT+ radar for beta1.
I don't see this today. The default home page is being launched at startup.
not on my home build on nt
I have some info on this bug but I'm not sure what to do about it. First, there are a bunch of js exceptions when starting up navigator. The attached patch fixes these. The main problem comes about because nsBrowserInstance::LoadInitialPage is always returning early because the line mWebShellWin->ShouldLoadDefaultPage(&loadDefault); is always returning loadDefault as false. this is due to the fact that nsXULWindow::CreateNewChromeWindow is passing in PR_FALSE to appShell->CreateTopLevelWindow(..) for the loadDefaultParameter. If this were PR_TRUE it might work (I haven't tried it out yet)
I believe this worked on yesterdays Linux build (sorry, can't remember which build ID) but stopped working today (on build #2000021309).
I have not seen this working on linux for at least the last two or three days.
If nsXULWindow::CreateNewChromeWindow is passing the wrong flag in for Load InitialPage then that sounds like something for travis. Although it's strange that this problems happens intermittenly and not on all platforms. I wonder if we are passing a piece of unitialized memory in as the boolean for InitialPage.
Assignee: mscott → travis
Status: REOPENED → NEW
Travis, I have a fix for this in my tree pending a review from you if you want me to take this back. Putterman's analysis is basically right on the money. nsXULWindow::CreateNewChromeWindow always sets aLoadDefaultPage to false. So we never load a default page. By changing this true, life became very good again. Can I check this in?
I'd like to look at it in some detail. The call in CreateContentWindow was never taking true. My guess is you have fixed the initial browser case, but popups are now loading the homepage first and then the requested popup page.
I noticed that by launching mozilla with -splash on 2000-02-13-09 and 2000-02-14-16 on Linux, the start page gets loaded. Strange, isn't it?
I'm seeing something similar to the -splash comment made above. In today's build if I do "mozilla -mail", instead of starting mail, I get the browser with my home page. If I just do mozilla I get about:blank.
*** Bug 27917 has been marked as a duplicate of this bug. ***
I'm the choad who broke this, when I landed my nsICmdLineHandler changes. travis, mscott and I talked about how to fix it, and I'm going to work on it.
Assignee: travis → sspitzer
Also note/ remember to remove the Ensure1Window.
yes, I've cleaned up Ensure1Window. mscott as reviewed, and I'll be checking in soon. the logic for "what page do I load in a new browser window?" got moved into nsBrowserInstance.cpp, and so I removed the logic from navigator.js, tasksOverlay.js and editorOverlay.js to get it from there (using xpconnect) so things are much better now.
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago → 19 years ago
Resolution: --- → FIXED
*** Bug 27082 has been marked as a duplicate of this bug. ***
Adding verifyme keyword.
verified on a linux cvs build 2000-02-17
Verified on WinNT with 2000-02-17-08-M14 nightly binary, for both initial and subsequent broser windows, and for mozilla -mail.
removing verifyme keyword
You need to log in before you can comment on or make changes to this bug.