this makes it so the create profile wizard uses the generic wizard js
(mozilla/xpfe/global/resources/content/wizard*, mozilla/xpfe/global/resources/content/widgetStateManager.js)
confuse people into thinking it has something to do with the Mac command key.
This means changing all the XUL keybinding files from command= to xulkey=.
r=brade.
gracefully handle migration if the user used movemail (unix only) in 4.x
wrap all the movemail code with #defines, it is not needed on non-unix
platforms. movemail is still not supported, but at least now migration
(of bookmarks and cookies) doesn't fail, and you can see your old mail
in 5.0.
before, if "mail.directory" was set, we'd assume the mail wasn't in the standard
default place, so we'd migrate Mail -> Mail5
now, we check if "mail.directory" == the default place. if so, we migrate
it like we would if it wasn't set.
Mail -> Users50/<profile>/Mail
to help do this, I added Equals() to the nsIFileSpec interface, to compare
two nsIFileSpec's, it does this by comparing the nsFileSpecs.
r=sspitzer
I made changes so that:
1) exit quits the app, and doesn't start up app with the last current profile
2) fix a spelling error (personalisation -> personalization), this is en-US, not en-UK
3) fix it so start actually starts the selected profile.
4) -SelectProfile launches this new dialog
5) if the user starts with no command line, and they have more than one profile, they get -SelectProfile, and not -installer.
functionality, and also to free up the namespace for a *real* Copy
and Move that allow renaming the leaf name rather than just copying
into different directories (i.e. to make backup files). r=ssu
reviewed by Ben Goodger <rgoodger@ihug.co.nz> and Seth Spitzer <sspitzer@netscape.com>
Scripts running from chrome are considered super privileged and can perform operations that
scripts from the web cannot. I differentiate chrome scripts from web
scripts by considering all scripts loaded from chrome: URIs to be
privileged.
The problem I'm running into is that the loading of relative urls in
this code ends up going to the file: protocol (which is what the chrome
protocol is converted to internally). This change makes sure we load
from the chrome protocol so that the scripts are privileged and don't
get access errors. It's probably a good idea to load from the chrome
protocol anyway since it may one day be resolved to extracting from a
JAR file rather than accessing a discrete file.
