12687 - sched: need component specific chrome registry support

Status: VERIFIED FIXED

(Core :: XUL, defect, P3)

Description

[Cathleen]

for tracking...  :-)

Comment 1

[Daniel Veditz [:dveditz]]

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.

Comment 2

[Peter Trudelle]

moving to m14

Comment 3

[Cathleen]

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.

Comment 4

[Daniel Veditz [:dveditz]]

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

Comment 5

[David Hyatt]

I don't get it.  Can't we just force an uninstall of beta 1 when beta 2 comes
out?

Comment 6

[Daniel Veditz [:dveditz]]

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.

Comment 7

[David Hyatt]

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

Comment 8

[Cathleen]

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

Comment 9

[Peter Trudelle]

I thought we pointy-hairs agreed yesterday that we would have 2 install options:
1) Navigator only
2) Everything.

Comment 10

[Cathleen]

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

Comment 11

[Daniel Veditz [:dveditz]]

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.

Comment 12

[Peter Trudelle]

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.

Comment 13

[Peter Trudelle]

Never mind, since dveditz says we can push it off, we will.

Comment 14

[David Hyatt]

This has been fixed.   Dynamic overlays are in and working.

Comment 15

[Paul MacQuiddy]

marking verified

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0dbbbb7f5132
[fenix] Import l10n. (https://github.com/mozilla-mobile/fenix/pull/12687)