12361 - [feature] need to support auto registering components

Status: VERIFIED FIXED

(Core Graveyard :: Installer: XPInstall Engine, defect, P1)

Description

[Cathleen]

we need to support auto registering components, after a component is installed
via xpinstall.

Comment 1

[Doug Turner (:dougt)]

marking as a BLOCKER and DOGFOOD.  I need this so that we can distrubute xpi
files to mozilla users without requiring them to restart their browser.

Comment 2

[leger]

Putting on [PDT-] radar...sorry..this is for beta..not dogfood.

Comment 3

[Daniel Veditz [:dveditz]]

Putting back through the pdt group. SSL is part of the dogfood requirement, and
XPInstall is how we are packaging the proprietary Cartman components.

Comment 4

[leger]

Putting on the PDT- radar.  Spoke with dveditz.  ok with him

Comment 5

[leger]

Bulk move of XPInstall (component to be deleted) bugs to Installer: XPInstall
Engine

Comment 6

[Daniel Veditz [:dveditz]]

This is not dogfood. In fact, XPCOM currently auto-registers all the time --
what we'd want to do is turn that off, but then have a way for an install to
trigger registration when needed. This would be a start-up performance
improvement (Simon Frasier measured about 0.5 seconds on the Mac) but not
necessary for M12 or dogfood.

Comment 7

[Peter Trudelle]

On behalf of PorkJockeys: putting on beta1 radar, per beta criteria priority #2 
- startup performance on Mac is not within beta metrics. cc waterson.

Comment 8

[leger]

Putting on PDT+ radar for beta1.

Comment 9

[Daniel Veditz [:dveditz]]

Making pdt+ bugs P1

Comment 10

[Michael La Guardia]

I'm trying to understand this one.  Is this to improve startup performance on 
the Mac?  Is this a big win?  Should it be moved to post beta?  I suggest that 
people who know better than me might want to remove the pdt+ designation for 
reconsideration.

Comment 11

[Michael La Guardia]

I just read http://bugzilla.mozilla.org/show_bug.cgi?id=12817.

It sheds a bit more light on the performance nature of the bug, but Simon never 
gave an answer.  Is this a big win or a small gain?

Comment 12

[Daniel Veditz [:dveditz]]

Fix checked in, we will now signal the need for an autoreg after every 
install.  Once dbragg gets the new mode flags checked in we can limit this to 
only those installs that indicate they've checked in components.

Comment 13

[Jimmy Lee]

Reopening as I had discussed with Dan yesterday.  I have observed some 
inconsistencies between Macintosh and Windows.  And I'm not quite sure if either 
is correct.  Dan has agreed to help verify.  Thanks, Dan.

Comment 14

[Daniel Veditz [:dveditz]]

I was not flushing the registry after writing to it, possible shutdown leaks or 
crashes may have lead to unsaved data. I've added an explicit close/flush after 
setting the "need autoreg" flag. I no longer see the inconsitencies jimmy is 
seeing, but I saw them only occasionally anyway. This may or may not help.

Comment 15

[Jimmy Lee]

Build 2000-02-28-09-M15(WIN), 2000-02-28-08-M15(MAC)

Verified on Macintosh and Windows NT/98.  Autoreg flag is getting set from Yes 
to No from Mozilla Registry.  Component.reg increases in size after triggering 
mail.xpi.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4427d0769495
[components] For https://github.com/mozilla-mobile/android-components/issues/12361 - Changed `distinctUntilChangedBy` to `ifChanged` in SearchFeature