301073 - chrome home pages broken (cannot startup successfully if homepage is set to a chrome:// url)

Status: VERIFIED FIXED

(Toolkit :: Startup and Profile System, defect)

Description

[ownwomon]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Vanilla FF 1.0.4 supports home page of
chrome://browser/content/bookmarks/bookmarksPanel.xul.  
Vanilla 1.0.5 cannot startup successfully.

Note: If the 1.0.5 home page consists of more than one location where the
1st location is a non-xul url (i.e. www.google.com), then vanilla 1.0.5 can
initialize successfully.  Vanilla 1.0.5 can also when the home page is
a non-xul url (i.e. www.google.com) followed by 
chrome://browser/content/bookmarks/bookmarksPanel.xul.  

I reverted to 1.0.4 successfully. Just want to make sure that vanilla 1.0.6 does
not drop this functionality as well.

Reproducible: Always

Steps to Reproduce:
1.Steps found in Detail section.
2.
3.

Actual Results:  
Results found in Detail section.

Expected Results:  
See Detail section.

Comment 1

[Ria Klaassen (not reading all bugmail)]

It works for me in the current trunk builds.
http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/pacifica-trunk/

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050716
Firefox/1.0+ ID:2005071623

Comment 2

[ownwomon]

Thought I'd give 1.0.6 a test drive in regards to this bug.  Just downloaded 
and installed
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2005-07-16-05-aviary1.0.1/firefox-1.0.6.en-US.win32.installer.exe.

Vanilla FF 1.0.6 fails like 1.0.5.  

Comment 3

[ownwomon]

True,vanilla Deer Park Alpha 2 from
http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/pacifica-trunk/
does not exhibit this bug.  So that's hopeful for the future.
Now, if only the supported general user 1.0.5 (not as important if a stable 1.0.6
is available soon) could get fixed.  I'm even game to test the 1.0.6 (as noted
below) if the 1.0.6 bug would be resolved.

Comment 4

[Brendan Eich [:brendan]]

Gavin said he may patch this; giving it to mconnor for now since he reviewed the
patch for bug 298255 (which Gavin identified quickly on IRC as the regressor)
and may have some thoughts.  Cc'ing dveditz as well.

/be

Comment 5

[:Gavin Sharp [email: [e-mail]]]

I have a trunk patch that prevents loading chrome:// from the command line,
which is the only issue here, right? I'll test a little further anyways. The
branch equivalent however is somewhat more difficult, given that the command
line code there is a mess.

Comment 6

[Mike Connor [:mconnor]]

Opening chrome in the browser context is dangerous, especially on first startup.
 Allowing this behaviour is opening the door to exploits like bug 298255.  I
really don't think we want to fix this, because the alternative seems more bogus.

dveditz wants to strip chrome privs for chrome URLs opened in the browser, but
that hasn't happened yet.  When it does, this will break anyway.

Comment 7

[ownwomon]

Fyi: The intent is to have bookmarks panel,bookmarks manager in a tab.  This is
to replace funtionality I lost when I converted from Opera (CTRL-ALT-B) to
Firefox.  

Comment 8

[Adam Guthrie]

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

Comment 9

[:Gavin Sharp [email: [e-mail]]]

Attachment: Patch

Prevent loading chrome at startup at the command line, instead of on window
load. Also fixes bug 305372.

Comment 10

[:Gavin Sharp [email: [e-mail]]]

Trunk:

Checking in base/content/browser.js;
/cvsroot/mozilla/browser/base/content/browser.js,v  <--  browser.js
new revision: 1.495; previous revision: 1.494
done
Checking in components/nsBrowserContentHandler.js;
/cvsroot/mozilla/browser/components/nsBrowserContentHandler.js,v  <-- 
nsBrowserContentHandler.js
new revision: 1.16; previous revision: 1.15
done

Comment 11

[Brendan Eich [:brendan]]

I think we should unregress 1.5 (and probably 1.0.7) in this way.  The claim
that users who know how to set chrome as their start page need protection by our
disabling that capability is weak if we fix other bugs, and seems to disrespect
such users' judgment, and our commitments to compatibility where such promises
can be reasonably kept.

/be

Comment 12

[Brendan Eich [:brendan]]

Comment on attachment 193660 [details] [diff] [review]
Patch

Looking for another driver or two to agree.

/be

Comment 13

[Asa Dotzler [:asa]]

after this is verified on the trunk, we'll consider for branch approval.

Comment 14

[[e-mail]]

Attachment: xpfe version (checked in)

Comment 15

[Tracy Walker [:tracy]]

Verified with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1)
Gecko/20050902 Firefox/1.6a1

Comment 16

[Asa Dotzler [:asa]]

Comment on attachment 193660 [details] [diff] [review]
Patch

Let's get this landed on the branch ASAP. Thanks!

Comment 17

[:Gavin Sharp [email: [e-mail]]]

Checked in on the 1.8 Branch.
mozilla/browser/base/content/browser.js; new revision: 1.479.2.22;
mozilla/browser/components/nsBrowserContentHandler.js; new revision: 1.12.2.4;

Comment 18

[Tracy Walker [:tracy]]

verified on Firefox 1.4 -mozilla1.8 branch- Win, Lin and Mac : 2005-09-07

Comment 19

[Daniel C]

Do we still need the review requests here?

Comment 20

[Adam Guthrie]

(In reply to comment #19)
> Do we still need the review requests here?

Yes, the xpfe version still needs to be reviewed by xpfe people.

Comment 21

[Daniel Veditz [:dveditz]]

Comment on attachment 194651 [details] [diff] [review]
xpfe version (checked in)

sr=dveditz

Comment 22

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Comment on attachment 194651 [details] [diff] [review]
xpfe version (checked in)

First a=me

Comment 23

[Ian Neal]

Comment on attachment 194651 [details] [diff] [review]
xpfe version (checked in)

a=me for SM1.0b on SM only part of code, 2nd needed one - onwards and upwards!

Comment 24

[[e-mail]]

SeaMonkey-only portion of patch checked in to the 1.8 branch.