Closed Bug 12361 Opened 21 years ago Closed 20 years ago

[feature] need to support auto registering components


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

Windows NT


(Not tracked)



(Reporter: cathleennscp, Assigned: dveditz)



(Keywords: perf, Whiteboard: [PDT+] fix in hand, needs review)

we need to support auto registering components, after a component is installed
via xpinstall.
Blocks: 11020
Blocks: 12805
Target Milestone: M11
Depends on: 12816
Depends on: 12817
Depends on: 12823
Summary: [feature] need to support auto registering components → BLOCKER DOGFOOD [feature] need to support auto registering components
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.
Whiteboard: [PDT-]
Putting on [PDT-] radar...sorry..this is for beta..not dogfood.
Whiteboard: [PDT-] → [PDT]
Putting back through the pdt group. SSL is part of the dogfood requirement, and
XPInstall is how we are packaging the proprietary Cartman components.
Whiteboard: [PDT]
Whiteboard: [PDT-]
Putting on the PDT- radar.  Spoke with dveditz.  ok with him
Bulk move of XPInstall (component to be deleted) bugs to Installer: XPInstall
Summary: BLOCKER DOGFOOD [feature] need to support auto registering components → [perf][feature] need to support auto registering components
Whiteboard: [PDT-]
Target Milestone: M12 → M13
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.
Blocks: 22176
Target Milestone: M13 → M14
Keywords: perf
Summary: [perf][feature] need to support auto registering components → [feature] need to support auto registering components
On behalf of PorkJockeys: putting on beta1 radar, per beta criteria priority #2 
- startup performance on Mac is not within beta metrics. cc waterson.
Keywords: beta1
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
Making pdt+ bugs P1
Priority: P3 → P1
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 
I just read

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?
Whiteboard: [PDT+] → [PDT+] 2/15
Whiteboard: [PDT+] 2/15 → [PDT+] fix in hand, needs review
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.
Closed: 20 years ago
Resolution: --- → FIXED
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.
Resolution: FIXED → ---
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.
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
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 
No longer blocks: 22176
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.