Closed
Bug 301073
Opened 19 years ago
Closed 19 years ago
chrome home pages broken (cannot startup successfully if homepage is set to a chrome:// url)
Categories
(Toolkit :: Startup and Profile System, defect)
Toolkit
Startup and Profile System
Tracking
()
VERIFIED
FIXED
mozilla1.8final
People
(Reporter: ownwomon, Assigned: Gavin)
References
Details
(Keywords: fixed-seamonkey1.0, regression, verified1.8)
Attachments
(2 files)
5.35 KB,
patch
|
mconnor
:
review+
asa
:
approval1.8b4+
|
Details | Diff | Splinter Review |
4.74 KB,
patch
|
dveditz
:
review+
dveditz
:
superreview+
|
Details | Diff | Splinter Review |
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•19 years ago
|
||
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
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.
Summary: Vanilla FF 1.0.4 supports home page of chrome://browser/content/bookmarks/bookmarksPanel.xul. Vanilla 1.0.5 cannot startup successfully. → Vanilla FF 1.0.4 supports home page of chrome://browser/content/bookmarks/bookmarksPanel.xul. Vanilla 1.0.5, 1.0.6 cannot startup successfully.
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.
Updated•19 years ago
|
Assignee: nobody → mconnor
Comment 4•19 years ago
|
||
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 5•19 years ago
|
||
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•19 years ago
|
||
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.
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•19 years ago
|
||
*** Bug 303878 has been marked as a duplicate of this bug. ***
Updated•19 years ago
|
Keywords: regression
Assignee | ||
Comment 9•19 years ago
|
||
Prevent loading chrome at startup at the command line, instead of on window
load. Also fixes bug 305372.
Assignee | ||
Updated•19 years ago
|
Updated•19 years ago
|
Attachment #193660 -
Flags: review?(mconnor) → review+
Assignee | ||
Comment 10•19 years ago
|
||
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
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Summary: Vanilla FF 1.0.4 supports home page of chrome://browser/content/bookmarks/bookmarksPanel.xul. Vanilla 1.0.5, 1.0.6 cannot startup successfully. → chrome home pages broken (cannot startup successfully if homepage is set to a chrome:// url)
Comment 11•19 years ago
|
||
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
Flags: blocking1.8b4+
Comment 12•19 years ago
|
||
Comment on attachment 193660 [details] [diff] [review]
Patch
Looking for another driver or two to agree.
/be
Attachment #193660 -
Flags: superreview?
Updated•19 years ago
|
Attachment #193660 -
Flags: approval1.8b4?
Comment 13•19 years ago
|
||
after this is verified on the trunk, we'll consider for branch approval.
Comment 14•19 years ago
|
||
Attachment #194651 -
Flags: superreview?(jag)
Attachment #194651 -
Flags: review?(jag)
Comment 15•19 years ago
|
||
Verified with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1)
Gecko/20050902 Firefox/1.6a1
Status: RESOLVED → VERIFIED
Comment 16•19 years ago
|
||
Comment on attachment 193660 [details] [diff] [review]
Patch
Let's get this landed on the branch ASAP. Thanks!
Attachment #193660 -
Flags: approval1.8b4? → approval1.8b4+
Assignee | ||
Comment 17•19 years ago
|
||
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;
Keywords: fixed1.8
Target Milestone: --- → Firefox1.5
Comment 18•19 years ago
|
||
verified on Firefox 1.4 -mozilla1.8 branch- Win, Lin and Mac : 2005-09-07
Keywords: fixed1.8 → verified1.8
Comment 19•19 years ago
|
||
Do we still need the review requests here?
Comment 20•19 years ago
|
||
(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.
Updated•19 years ago
|
Attachment #193660 -
Flags: superreview?
Comment 21•19 years ago
|
||
Comment on attachment 194651 [details] [diff] [review]
xpfe version (checked in)
sr=dveditz
Attachment #194651 -
Flags: superreview?(jag)
Attachment #194651 -
Flags: superreview+
Attachment #194651 -
Flags: review?(jag)
Attachment #194651 -
Flags: review+
Updated•19 years ago
|
Attachment #194651 -
Attachment description: xpfe version → xpfe version (checked in)
Comment on attachment 194651 [details] [diff] [review]
xpfe version (checked in)
First a=me
Comment 23•19 years ago
|
||
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•19 years ago
|
||
SeaMonkey-only portion of patch checked in to the 1.8 branch.
Whiteboard: fixed-seamonkey1.0
Updated•19 years ago
|
Keywords: fixed-seamonkey1.0
Whiteboard: fixed-seamonkey1.0
Updated•16 years ago
|
Product: Firefox → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•