Closed Bug 12687 Opened 25 years ago Closed 25 years ago

sched: need component specific chrome registry support

Categories

(Core :: XUL, defect, P3)

x86
Other
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: cathleennscp, Assigned: hyatt)

References

Details

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 out?
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 accordingly.
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 doomed...
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
Status: NEW → ASSIGNED
Blocks: 18951
Blocks: 20203
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
This has been fixed. Dynamic overlays are in and working.
Status: RESOLVED → VERIFIED
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.