130088 - Preferences not visible when upgrading from 6.0 or 6.01 to Trunk 3/07 or 3/11

Status: VERIFIED FIXED

(SeaMonkey :: Preferences, defect)

Description

[Grace Bush]

Steps to reproduce:
1. Install Netscape 6.0 (or 6.01) ( not tried 6.1 and up yet)
2. Install trunk build 2002031103
3. Go to preferences to turn on QuickLaunch

Actual results: preferences not visible

expected results: preferences visible to select and change

Comment 1

[Grace Bush]

this is not happening on 6.1 upgrades -

Comment 2

[Samir Gehani]

Any JS console errors that weren't there before opening the prefs dialog?  Is
this happening to any other prefs or is it specific to the QuickLaunch pref?

Comment 3

[Grace Bush]

nope, not a QuickLaunch bug- cannot get to prefs to turn it on.

Tried again with 3/18 build upgraded a 6.0 install
the following messages came up in the console

failed to load overlay chrome://messenger/content/mailActivationOVerlay.xul
warning add child failed!!

failed to load overlay chrome://communicator/content/pref/pref-IM_overlay.xul
Warning add child failed!!

(Activation failed to load today- intermittent problem)
(prefs display was empty)


am not seeing this on 6.1 and up  upgrades- only 6.0 and 6.01 - not sure how
many of these users we still have

Comment 4

[(not reading, please use [e-mail] instead)]

according to esther, help menu doesn't drop down and the mail address book
advanced search dropdowns don't work.

here's a theory:

the 6.0 install leaves some component or jar default pref file behind that 6.0+
(including 6.1 and 6.2) didn't remove.  (It didn't affect us, so it we probably
never noticed.)

Now, it affects us because mach v is different than earlier builds.

can someone compare the contents of the "Netscape 6" directory (with this
problem) to that of a pure "Netscape 7" directory, and see there are any files
in one, but not the other?

Comment 5

[Grace Bush]

Seth, I will attach two sets of diffs-
one is comparison of 60 full  setup type install to 70 full setup type install
the other compares 60upgraded to 70 with a 70 install (both full setup type)

Note in both there are lots of cvs files in the 60 installs which were 
subsequently removed that have no bearing.

I also have another tool that gives a better visual comparison but the results 
cannot be saved to a file

Comment 6

[Grace Bush]

Attachment: comparison of 60 install with 70 install

Comment 7

[Grace Bush]

Attachment: comparison of upgraded 60(to 70)install to 70 install

Comment 8

[scottputterman]

nominating for rtm. This needs to be fixed.

Comment 9

[Peter Trudelle]

nsbeta1+/ADT1 per Nav triage team.  Bill, should't this be assigned to ben?

Comment 10

[Bill Law]

Either Ben (as the Pref man), or to mailnews (the js console messages seem to 
be only about mailnews).  Seth, what do you think?  Is this something that will 
have to be fixed in prefs, mailnews, or somewhere else?

Comment 11

[Bill Law]

The "failed to load overlay" message comes from here:
http://lxr.mozilla.org/seamonkey/source/content/xul/document/src/nsXULDocument.c
pp#7021

As it happens, both mailActivationOverlay.xul and pref-IM_overlay.xul are in 
the Netscape commercial tree.  The former used to be under messenger/content 
and is now under messenger-ns/content.  The latter seems to have undergone a 
similar name change (more precisely, "chrome location" change).

The theory is that installing over a 6.0 installation leaves chrome registry 
residue that refers to the old names/locations.

The possible fixes seem to be:

1. Add an installer API feature to enable the removal of such stale chrome 
registry entries, plus, installer script directives that use this to remove the 
ones causing the problem.  This is probably too much work and too high risk.

2. Make the code that detects the error not fail so hard.  I.e., have it treat 
the missing overlay the same as an empty overlay.  Not sure how much work this 
wouild be or how risky.

3. Ship empty/dummy content located where the stale chrome registry entries are 
looking.  This seems relatively easy and low risk.

So who gets the bug?  Ben doesn't sound like a proper victim, since it's just 
coincidence that the problem appears in prefs.  I'm not a chrome registry guru 
so I don't really want it.  I talked to Peter and he suggested Joe Hewitt.  Joe 
knows this as well as anybody and can hopefully arrive at the proper fix.

Comment 12

[Blake Ross]

This is a problem dveditz and I faced recently with a wallet overlay...this
really needs to be dealt with somehow at the installer level, but agreed that
that's a lot of work at this point.  If I recall correctly, we just solved the
wallet problem with solution 3 (use a dummy file), didn't we?

Comment 13

[Blake Ross]

We will somehow need to figure out all of the files that have changed location
-- there must be more, if things like the help menu don't work (comment 4).

Is this *only* a problem when upgrading from 6.0 to current trunk?  It looks
like pref-IM_overlay.xul, for example, changed location way back in March 2001.
 This maens upgrading from 6.0 to 6.1 should be problematic, too.

Comment 14

[scottputterman]

When I watched Esther try this out, it looks like from 6.0 to 6.1 worked fine
but if you then installed 7.0 it broke. 

Comment 15

[Joe Hewitt (gone)]

We just need to delete everything in the /overlayinfo directory, which contains
the references to these now-defunct overlays.  chrome.rdf gets regenerated after
an install (due to the touched installed-chrome.txt), but the overlay stuff
doesn't, so we should clean it.  It just gets rebuilt anyway.

Installer has the ability to remove files - but I'm not sure if it can remove an
entire directory and its contents.

Comment 16

[Peter Trudelle]

Joe, did you need help on this, or mean to reassign it?

Comment 17

[Joe Hewitt (gone)]

Attachment: this oughta do it

This patch just puts the missing files back in the location they are expected
in.

Comment 18

[Jaime Rodriguez, Jr.]

dveditz/blake - is this something you can r= and/or sr=?

Comment 19

[Samir Gehani]

Comment on attachment 87743 [details] [diff] [review]
this oughta do it

r=sgehani

Comment 20

[Daniel Veditz [:dveditz]]

Comment on attachment 87743 [details] [diff] [review]
this oughta do it

>+  content/communicator/pref-IM_overlay.xul (pref/pref-IM_overlay.xul)
>   content/aim/pref-IM_overlay.xul          (pref/pref-IM_overlay.xul)

>+  content/messenger/mailActivationOverlay.xul
	(base/resources/content/mailActivationOverlay.xul)
>   content/messenger-ns/mailActivationOverlay.xul
	(base/resources/content/mailActivationOverlay.xul)

This seems a bit too clever, I'd be much happier with
zero-length dummy files as used in previous instances.
I suppose this works, but it bloats the chrome .jar and
means that people who suffer from this bug will now have
to parse these overlays twice, hurting performance and
probably adding to footprint (or do we throw away the
duplicate nodes?).

I'm also concerned about the implications in comment 4 that these
aren't the only ones. We need to compare the chrome/overlayinfo
files in the 6.0-upgraded case against a plain 7.0 install.

To be safe we should compare these files for 6.1 and 6.2 with 7.0
as well, just in case some overlay came and went in the meantime.

Comment 21

[Samir Gehani]

K'trina is working on diffing the chrome/overlayinfo directories of 6.{0,1,2}
upgraded to 7.0 vs. a pure 7.0 installation to address Dan's concern.

Comment 22

[kmurray1115]

I'm seeing this too, on all three of my machines (two Win2k, and one WinXP).
Nothing out of the ordinary in terms of upgrading, just installing daily builds
in the same directory for the last year or so.

Comment 23

[sairuh (rarely reading bugmail)]

spoke w/k'trina, and giving this over to her as she's actively looking into it.

Comment 24

[K'Trina Medina]

Attachment: 60-70-upgrade-vs-70-pure

Comment 25

[K'Trina Medina]

Attachment: 61-70-upgrade-vs-70-pure

Comment 26

[K'Trina Medina]

Attachment: 62-70-upgrade-vs-70-pure

Comment 27

[Jaime Rodriguez, Jr.]

what are the chances this is gonna be ready by wednesday, 06/27?

Comment 28

[Joe Hewitt (gone)]

Attachment: patch

This approach is pretty uncomplicated - I just use one file "dummyOverlay.xul"
which I copy into the appropriate places via the jar.mn.  Reviews?

Comment 29

[Daniel Veditz [:dveditz]]

Comment on attachment 89036 [details] [diff] [review]
patch

sr=dveditz

Comment 30

[Joe Hewitt (gone)]

Comment on attachment 89036 [details] [diff] [review]
patch

r=jag

Comment 31

[Joe Hewitt (gone)]

fixed checked into trunk

Comment 32

[Jaime Rodriguez, Jr.]

thanks joe!

ktrina - can you pls verify this on the trunk today, so we can take it on the
branch this evening? thanks!

Comment 33

[Jaime Rodriguez, Jr.]

resolving as fixed per Comment #31 From Joe Hewitt.

Comment 34

[K'Trina Medina]

I verified the code fix. 

hewitt, I also did new upgrade comparisons so I was wondering if you can check
it out before I mark it verified. I will attach the comparisons.

And I submitted bug 154243 because I received XPCOM errors on the upgrades from
6.0 to 7.0 trunk and 6.1 to 7.0 trunk. When I upgraded from 6.2 to 7.0 trunk I
received a dialog that prompted me to restart my machine.  

Comment 35

[K'Trina Medina]

Attachment: 60-70-upgrade-vs-70-trunk

Comment 36

[K'Trina Medina]

Attachment: 61-70-upgrade-vs-70-trunk

Comment 37

[K'Trina Medina]

Attachment: 62-70-upgrade-vs-70-trunk

Comment 38

[Joe Hewitt (gone)]

K'Trina, I'm trying to make use of your comparisons, but I think I need them
done a little differently.  Can you compare the overlays.rdf from a pure 6.0
install against a pure 7.0 install? That would give me the data I really need. 
Comparing a 6.0 with 7.0 installed over it doesn't really help.

Comment 39

[K'Trina Medina]

Attachment: 60-pure-vs-70-trunk-pure

hewitt, here is the comparison of 60 pure and 70 pure. Let me know if you need
6.1 and 6.2 comparisons as well.

Comment 40

[Daniel Veditz [:dveditz]]

Over in bug 140104 mscott is running into similar, but not as easily solved
problem because they don't want an existing overlay hooked into a spot it used
to be hooked. They can't just dummy it out because the same overlay is used in
another spot.

They're leaning toward the "zap the chrome registry on install" solution as well.

Comment 41

[scottputterman]

I'm not clear if we believe this is fixed.  Has this been verified on the trunk?
 We need to land this on the branch as soon as we can.

Comment 42

[Daniel Veditz [:dveditz]]

The fix for bug 140104 will resolve any remaining issues. Kind of obsoletes this
patch, actually. We can remove the dummy files from the trunk in the future.

Comment 43

[Grace Bush]

I am unable to verify this on trunk - I tried both full and recommended 6.0 
installs, upgraded to 628 trunk builds.
I get an 'event receiver' error - followed by a crash 
I will attach error message

Comment 44

[Grace Bush]

Attachment: Error message after upgrade from 6.0 to trunk (6/28) build

Comment 45

[Daniel Veditz [:dveditz]]

entry point error is something else, just means there's an old component left
over. Not a big deal on the trunk, we'll clean it up before the next milestone.
bug 154243

Comment 46

[scottputterman]

Did 140104 fix this on the branch?

Comment 47

[Grace Bush]

this is fixed on branch build 2002070108
will someone add the correct keywords and I will add verified1.0.1?

Comment 48

[scottputterman]

adding fixed1.0.1

Comment 49

[K'Trina Medina]

Verified. The fix for bug 140104 resolved remaining issues.