Closed Bug 26959 Opened 25 years ago Closed 25 years ago

Start page is about:blank

Categories

(SeaMonkey :: General, defect, P1)

Product:
SeaMonkey
Component:
General
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: jud, Assigned: sspitzer)

References

Details

(Keywords: regression, Whiteboard: [PDT+])

Attachments

(1 file)

patch for js exceptions
1.35 KB, patch
Details | Diff | Splinter Review 
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.
Keywords: regression
t
Assignee: nobody → travis
Ugh.
Keywords: beta1
Priority: P3 → P1
Target Milestone: M14
Assignee: travis → mscott
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.

Fixed.
Status: NEW → RESOLVED
Closed: 25 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.
Whiteboard: [PDT+]
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.
Blocks: 26958
*** 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
fixed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
*** Bug 27082 has been marked as a duplicate of this bug. ***
Keywords: verifyme
Adding verifyme keyword.
Status: RESOLVED → VERIFIED
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.
Keywords: verifyme
removing verifyme keyword
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: