Closed
Bug 141035
Opened 22 years ago
Closed 22 years ago
cfg activation doesn't fail to launch browser if cfg is NOT present
Categories
(Core :: Preferences: Backend, defect)
Core
Preferences: Backend
Tracking
()
VERIFIED
FIXED
People
(Reporter: rvelasco, Assigned: bnesse)
References
Details
(Keywords: regression, Whiteboard: [ADT2 RTM],custrtm+)
Attachments
(3 files, 1 obsolete file)
19.95 KB,
patch
|
samir_bugzilla
:
review+
alecf
:
superreview+
|
Details | Diff | Splinter Review |
2.50 KB,
patch
|
alecf
:
review+
dveditz
:
superreview+
|
Details | Diff | Splinter Review |
3.96 KB,
patch
|
alecf
:
review+
beard
:
superreview+
|
Details | Diff | Splinter Review |
In the Mozilla 0.9.4 (Netscape 6.2.1/6.2.2) timeframe we failed somewhat "ungracefully" when we applied the CFG activation lines... 'pref("general.config.filename", "mozilla.cfg");' 'pref("general.config.vendor", "mozilla");' to the all.js or all-ns.js and did not have a CFG present in the local install directory. This was a check made by chip clark on bug 5132 during the initial implementation of CFG activation with the mozilla browser. Steps to reproduce: 1. Download latest trunk/branch build (i.e. 2002-04-29). 2. Edit the MOZILLA_INSTALL_DIR/defaults/pref/all.js (all-ns.js for netscape) and add the following lines to the file pref("general.config.filename", "mozilla.cfg"); pref("general.config.vendor", "mozilla"); 3. Start browser (we are testing for the failure case so no need to have a CFG present in the MOZILLA_INSTALL_DIR) Expected result: Browser should FAIL to launch since we activated the CFG in all*.js file. This is to prevent end users from deleting a CFG and using an uncustomized browser. Actual result: Browser starts normally as if no CFG activation lines are present. Last known build that worked was 200112220 builds. This could be a regression caused by bug 89137
Reporter | ||
Updated•22 years ago
|
QA Contact: sairuh → rvelasco
Updated•22 years ago
|
Keywords: regression
Assignee | ||
Comment 2•22 years ago
|
||
There has been a lot of offline discussion regarding this bug. To summarize... The application used to quit when this condition occurred because, as a part of the preferences service initialization, this caused the preferences service to throw an error in its Init() method. The failure of the preferences service to startup propagated back up the calling chain, causing the application to quit. Moving the autoconfig code out to a seperate module has pushed this check, and the subsequent failure, off onto a parallel task... one which does not affect the startup of the browser. Subsequent investigation has shown that through the nsAppShellService there appears to be a method which can be used to force the application to quit. The problem with this is that if the quit message is processed before the application enters the Run() loop it is effectively lost. I am still working to find a workaround for this limitation.
OS: Windows 2000 → All
Hardware: PC → All
Assignee | ||
Comment 3•22 years ago
|
||
Here's a rough patch that causes mozilla to bring up an alert and quit. I'm sure there are things that could be done better.
Updated•22 years ago
|
Whiteboard: [ADT3 RTM],custrtm → [ADT3 RTM],custrtm+
Assignee | ||
Comment 4•22 years ago
|
||
Here's a patch that is much better. The integration is a bit cleaner, and it pulls the error text from localizable resources.
Assignee | ||
Updated•22 years ago
|
Attachment #85831 -
Attachment is obsolete: true
Assignee | ||
Comment 5•22 years ago
|
||
Adding Conrad and Samir for reviews. Conrad, could you review the AppShell changes? Samir, can you review the UI changes? Alec, sr? This is an RTM blocker... time is of the essence. Thanks.
Status: NEW → ASSIGNED
Comment on attachment 86705 [details] [diff] [review] Proposed patch >Index: mozilla/extensions/pref/autoconfig/resources/content/contents.rdf >=================================================================== >RCS file: resources/content/contents.rdf >diff -N resources/content/contents.rdf >--- /dev/null 1 Jan 1970 00:00:00 -0000 >+++ mozilla/extensions/pref/autoconfig/resources/content/contents.rdf 6 Jun 2002 19:43:39 -0000 >@@ -0,0 +1,18 @@ >+<?xml version="1.0"?> >+<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#" >+ xmlns:chrome="http://www.mozilla.org/rdf/chrome#"> >+ >+ <!-- list all the packages being supplied --> >+ <RDF:Seq about="urn:mozilla:package:root"> >+ <RDF:li resource="urn:mozilla:package:autoconfig"/> >+ </RDF:Seq> >+ >+ <!-- package information --> >+ <RDF:Description about="urn:mozilla:package:autoconfig" >+ chrome:displayName="AutoConfig" >+ chrome:author="mozilla.org" >+ chrome:name="autoconfig" >+ chrome:localeVersion="1.0.0"> The trunk is "1.0.0". now. But, the branch is "1.0.0final" now. You might want to change the version # before landing it into branch. >+ </RDF:Description> >+ >+</RDF:RDF> > >Index: mozilla/extensions/pref/autoconfig/resources/locale/en-US/contents.rdf >=================================================================== >RCS file: resources/locale/en-US/contents.rdf >diff -N resources/locale/en-US/contents.rdf >--- /dev/null 1 Jan 1970 00:00:00 -0000 >+++ mozilla/extensions/pref/autoconfig/resources/locale/en-US/contents.rdf 6 Jun 2002 19:43:39 -0000 >@@ -0,0 +1,23 @@ >+<?xml version="1.0"?> >+<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#" >+ xmlns:chrome="http://www.mozilla.org/rdf/chrome#"> >+ >+ <!-- list all the locales being supplied --> >+ <RDF:Seq about="urn:mozilla:locale:root"> >+ <RDF:li resource="urn:mozilla:locale:en-US"/> >+ </RDF:Seq> >+ >+ <!-- locale information --> >+ <RDF:Description about="urn:mozilla:locale:en-US"> >+ <chrome:packages> >+ <RDF:Seq about="urn:mozilla:locale:en-US:packages"> >+ <RDF:li resource="urn:mozilla:locale:en-US:autoconfig"/> >+ </RDF:Seq> >+ </chrome:packages> >+ </RDF:Description> >+ >+ <!-- Version Information. State that we work only with major version of this >+ package. --> >+ <RDF:Description about="urn:mozilla:locale:en-US:autoconfig" >+ chrome:localeVersion="1.0.0"/> Comments above applies here. >+</RDF:RDF> >
Comment 7•22 years ago
|
||
r=ccarlen on the appshell changes.
Comment 8•22 years ago
|
||
Comment on attachment 86705 [details] [diff] [review] Proposed patch r=sgehani on build/installer changes required for chrome registration.
Attachment #86705 -
Flags: review+
Comment 9•22 years ago
|
||
Comment on attachment 86705 [details] [diff] [review] Proposed patch sr=alecf
Attachment #86705 -
Flags: superreview+
Assignee | ||
Comment 11•22 years ago
|
||
Checked in on the trunk.
Comment 12•22 years ago
|
||
Can I ask a dumb question. Isn't the .cfg issue moot? On 4.x you had to have a netscape.cfg or the browser wouldn't start. It got laid down by default by Netscape. A vendor could add locked prefs in it. With Mozilla, all someone would have to do is remove the two lines from the text based js file and the browser would come up without the .cfg file. This essentially makes the concept of the .cfg file (locked preferences) useless since anyone with an editor can turn it off...
Updated•22 years ago
|
Whiteboard: [ADT3 RTM],custrtm+ → [ADT2 RTM],custrtm+
Assignee | ||
Comment 14•22 years ago
|
||
Michael, while it is true that a knowledgeable person can disable the reading of the .cfg file, I don't believe that the point is entirely moot. For one thing, the .cfg file can be used for many things besides just locking preferences. For instance, bug 121332 (blocked by this) is about accessing LDAP attributes. The testcase attached to that bug sets the users homepage to a value pulled from the the user's entry on an LDAP server. In practice a vendor would probably also store info in the .cfg file that was necessary for the user to use the browser in their corporate environment. While the user could force the program to launch, they would effectively be left with a useless application.
Assignee | ||
Comment 15•22 years ago
|
||
Rodney has discovered that this doesn't work in a packaged build. I tracked it down to a missing file (platform.js) which is not being copied over from the viewer:defaults:autoconfig directory. This was apparently missed on a checkin for bug 132140. The attached patch insures that all files in this directory are grabbed in the packaging phase.
Assignee | ||
Comment 16•22 years ago
|
||
Rodney has also found that the error dialog is not appearing in the commercial build. This appears to be a regchrome issue. The bits are in the chrome packages, but are not being registered properly... still investigating.
Comment 17•22 years ago
|
||
Comment on attachment 87719 [details] [diff] [review] Mozilla packaging fix sr=dveditz
Attachment #87719 -
Flags: superreview+
Comment 18•22 years ago
|
||
Comment on attachment 87719 [details] [diff] [review] Mozilla packaging fix r=alecf
Attachment #87719 -
Flags: review+
Assignee | ||
Comment 19•22 years ago
|
||
Patch to fix commercial chrome registration. Thanks to Dan for explaining to me that chrome registration is unique, and does not take from Mozilla.
Comment 20•22 years ago
|
||
Comment on attachment 87728 [details] [diff] [review] Commercial patch sr=beard (rs)
Attachment #87728 -
Flags: superreview+
Reporter | ||
Comment 21•22 years ago
|
||
Dropping the platform.js in the defaults/autoconfig directory fixed the problem on all platforms (mac OS 9.2.2, macOSX.1.5, win32, and Linux2.4-16) as far as starting up the browser with the activation lines and CFG present in the install directory (essential files for mac). This was tested on todays commercial trunk builds. I'll try applying the patch for the error dialog/chrome registration issue I reported to brian (see patch 87728) on windows and linux. I'll post my findings once that build completes.
Comment 22•22 years ago
|
||
Comment on attachment 87728 [details] [diff] [review] Commercial patch sr=alecf
Attachment #87728 -
Flags: review+
Assignee | ||
Comment 23•22 years ago
|
||
Both patches checked in.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 24•22 years ago
|
||
New changes works on all supported platforms. Able to see failure dialog for all using todays trunk builds, as well as startup with a valid CFG. Verified on commercial trunk Mac OS X (2002061708) Linux 2.4.7-10 (2002061708) Windows XP (2002061708)
Status: RESOLVED → VERIFIED
Comment 25•22 years ago
|
||
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+" keyword and add the "fixed1.0.1" keyword.
Keywords: mozilla1.0.1 → mozilla1.0.1+
Comment 26•22 years ago
|
||
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+" keyword and add the "fixed1.0.1" keyword.
Assignee | ||
Comment 27•22 years ago
|
||
New files added to the 1.0 branch... awaiting the go ahead from Leaf to land the remainder and activate the code.
Reporter | ||
Comment 28•22 years ago
|
||
over to luke for verification on the branch once it lands. Luke, please add verified1.01 to the keyword once you have completed testing this.
QA Contact: rvelasco → lrg
Comment 29•22 years ago
|
||
Is this in branch already? if not, please check it in asap. thx!
Assignee | ||
Comment 30•22 years ago
|
||
As per comment #27, I am waiting for leaf to tell me that he has done whatever CVS magic is required for new branch files before I can add them to the build. I can not check in the remainder of the patch until this happens.
Comment 31•22 years ago
|
||
hi, leaf: would you please do the CVS magic Brian needs? :-)
Comment 32•22 years ago
|
||
actually, no magic needed doing. the files seemed to get added to the "right" tag MOZILLA_1_0_BRANCH, i'll put them on MOZILLA_1_0_0_BRANCH now, too.
Assignee | ||
Comment 33•22 years ago
|
||
Remainder of the files checked in to the 1.0 branch.
Keywords: mozilla1.0.1+ → fixed1.0.1
Comment 34•22 years ago
|
||
I verified this bug on Windows 2000, Linux2.2 and MacOSX using todays (06/24) branch Build, updating to verified1.0.1
Keywords: fixed1.0.1 → verified1.0.1
You need to log in
before you can comment on or make changes to this bug.
Description
•