Start page is about:blank

VERIFIED FIXED in M14

Status

P1
normal
VERIFIED FIXED
19 years ago
14 years ago

People

(Reporter: jud, Assigned: sspitzer)

Tracking

({regression})

Trunk
x86
Linux
regression

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+])

Attachments

(1 attachment)

(Reporter)

Description

19 years ago
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

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

Comment 2

19 years ago
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
(Reporter)

Comment 3

19 years ago
t
Assignee: nobody → travis

Comment 4

19 years ago
Ugh.
Keywords: beta1
Priority: P3 → P1
Target Milestone: M14

Updated

19 years ago
Assignee: travis → mscott

Comment 5

19 years ago
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

19 years ago
Fixed.
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 7

19 years ago
Reopening. See this on today's linux commercial build 2000020908m14.
Status: RESOLVED → REOPENED
OS: Windows NT → Linux
Resolution: FIXED → ---

Comment 8

19 years ago
Problem fixed on windows build 2000020908.

Comment 9

19 years ago
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

19 years ago
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]

Comment 11

19 years ago
I don't see this today. The default home page is being launched at startup.
(Reporter)

Comment 12

19 years ago
not on my home build on nt

Comment 13

19 years ago
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

19 years ago
Created attachment 5147 [details] [diff] [review]
patch for js exceptions

Comment 15

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

Comment 16

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

Comment 17

19 years ago
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

Comment 18

19 years ago
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

19 years ago
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

19 years ago
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

19 years ago
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.

Updated

19 years ago
Blocks: 26958

Comment 22

19 years ago
*** 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

Comment 24

19 years ago
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
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED
*** Bug 27082 has been marked as a duplicate of this bug. ***

Updated

19 years ago
Keywords: verifyme

Comment 28

19 years ago
Adding verifyme keyword.

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 29

19 years ago
verified on a linux cvs build 2000-02-17

Comment 30

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

Updated

19 years ago
Keywords: verifyme

Comment 31

19 years ago
removing verifyme keyword
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.