cfg activation doesn't fail to launch browser if cfg is NOT present

VERIFIED FIXED

Status

()

VERIFIED FIXED
17 years ago
17 years ago

People

(Reporter: rvelasco, Assigned: bnesse)

Tracking

({regression})

Trunk
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ADT2 RTM],custrtm+)

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

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

17 years ago
QA Contact: sairuh → rvelasco

Comment 1

17 years ago
nominate for rtm
Blocks: 144547
Keywords: nsbeta1

Updated

17 years ago
Blocks: 143047
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [ADT3 RTM]

Updated

17 years ago
Keywords: regression
(Assignee)

Comment 2

17 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

Updated

17 years ago
Whiteboard: [ADT3 RTM] → [ADT3 RTM],custrtm
(Assignee)

Comment 3

17 years ago
Created attachment 85831 [details] [diff] [review]
Preliminary patch

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

17 years ago
Whiteboard: [ADT3 RTM],custrtm → [ADT3 RTM],custrtm+
(Assignee)

Comment 4

17 years ago
Created attachment 86705 [details] [diff] [review]
Proposed patch

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

17 years ago
Attachment #85831 - Attachment is obsolete: true
(Assignee)

Comment 5

17 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 6

17 years ago
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>
>
r=ccarlen on the appshell changes.

Comment 8

17 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+
(Assignee)

Updated

17 years ago
Blocks: 121332

Comment 9

17 years ago
Comment on attachment 86705 [details] [diff] [review]
Proposed patch

sr=alecf
Attachment #86705 - Flags: superreview+
(Assignee)

Comment 10

17 years ago
Adding keywords...
Keywords: adt1.0.1, mozilla1.0.1
(Assignee)

Comment 11

17 years ago
Checked in on the trunk.
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...

Comment 13

17 years ago
adt1.0.1+ per scott and syd's vote.
Keywords: adt1.0.1 → adt1.0.1+

Updated

17 years ago
Whiteboard: [ADT3 RTM],custrtm+ → [ADT2 RTM],custrtm+
(Assignee)

Comment 14

17 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

17 years ago
Created attachment 87719 [details] [diff] [review]
Mozilla packaging fix

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

17 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 on attachment 87719 [details] [diff] [review]
Mozilla packaging fix

sr=dveditz
Attachment #87719 - Flags: superreview+

Comment 18

17 years ago
Comment on attachment 87719 [details] [diff] [review]
Mozilla packaging fix

r=alecf
Attachment #87719 - Flags: review+
(Assignee)

Comment 19

17 years ago
Created attachment 87728 [details] [diff] [review]
Commercial patch

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

17 years ago
Comment on attachment 87728 [details] [diff] [review]
Commercial patch

sr=beard (rs)
Attachment #87728 - Flags: superreview+
(Reporter)

Comment 21

17 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

17 years ago
Comment on attachment 87728 [details] [diff] [review]
Commercial patch

sr=alecf
Attachment #87728 - Flags: review+
(Assignee)

Comment 23

17 years ago
Both patches checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
(Reporter)

Comment 24

17 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

17 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

17 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

17 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

17 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

17 years ago
Is this in branch already? if not, please check it in asap. thx!
(Assignee)

Comment 30

17 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

17 years ago
hi, leaf: would you please do the CVS magic Brian needs? :-)

Comment 32

17 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

17 years ago
Remainder of the files checked in to the 1.0 branch.
Keywords: mozilla1.0.1+ → fixed1.0.1

Comment 34

17 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.