Closed Bug 12361 Opened 21 years ago Closed 20 years ago
[feature] need to support auto registering components
we need to support auto registering components, after a component is installed via xpinstall.
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.
Putting on [PDT-] radar...sorry..this is for beta..not dogfood.
Putting back through the pdt group. SSL is part of the dogfood requirement, and XPInstall is how we are packaging the proprietary Cartman components.
Putting on the PDT- radar. Spoke with dveditz. ok with him
Bulk move of XPInstall (component to be deleted) bugs to Installer: XPInstall Engine
Status: NEW → ASSIGNED
Summary: BLOCKER DOGFOOD [feature] need to support auto registering components → [perf][feature] need to support auto registering components
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.
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.
Putting on PDT+ radar for beta1.
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 reconsideration.
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?
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.
Status: ASSIGNED → RESOLVED
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.
Status: RESOLVED → REOPENED
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.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 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 mail.xpi.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.