Closed Bug 12687 Opened 25 years ago Closed 25 years ago

sched: need component specific chrome registry support


(Core :: XUL, defect, P3)






(Reporter: cathleennscp, Assigned: hyatt)



for tracking...  :-)
Cathleen felt the need to stay on top of this since the current chrome registry
will greatly complicate life for any "after market" component installs (AIM,
for example).

Based on a mtg between hyatt, waterson and me it sounds like a reasonable
solution is at hand and simply needs to be implemented. At that point
installing a new component will be a simple matter of including an extra
registry fragment that the chrome system will aggregate at startup. Details to
be worked out and posted by hyatt.
Summary: [feature]need component specific chrome registry support → sched: need component specific chrome registry support
Target Milestone: M14
moving to m14
Severity: normal → blocker
Peter, we need this feature support for beta, otherwise, we won't be able to
update chrome registry to reflect new component that gets installed afterwards.

possible new components: mail/news, aim

changing severity to blocker.
For Netscape components we can just ship with an "all components" chrome
registry. If those components aren't present no one will be referring to their
chrome URLs. We could then add the actual binaries/chrome later.

This would only work for Netscape components we know about ahead of time. 3rd
party folks will not be able to install additional components without telling
people to hand-edit the chrome registry after the install. I think we can live
with that.

I'm assuming that it's OK to have the chrome registry refer to an overlay that
isn't actually present, because this is how AIM is implemented. Otherwise we're
screwed and we really do need to fix this by beta (or not allow components with
overlays to be optional).
I don't get it.  Can't we just force an uninstall of beta 1 when beta 2 comes
You're asking about my XUL overlay comment, right? I think you agree that
installing unknown 3rd party components with chrome will require hand-editing
the chrome registry in its current form. But we can live with that because
there are no 3rd party components (that we care about, at least) in the Beta
time frame.

So the issue is, someone installs the beta and chooses the "minimum" option: no
AIM, no mailnews, etc, just the browser.  Because the installer can't add to
the chrome registry later the default chrome registry includes all possible
stuff we'd ever want in there, including the XUL overlay notation for AIM even
though AIM (including its chrome) isn't installed.

Does this break the build?

If so and there's no way to do chrome registry fragments by beta maybe this
means we have to ship fully bundled. At least some of the managers would
consider that better than missing the date, but we need to know so we can plan
Ok.  We need to get a manager to make a call on this one I think.  It's a
question of the upgrade path from beta 1 to beta 2 (as well as a question of
just what we're going to ship in beta 1).
For beta 1, we do offer users to install Navigator only, and users have the
option to add mail/news, editor, aim and other components seperately, later on.

If we can have the main chrome registry file include all Netscape components
that possibly might not exist, so we can install those components later and have
them reflected correctly, then I can live with not having this support in first
beta.  Can we do that?  Is it possible?

If not, then component install would not work correctly, and we're possibly
I thought we pointy-hairs agreed yesterday that we would have 2 install options:
1) Navigator only
2) Everything.
no, that wasn't the case...  we have more than just those two options, but
that's different.

there will be components that don't get installed the first time, like
mail/news, aim..., if you choose to install nav only.  So, those components can
be installed through smartupdate, which means our notification will notify
people to install, but they won't work correct...
Turns out mailnews and aim both use explicit XUL overlays, and no one is using
overlays specified from the chrome registry. We can ship a single kitchen-sink
registry with the browser and the correct entries will already be there when
required by additional (known) Netscape components. 3rd party components will
require hand-tweaking of the chrome registry in beta, or perhaps could provide
a bookmarked file URL to kick off their feature. Upshot: we can put this bug
off until after beta.

We *will* still have to solve the problem when trying to load an overlay that
doesn't exist. If you find the bug that describes that you can reassign it to
me since it'll be a blocker for the install.
Why would we need to have so many possible permutations for install of a
pre-alpha preview release? I was sure I heard marketing say that two options
were enough.
Never mind, since dveditz says we can push it off, we will.
Blocks: 15681
Blocks: 18951
Blocks: 20203
Closed: 25 years ago
Resolution: --- → FIXED
This has been fixed.   Dynamic overlays are in and working.
QA Contact: phillip → paulmac
marking verified
No longer blocks: 18951
No longer blocks: 20203
You need to log in before you can comment on or make changes to this bug.