26959 - Start page is about:blank

Status: VERIFIED FIXED

(SeaMonkey :: General, defect, P1)

Description

[Judson Valeski]

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.

Comment 1

[Christine Begle]

*** Bug 26971 has been marked as a duplicate of this bug. ***

Comment 2

[Sean Richardson]

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. 

Comment 3

[Judson Valeski]

t

Comment 4

[don]

Ugh.

Comment 5

[Scott MacGregor]

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.

Comment 6

[Scott MacGregor]

Fixed.

Comment 7

[shrirang khanzode]

Reopening. See this on today's linux commercial build 2000020908m14.

Comment 8

[shrirang khanzode]

Problem fixed on windows build 2000020908.

Comment 9

[Paul MacQuiddy]

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.

Comment 10

[leger]

Putting on PDT+ radar for beta1.

Comment 11

[shrirang khanzode]

I don't see this today. The default home page is being launched at startup.

Comment 12

[Judson Valeski]

not on my home build on nt

Comment 13

[scottputterman]

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)

Comment 14

[scottputterman]

Attachment: patch for js exceptions

Comment 15

[David Härdeman]

I believe this worked on yesterdays Linux build (sorry, can't remember which
build ID) but stopped working today (on build #2000021309).

Comment 16

[Andreas Otte]

I have not seen this working on linux for at least the last two or three days.

Comment 17

[Scott MacGregor]

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.

Comment 18

[Scott MacGregor]

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?

Comment 19

[travis]

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.

Comment 20

[Cyril Bortolato]

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?

Comment 21

[scottputterman]

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.

Comment 22

[cbegle]

*** Bug 27917 has been marked as a duplicate of this bug. ***

Comment 23

[(not reading, please use [e-mail] instead)]

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.

Comment 24

[travis]

Also note/ remember to remove the Ensure1Window.

Comment 25

[(not reading, please use [e-mail] instead)]

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.

Comment 26

[(not reading, please use [e-mail] instead)]

fixed.

Comment 27

[(not reading, please use [e-mail] instead)]

*** Bug 27082 has been marked as a duplicate of this bug. ***

Comment 28

[leger]

Adding verifyme keyword.

Comment 29

[Dan Erikson]

verified on a linux cvs build 2000-02-17

Comment 30

[Sean Richardson]

Verified on WinNT with 2000-02-17-08-M14 nightly binary, for both initial
and subsequent broser windows, and for mozilla -mail.

Comment 31

[Andrew Niese]

removing verifyme keyword