nsAppRunner.cpp should write compatibility.ini

RESOLVED FIXED

Status

()

Toolkit
Startup and Profile System
RESOLVED FIXED
13 years ago
9 years ago

People

(Reporter: Darin Fisher, Assigned: Darin Fisher)

Tracking

unspecified
Points:
---
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

14.37 KB, patch
Benjamin Smedberg
: first-review+
Details | Diff | Splinter Review
(Assignee)

Description

13 years ago
nsAppRunner.cpp should write compatibility.ini

currently, EM writes out compatibility.ini so that it can indicate changes to
the components list.  however, EM never reads this file.  it would be better if
we used another mechanism to signal a need to re-run component registration. 
then, the version checking could be managed entirely by nsAppRunner.cpp (i.e.,
it will read and write the compatibility.ini version fields).

this is a pre-req to fixing bug 258638

note: xulrunner needs to be able to disable EM completely for apps that don't
want EM, but version checking must not be disabled in the process.
(Assignee)

Comment 1

13 years ago
Created attachment 167797 [details] [diff] [review]
v0 patch - prototype

this is just a prototype patch.  it seems to work the way i want it to work,
but at a minimum, some comments (and printfs/dumps) would need to be cleaned up
before it can be landed.

the idea here is to make EM write out a .autoreg file to the profile directory.
 if that file is encountered by nsAppRunner.cpp then it will blow away the
compreg.dat and xpti.dat (just as we did when we previously encountered the
components list changed flag in compatibility.ini).  i then added a
WriteVersion function to complement the GetVersion function in nsAppRunner.cpp,
and i moved the version checking out of the "do this only if EM is enabled"
block.	unlike .autoreg in the app directory, the .autoreg file in the profile
directory is removed once it is seen by nsAppRunner.cpp.  there is no need to
compare its date against another file since we only have one compreg.dat to
worry about.

we might want to extend this to also support .autoreg in the xulapp directory,
but that's not a requirement to solve this bug.
(Assignee)

Comment 2

13 years ago
Created attachment 168092 [details] [diff] [review]
v1 patch

OK, here's a final version of the patch.  It includes a better version stamp
for compatibility.ini.	Instead of just writing the appBuildID, we now write
the appVersion, appBuildID, and GRE_BUILD_ID.
Attachment #167797 - Attachment is obsolete: true
(Assignee)

Comment 3

13 years ago
Comment on attachment 168092 [details] [diff] [review]
v1 patch

Ben Goodger reviewed the changes to nsExtensionManager.js.in
Attachment #168092 - Flags: first-review?(bsmedberg)

Comment 4

13 years ago
Comment on attachment 168092 [details] [diff] [review]
v1 patch

>Index: xre/nsAppRunner.cpp

>+  aProfileDir->Clone(getter_AddRefs(file));
>+  file->AppendNative(FILE_COMPATIBILITY_INFO);

check if (file) for OOM.

>+  nsCOMPtr<nsILocalFile> localFile(do_QueryInterface(file));
>+  parser.Init(localFile);

I know we fixed the assertion, but I would desperately like it if we checked
the rv of Init().

All these "\r\n" are icky. Perhaps we could make a macro for "\r\n" on win32
and "\n" everywhere else?

>+static PRBool ComponentsListChanged(nsIFile* aProfileDir)
>+{
>+  nsCOMPtr<nsIFile> file;
>+  aProfileDir->Clone(getter_AddRefs(file));

Again, I think we should null-check the clone calls.

>+  file->AppendNative(NS_LITERAL_CSTRING("compreg.dat"));
>+  file->Remove(PR_FALSE);
>+
>+  file->SetNativeLeafName(NS_LITERAL_CSTRING("xpti.dat"));
>+  file->Remove(PR_FALSE);
>+
>+  file->SetNativeLeafName(NS_LITERAL_CSTRING(".autoreg"));
>+  file->Remove(PR_FALSE);

Please also remove xul.mfl or whatever the fastload filename is. I would love
to remove the profile chrome.rdf, but we can't yet.
Attachment #168092 - Flags: first-review?(bsmedberg) → first-review+
(Assignee)

Comment 5

13 years ago
> All these "\r\n" are icky. Perhaps we could make a macro for "\r\n" on win32
> and "\n" everywhere else?

nsCRT.h happens to define NS_LINEBREAK :-)


> Please also remove xul.mfl or whatever the fastload filename is. I would love
> to remove the profile chrome.rdf, but we can't yet.

Hmm... I'd have to use nsIFastLoadService::newFastLoadFile to get a pointer to
this file.  That'd work I suppose, but the fastload file format is supposed to
deal properly with changes.  That's why it's versioned, so I don't think we
really need to wipe out this file.
(Assignee)

Comment 6

13 years ago
fixed-on-trunk without XUL.mfasl / XUL.mfl / XUL Fastload File deletion fu.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED

Updated

11 years ago
Flags: in-testsuite-

Updated

9 years ago
Component: XRE Startup → Startup and Profile System
QA Contact: nobody → startup
You need to log in before you can comment on or make changes to this bug.