Closed
Bug 258470
Opened 20 years ago
Closed 20 years ago
XULRunner shouldn't use firefox migration service
Categories
(Toolkit :: Startup and Profile System, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: janv, Assigned: darin.moz)
References
Details
Attachments
(2 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
benjamin
:
review+
|
Details | Diff | Splinter Review |
Comment 1•20 years ago
|
||
Actually, the xulrunner should attempt to do migration, it just shouldn't use
the firefox migration service. Ick, I'm not sure what we want to do about this
until the siamese twins xulrunner and firefox are separated.
Assignee: nobody → bsmedberg
Component: XP Miscellany → Startup and Profile System
Product: Browser → Firefox
QA Contact: brendan → bsmedberg
Summary: XULRunner shouldn't try to import settings for stanalone third-party apps → XULRunner shouldn't use firefox migration service
please please please please read component descriptions.
COMPONENT RETIRED. Please do not file bugs here.
Comment 3•20 years ago
|
||
Discussed with darin, we're going to add a DoMigration=true/false key to the
API. This will also prevent a restart in the (common) case that the app does not
provide a migration service.
Status: NEW → ASSIGNED
Assignee | ||
Comment 4•20 years ago
|
||
Here's a proof of concept patch. It added two flags to nsXREAppData:
enableProfileMigrator
enableExtensionManager
These flags allow an XRE-based app to enable/disable PM and EM.
I've stripped whitespace changes from this patch.
Assignee | ||
Updated•20 years ago
|
Assignee: bsmedberg → darin
Assignee | ||
Comment 5•20 years ago
|
||
here's a full patch. i left composer/app/nsComposerApp.cpp alone since it
seems to have bit-rotted anyways.
Assignee | ||
Updated•20 years ago
|
Attachment #158246 -
Flags: review?(bsmedberg)
Comment 6•20 years ago
|
||
Comment on attachment 158246 [details] [diff] [review]
v1 patch
In general, I prefer "true/false" to 0/1 but I'm not gonna be picky about it.
We still need some kind of compatibility.ini check, even if we disable the EM.
If you like, you can push this off to another bug, it won't be noticed for a
while. Actually, we need to expand the compatibility.ini check, because we need
to look at the xulrunner version *and* the app version.
Attachment #158246 -
Flags: review?(bsmedberg) → review+
Assignee | ||
Comment 7•20 years ago
|
||
> In general, I prefer "true/false" to 0/1 but I'm not gonna be picky about it.
Done. I'll accept arg[0] == '1', 't', or 'T' as true. Anything else is treated
as false.
> We still need some kind of compatibility.ini check, even if we disable the EM.
> If you like, you can push this off to another bug, it won't be noticed for a
> while. Actually, we need to expand the compatibility.ini check, because we need
> to look at the xulrunner version *and* the app version.
Yeah, we have the problem that EM is the one that actually writes
compatibility.ini today. I think we may want to arrange for nsAppRunner.cpp to
completely own the I/O on that file. That way, we can more easily disconnect EM
if not needed. I'll file another bug.
Assignee | ||
Comment 8•20 years ago
|
||
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment 9•20 years ago
|
||
> Done. I'll accept arg[0] == '1', 't', or 'T' as true. Anything else is treated
hm... maybe "yes" should also be accepted?
Updated•16 years ago
|
Product: Firefox → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•