Changes in Firefox "-no-remote" switch and running Fx

[therube]

Horsepoop. I do that all the time.

Well not exactly.
Depending on how you go about it, it is certainly possibly that you will run into the "Firefox is already running but is not responding
message". (That does & can happen.) The part about the "default" profile is just wrong (basically, or not explained completely, or dumbed down to the level of a FF user ).

[dhouwn]

Yep. I've looked at that before. A 15 MB (ZIP'd) app (36 MB unzipped) - so that you can simply change profiles. What a crock. But then it includes xulrunner .

I share therube's eyeroll at replacing the built-in Profile Manager with a standalone that *is bigger than my entire %prog%\F3 folder*, and
*twice the size of the entire F2 folder*.

I guess in a in this regard perfect world one would just have one single, centralised XULRunner system and many application running on it (e.g. Firefox, Thunderbird, Mozilla's multi-IM application, this profile manager, …), but I believe the bug tracker entries related to this have either been abandoned or marked as WONTFIX. Though they went a little bit into this direction with the update helper ("maintenance") service (but it seems not everyone from Mozilla's ranks is happy with this).

I didn't read all of this, and IDK everything about Win 7, but where I live, the NS folder is *not* in any Program Files folder, but rather in
%appdata%\mozilla\firefox\profiles. Each profile there, in its Extensions subfolder, has its own NS folder, 73a6... etc (with a country code prefix for non-US or non-English localizations, IIUC).

Of course, that's the default install method for extensions, i.e. the graphical one from inside the app is to install it into the profile.

Yep. Perpetuate the myth (wrong word) that FF users are nothing but a bunch of dummies.

It seems to be general consensus even or especially on Mozilla's side that this is not a feature for the masses, as can be seen from the bugzilla comments on recent bugs related to profile handling.

I would have to investigate the -profile switch more fully to understand what it does, & in particular what happens if used in a path in some "special folder" location, like ...\AppData\*.

I guess from Firefox's perspective it's no special location (in this case). As I understand it, this feature (which is a pretty recent addition) was meant to be simple, so what glob considered to be a bug stems from this simplicity.

[Tom T.]

SI have never used -profile before, always using just -P to specify a particular profile to use (or to bring up Profile Manager to manually select a profile).
I do use -no-remote with -P - all the time, even now.

I would have to investigate the -profile switch more fully to understand what it does, & in particular what happens if used in a path in some "special folder" location, like ...\AppData\*.

http://kb.mozillazine.org/Profile_Manag ... le_Manager

You can use the -profilemanager command line argument when starting the application, as specified below. A capitalized -P in place of -profilemanager should also work.

So -p is just a shorthand alias for -profilemanager.

Caution: Do not use -profile manager (do not add a space). This previously caused a " already running but is not responding" error. [4] Currently, due to the fix for bug 531532, the command line argument -profile <path> will create a new profile folder at <path> (if it doesn't already exist) and launches the application with a profile that isn't listed in the Profile Manager. (For example, if you run firefox.exe -profile manager on Windows 7, then Firefox will launch with a new profile and a folder named "manager" will be created in the C:\Users\<username> directory.)

Could this be part of OP's issue?

[therube]

-p, will load the browser, starting the named profile, or with the Profile Manager if no name is given
-profilemanager, will always load the Profile Manager (unless -P is also provided)
-profile, "starts with profile located at the given path" (& also creates it if not existing, & it need not exist in & will not be added to profiles.ini)

For the -P, the profile must exist & be able to be referenced from within profiles.ini.

Separately there is a -CreateProfile option.

The "Don't ask at startup" setting may also have an affect.

Note that the profile name is case sensitive (which I never realized till just now).
(Wonder if that is a bug, but seemingly not?)

-profilemanager & -profile-manager may be synonymous?

[Tom T.]

Note that the profile name is case sensitive (which I never realized till just now).
(Wonder if that is a bug, but seemingly not?)?

It's documented -- twice -- in the Profile Manager article.
http://kb.mozillazine.org/Profile_Manag ... _a_profile

The profile name is case-sensitive and using spaces in a profile name will require enclosing the profile name in quotes in a shortcut.

http://kb.mozillazine.org/Profile_Manag ... ic_profile

Note: Profile names are case sensitive...

[DJ-Leith]

Thanks again to those of you who have taken the time and trouble to
A. Read, B. Think and C. Post.
IIRC, I'm the only one who has reported these 'symptoms'.

The underlying cause is still not known.

The cause is, I suspect, due to changes in the 'internal to Firefox meaning' of the "-no-remote" startup switch
and/or
the location and USE of the "startupCache" subfolder in the
LOCAL vs ROAMING part of the Profile.

The more I think about it (and read in bugzilla) the more I am inclined to suspect
the 'wrong' "startupCache" is being used.

So, in the next few posts I will:
1. Summarise the thread so far.
2. Clarify a few points that have been posted above.
3. Discuss 'Local vs Roaming': why the Profile is split and "startupCache".
4. Discuss some of my experiments with "startupCache" and describe other 'symptoms' that I have seen.
5. List some bugs at bugzilla and other sources: with some comments.
6. Describe another proposed work around.


1. Summary of the thread to date

Seen by one reporter on three different computers.
OS
Microsoft Windows Vista (Home Premium SP2, 32 bit) and
Microsoft Windows 7 (Home Premium SP1, 64-bit)

Firefox versions
Seen on Fx 11 and 12. OP was on Fx 3.6.xx until 20 April 2012.

All Profiles were created using the 'built into Firefox' Profile Manager.

These profiles are all located, as one would expect using Fx 'out of the box' on
Vista or Windows 7, within the 'AppData tree'.

LOCAL

Code: Select all

C:\Users\UserNameHere\AppData\Local\Mozilla\Firefox\Profiles

ROAMING

Code: Select all

C:\Users\UserNameHere\AppData\Roaming\Mozilla\Firefox\Profiles

The LOCAL has only part of the Profile while the ROAMING seems to have
all (including the "startupCache" subfolder) of the Profile.

Code: Select all

C:\Users\UserNameHere\AppData\Roaming\Mozilla\Firefox\Profiles\v0kx56co.20-TestNR

So, there are two "startupCache" subfolders:

Code: Select all

C:\Users\UserNameHere\AppData\Local\Mozilla\Firefox\Profiles\v0kx56co.20-TestNR\startupCache

Code: Select all

C:\Users\UserNameHere\AppData\Roaming\Mozilla\Firefox\Profiles\v0kx56co.20-TestNR\startupCache

From October 2011 to April 2012 a set of shortcuts that
specified the full path to the Application (Fx or Aurora) AND the full Profile: as in this anonymised example
(I've changed the Windows User Name) worked without any issues.
The 'shortcut Target: field' is

Code: Select all

"C:\Program Files\Mozilla Firefox\firefox.exe" -profile 
"C:\Users\UserNameHere\AppData\Roaming\Mozilla\Firefox\Profiles\v0kx56co.20-TestNR" -no-remote

When using a shortcut like this example I think NONE of the LOCAL part of the Profile is accessed.
I think 'the whole Profile', for this 'Firefox session', is in the

Code: Select all

C:\Users\UserNameHere\AppData\Roaming\Mozilla\Firefox\Profiles\v0kx56co.20-TestNR

including subfolders below "...\v0kx56co.20-TestNR\".


The 'symptoms' that I have seen include:-
* When starting Fx I appear to have 'updated NoScript' when I have not.

* When starting Fx I appear to have 'downdated (gone back to an older release) of NoScript' when I have not.

* Apparently having two versions of NoScript at the same time: see OP and Post on Fri May 11, 2012 8:13 pm,
http://forums.informaction.com/viewtopi ... =15#p38601
and Post on Sat May 12, 2012 11:29 pm.
http://forums.informaction.com/viewtopi ... =15#p38662).

Also, you may recall, NoScript is installed per Profile.

I think some of these phenomena may have been caused by the 'wrong' "startupCache" being read when
starting or restarting Fx.


2. A few clarifications on the posts above in this thread

I think dhouwn (on Fri May 11, 2012 5:27 pm) may have thought
I was running a 64bit version of Firefox.

All three computers have 32bit Firefox (and 32bit Aurora).
However the two Windows 7 Computers have a 64 bit OS.

We both agree that the place to look for a machine wide
instillation of an Add on, for 32bit Firefox on Windows 7 64 bit OS
would be:
"C:\Program Files (x86)\Mozilla Firefox\extensions\".

The important point - which we have clarified (and double checked) - is that NoScript is installed per Profile.

I have said that I nearly always used the shortcuts to start Firefox
(between October 2011 and April 2012). I now realise that the main
exception to this has been when clicking links in PDFs.

This starts Firefox with the Profile Manager because I have

Code: Select all

[General]
StartWithLastProfile=0

as the first item in my Profile.ini

When this happens I usually close any 'already started by shortcut Firefox sessions'
and then choose my the Profile that I use for general browsing
(which happens to be the one illustrated in Pictures #01, #07 and #08).

So, I have not run into any 'already running Firefox' issues.
Also, as 3.6.xx (which I was using until 20 April 2012) did not have any "startupCache"
I never used the wrong "startupCache".


I have used several example Profile Names

Code: Select all

AtoZandNumbersRandom.ProfileNameHere

Code: Select all

rywfzqk3.ProfileNameHere

Code: Select all

v0kx56co.20-TestNR

These are also called 'salted Profile Names' in various bugs and discussions.
The 'built into Firefox' Profile Manager creates these.

It also creates the 'split' between the Roaming and the Local part of the Profile.
As I will document (below) this has led to 'unexpected' issues in e.g. Thunderbird and SeaMonkey.

Note also:
A. In all the posts (above) I said (or implied) that I thought my
'whole Profile' / 'full Profile' / 'real Profile' was the Roaming Profile

Code: Select all

C:\Users\UserNOAdmin\AppData\Roaming\Mozilla\Firefox\Profiles\v0kx56co.20-TestNR

B. All my shortcuts have both the "-profile" (pointing to the full path of the Roaming Profile)
and "-no-remote" startup switches.

DJ-Leith

Continued...

[DJ-Leith]

3.1 Local vs Roaming - why is the Profile split?

Short answers ...

Summary: keep cache & other temp files out of Windows roaming profile 2006-10-27
https://bugzilla.mozilla.org/show_bug.cgi?id=358332
Although this is a duplicate of the main bug 74085 (next) the description is nice and clear.

Summary: [Win] Disk cache should use local directory (CSIDL_LOCAL_APPDATA) (Reported 2001-03-30 - there are 30
duplicates and 125 Comments)
https://bugzilla.mozilla.org/show_bug.cgi?id=74085


Summary: Breaking up the profile for roaming, sharing and performance 2002-05-27
https://bugzilla.mozilla.org/show_bug.cgi?id=147344

which backup do I use Local or Roaming 2012-02-16
http://support.mozilla.org/en-US/questions/919542

I need to backup my FF profile please onto a USB stick. Do I backup the Local profile or Roaming
profile please

Thanks pingu70

(who has provided 5,931 solutions and 58,220 answers)
The one in roaming is the main profile folder.

C:\Users\<user>\AppData\Roaming\Mozilla\Firefox\Profiles\<profile>\

The other in local is used for storing the cache and doesn't need to be backed up.

C:\Users\<user>\AppData\Local\Mozilla\Firefox\Profiles\<profile>\

Two Copies of Same Profile 2010-01-05
http://forums.mozillazine.org/viewtopic ... &t=1682415
Gives helpful advice about the Local part of the Profile.

DJ-Leith

Continued...

[DJ-Leith]

3.2 The startupCache

I think at one point this was called "fastload".
I think the idea is to make Firefox 'appear to load faster', and allow the user
to interact with the web site they are trying to access without too much delay,
by caching resources.

Summary: startup cache - replacement for fastload cache 2009-10-02
https://bugzilla.mozilla.org/show_bug.cgi?id=520309

Firefox Startup Performance (December 2009)
http://autonome.wordpress.com/2009/12/1 ... ce-dec-14/
Author: Dietrich Ayala

Blog post about improving the start up time for Firefox: with links to bugs.


I think, but don't have evidence, that startupCache may have been in Fx 4.
There are references to trying to fix an issue for 4.0.1 (in bug 640968).
https://bugzilla.mozilla.org/show_bug.cgi?id=640968

As I went from Fx 3.6.28 to Fx 11 IDK.
Also, although I used Aurora - since Aurora (8.0a2) on 30/09/2011 - I only
had one Profile for Aurora per 'Windows User'.
This was started with a shortcut, with a "-profile", to the full Roaming Profile.

So, I now think the startupCache was introduced in Fx 4,
is created by Fx if it is 'not found',
is 'expected to be' in the Local Profile (on Windows - assuming you created Profiles using the 'built into Firefox' Profile Manager).

DJ-Leith

Continued...

[DJ-Leith]

Q. Do you think it is safe to delete the startupCache?
A. Yes. Safer would be to rename the folder.
e.g. from

Code: Select all

C:\Users\UserNameHere\AppData\Local\Mozilla\Firefox\Profiles\v0kx56co.20-TestNR\startupCache

to

Code: Select all

C:\Users\UserNameHere\AppData\Local\Mozilla\Firefox\Profiles\v0kx56co.20-TestNR\xx2-startupCache

Obviously, AFTER you have checked that there are NO FireFox.exe running.
Exit Firefox and then check with Task Manager.
<Control>+<Shift>+<Escape> to start Task Manager and then check the "Processes" Tab
and make sure there are no "firefox.exe" running.


Q. Have you done this (delete the \startupCache subfolder)?
A. Yes.

Depending on how I start Firefox a new \startupCache subfolder is created in
either the Local Profile (if started without the "-profile")
or the Roaming Profile (if started with a shortcut that specifies "-profile"
and the 'full Roaming Profile' - as discussed above).


Q. What is in the startupCache?
A. IDK, but I think it may contain information about fonts
(including character code mappings - CMap).

Summary: Cache system font information in startupcache 2010-09-29
https://bugzilla.mozilla.org/show_bug.cgi?id=600713

Diagnosing Slow Startup (2010-10-04)
http://blog.mozilla.org/tglek/2010/10/0 ... w-startup/
Blog post by Taras Glek (who contributed code to 600713).

Q. Does it contain anything else? What about JavaScript? - "prefs.js"?
A. I guess - but do NOT know - that "prefs.js" is cached in the startupCache.
I think this, because it could explain my previously reported observation (next)
which is at the end of a long post.

http://forums.informaction.com/viewtopi ... =15#p38662

(Sat May 12, 2012 11:29 pm)
You will recall from Pictures #07 and #08 (posted Fri May 11, 2012 8:13 pm) that

If I start Fx, using the Profile Manager, and select "2... ..." then everything is NoScript

2.4.1rc3.
...
However, if I start Fx, using the shortcut ... ... apparently,
two versions of NoScript: 2.4.1rc1 and 2.4.1rc3.

I copied the {73a6fe31-595d-460b-a920-fcc0f8843232}.xpi from the Profile that
was used to produce Pictures #07 and #08
I used 7-Zip to extract it and the "install.rdf" does contain <em:version>2.4.1rc3</em:version>.
This confirms what I thought: this Profile is 2.4.1rc3.

I now tried the following experiment.
Start Fx, using the shortcut.
Type "about:config" in the Address Bar, edit "noscript.version" from 2.4.1rc1 to become
2.4.1rc2 - this is NOT true. Close the Tab.
Type "about:config" again and check that the 2.4.1rc2 is still present.
The Date and Time of "prefs.js" is the time of the edit. Close Fx.
Copy the "prefs.js" to another location. Edit with e.g. Notepad, and find it contains

Code: Select all

user_pref("noscript.version", "2.4.1rc2");

Start Fx, using the shortcut. All is as before i.e. as in Pictures #07 and #08, so I don't know where
the 2.4.1rc1, which is now back in the "prefs.js", is 'coming from'. Remember we KNOW it is is 2.4.1rc3.

A cache???

DJ-Leith

I now think that the "prefs.js" that was cached in the Roaming \startupCache was
NOT the same as the 'real "prefs.js" file' that I copied from the Roaming Profile
(which contained the text 2.4.1rc2 that I had created). I also think that
the cached version then becomes the 'real version in RAM' when I started Fx using the shortcut
that had a "-profile" that forced the use of the 'full Roaming Profile' with the
Roaming startupCache. The cached version of "prefs.js" contained the 2.4.1rc1
while the 'real NoScript version' was 2.4.1rc3. The 'real version of "prefs.js" file', on
the hard disk, does have the correct data (2.4.1rc3). The 'version in RAM (from the startupCache)'
has the wrong data.

DJ-Leith

Continued...

[DJ-Leith]

Q. So, is there documentation / evidence that "prefs.js" is cached in the startupCache?
A. I've not found direct documentation to confirm this.

Summary: Report startup cache age via telemetry 2011-12-15
https://bugzilla.mozilla.org/show_bug.cgi?id=711297

Comment #2
https://bugzilla.mozilla.org/show_bug.cgi?id=711297#c2

(at 2011-12-16 14:09:20 PST)

Startup cache contains parsed chrome js and other system-specific caches.
It would be good to understand how long startup cache lasts before it is corrupted/blown away, especially once we put more stuff like bug 705594 into it.

It's in the "local" profile directory. See http://dxr.mozilla.org/mozilla/mozilla- ... .html#l124 for details.

The comments in Bug 686187 implies that there are graphical elements in the startupCache
that 'reappeared' when it was recreated.

Summary: bitmaps for scrollbars sometimes missing / not drawn 2011-09-10
https://bugzilla.mozilla.org/show_bug.cgi?id=686187


Q. When is the startupCache "startupCache.4.little" written?
A. Again, IDNK but the meta bug 593349 discusses delaying the writing so that
the cache is not fragmented.

Bug 586859 seems to imply that it can be written at "xpcom-shutdown". I don't know what that is.

Summary: meta: Startup cache writing algorithm causes severe fragmentation 2010-09-03
https://bugzilla.mozilla.org/show_bug.cgi?id=593349

Summary: Move startupcache write off the main thread 2010-08-12
https://bugzilla.mozilla.org/show_bug.cgi?id=586859

DJ-Leith

Continued...

[DJ-Leith]

4. Other observations

Q. OK, so I've been following the STR and I've got one (actually several) Profiles 'in a mess', with
about:addons reporting one version of NoScript and 'hover over the NoScript icon' shows a different version.
What do you advise?

A. I've found the quick and easy way to get 'all back to normal' is to delete the relevant
startupCache folder(s). Particularly, if you have 'messed up a Profile that you want to use'
(as opposed to a Test Profile). The 'slower way' is to carefully do lots of updates and restarts
until everything is 'back in sync'.

So, for example if the Roaming Profile "20-TestNR", started with a "-profile" switch to

Code: Select all

C:\Users\UserNameHere\AppData\Roaming\Mozilla\Firefox\Profiles\v0kx56co.20-TestNR

is 'not OK' and the same Profile started with the 'built into Firefox' Profile manager is OK.

Exit Firefox, check it has stopped and rename the \startupCache sufolder to e.g.

Code: Select all

C:\Users\UserNameHere\AppData\Roaming\Mozilla\Firefox\Profiles\v0kx56co.20-TestNR\xx3-startupCache

While trying to get to the bottom of this I have come across another phenomenon.

I have been able to lock a Profile while starting it one way but it is not locked
when I start it the other way.

To be more specific, I have been trying to use my 3rd Work Around.

(Fri May 11, 2012 3:16 pm)
...
Since I have stumbled across this I have been using my 3rd Work Around:-

WA3. Whenever you update NoScript, carefully use the Profile Manager to update all the Profiles,
one by one, rotating the "default" (as seen in "profile.ini"). I could do this.

So, I do not have a record of how frequently I was using, indirectly, the "profile.ini" file.
Right now I am NOT, I have started with a "-no-remote" switch.

On reflection, the first 'symptom' that I noticed was the 'NoScript splash screen' appearing
unexpectedly (when I was helping someone on their PC).

I did find the apparently two versions of NoScript, see Picture #01 in the first post,
quite disconcerting.

When I have seen the apparently NoScript reverting to a previous install (see Pictures #03, #04 and #05)
I have done a full round of NoScript Upgages (sic - I meant "Upgrades"), on all Profiles, NOT using the shortcuts (see
WA3. above).
Why? Because the last thing I want is the false sense of security of a 'partial install'
/ 'broken install' of NoScript. I think NoScript has been working normally. I think the 'symptoms'
are 'not the true situation'. It is very little trouble - for me - to do a round of updates - to be on the safe
side.

However, this has led to 'locked Profile issues' when using the shortcuts after I had done a 'round of
NoScript updates'. As I now understand this better - I had no hesitation in renaming the Roaming \startupCache
subfolders. This quickly 'fixed the locked Profile' issue.


I think I have now seen this (next)
Summary: Browser crash when trying to start browser against a locked profile [@ mozall... 2010-06-20
https://bugzilla.mozilla.org/show_bug.cgi?id=573369

My 'quick solution', to remove the relevant \startupCache subfolder, has worked every time.
In my case, I was convinced that MY issue was caused by 'the startupCache' having the 'wrong data' in it.

I am going to abandon WA3. and try another strategy.

DJ-Leith

Continued ...

[DJ-Leith]

5. Other bugs and comments


Summary: Remove Profile Manager UI 2003-07-31
https://bugzilla.mozilla.org/show_bug.cgi?id=214675

This bug has been open since July 2003!
dhouwn (above - on Sun May 13, 2012 10:22 am) cited it.

In Comment #46 Neil, a Mozilla code contributor, makes the following important point
https://bugzilla.mozilla.org/show_bug.cgi?id=214675#c46

(on 2009-12-30 14:05:39 PST)

-profile isn't the same anyway, because it puts everything in the same folder,
whereas the create profile wizard separates the local and roaming data.

This is the point quoted by therube (above - on Sun May 13, 2012 12:51 pm).

Explain?
(I never use windows "special" folders so not familiar.)

I hope the conversation with <glob> (see above - Tue May 15, 2012 5:42 am)
was helpful. Having read more on the Local and Roaming 'split of the Profile'
since then, I now have a better understanding of what <glob> was saying.

In the public discussion group there are many people who give examples
of how useful the Profiles (and the Profile Manager UI) are.

Removal of the Profile Manager UI? 2010-01-12
http://groups.google.de/group/mozilla.d ... b97c2655d#



More bugs, that I think may have some bearing on this include:-

Summary: Cache folders are created in the roaming profile rather than the local profile 2011-03-11
https://bugzilla.mozilla.org/show_bug.cgi?id=640989

Summary: New profile incorrectly uses Roaming for Local data location 2011-10-02
https://bugzilla.mozilla.org/show_bug.cgi?id=691155 <== a duplicate of 640989 affecting SeaMonkey.

There are issues with Thunderbird too.
Summary: Thunderbird does store local IMAP mail copy in AppData\Roaming not AppData\Local ... 2009-09-18
https://bugzilla.mozilla.org/show_bug.cgi?id=517425

Profile folder - Thunderbird
http://kb.mozillazine.org/Profile_folder_-_Thunderbird
Seems to say that the "startupCache" subfolder is in the Roaming Profile.


Other similar bugs, FYI
Summary: Thumbnail cache should be created in the Local profile folder, not the Roaming ... 2012-05-06
https://bugzilla.mozilla.org/show_bug.cgi?id=752407

In the Newsgroup mozilla.dev.extensions Neil made another helpful comment:
How to *stop* fastload cache? 2012-01-12
http://groups.google.com/group/mozilla. ... 340965fda5

Newsgroups: mozilla.dev.extensions
From: Neil <n...@parkwaycc.co.uk>
Date: Thu, 12 Jan 2012 10:04:02 +0000
Local: Thurs, Jan 12 2012 5:04 am
Subject: Re: How to *stop* fastload cache?


Manuel Reimer wrote:
> Jonathan Protzenko wrote:

>> In particular: « As of Gecko 2 (Firefox 4), JavaScript files are
>> cached ("fastload"). The -purgecaches command-line flag disables this
>> behavior. Alternatively, you can set the MOZ_PURGE_CACHES environment
>> variable. See this bug for more information. »

> Why is there no preference to disable this?

Because the startup cache starts up before the preferences do. (And no,
it wouldn't be easy to change that.)

I think we can infer from this that the startupCache is read VERY early in
the Fx startup. I don't think it is going to be be easy to avoid reading it
except by deleting the \startupCache sub folder BEFORE you start Fx.


Another bug worth reading:
Summary: Profile local data dir (ProfLD / NS_APP_USER_PROFILE_LOCAL_50_DIR) is incorre... 2010-10-22
https://bugzilla.mozilla.org/show_bug.cgi?id=606575

Again, Neil makes a very helpful comment (#5)
https://bugzilla.mozilla.org/show_bug.cgi?id=606575#c5

neil@p ... 2012-05-25 06:50:01 PDT

When you save a profile, it only saves the root path, not the local path. When you then start using that profile, if
the root path was relative to the roaming profile folder, it uses the local path relative to the local appdata profile
folder. Otherwise it uses the root path as the local path.

So either we should start saving the local path in profiles.ini, or creating a profile shouldn't be passed a local
path, instead it should assume the local path based on the root path being relative or not.

Summary: Startupcache can load invalid cache if unable to delete startupCache file 2012-02-06
https://bugzilla.mozilla.org/show_bug.cgi?id=724513
This looks, to me, like an interesting bug.

Also,
Summary: Find a way to get rid of prefetch files on Windows for faster startup 2011-10-05
https://bugzilla.mozilla.org/show_bug.cgi?id=692255

In Comment #1

... We can set the ACL's on the .pf files for our filename (it is the filename followed by a
hex hash of the file path by default)

Code: Select all

C:\Windows\Prefetch

Based on the Date and Time when I started either

Firefox
or
Aurora


The following files have their Modified Date and Time changed

C:\Windows\Prefetch\FIREFOX.EXE-A606B53C.pf <== Firefox

C:\Windows\Prefetch\FIREFOX.EXE-CEFE33A7.pf <== Aurora

So, we may see this soon.


Summary: Disable disk cache for users who have "Clear private data at shutdown" 2011-12-09
https://bugzilla.mozilla.org/show_bug.cgi?id=709262
I think this applies to me. I have "Clear private data at shutdown" set (Custom)
and "Cache" is one of the items I have checked (ticked).


Firefox/Projects/Startup Time Improvements
https://wiki.mozilla.org/Firefox/Projec ... provements
This wiki has lots of links. However, I could not find the answers to my specific questions from the main page.

DJ-Leith

Edited, on 14-Jun-2012, to fix one broken link.
Continued ...

[DJ-Leith]

6. Summary and new Work Around

So, I now think that the 'historic cause' was the laudable aim of
splitting the Profile into Local and Roaming parts.

The 'built into Firefox' Profile Manager (which I and many others find very useful)
attempts to make this 'split'. However, there are issues (e.g. Thunderbird on a Network).

In general 'all the stuff you want to backup' is in the Roaming part.
Indeed 'almost everything' is in Roaming and some documentation fails to mention Local
(and implies that 'Roaming is the full Profile' - I thought this too, until I came across
this issue).

The startupCache is IMHO a good idea. Also good to put it in the Local part of the Profile.
However, the documentation is NOT up to date.

It is NOT clear that a consequence of using a "-profile" switch that is pointing
to a Roaming profile is that you can have TWO \startupCache sub folders
AND that the one you don't use very often might have 'old data' that
CAN BE loaded into RAM. You then can have 'wrong data', e.g. the wrong version of NoScript
showing. POSSIBLY, I don't know, this could result in worse things happening.
I expect that when you do 'important things', e.g. Update an Add on, the startupCache
is rewritten. I think this is happening but, again, I don't know.

Also, FYI, I have done all my investigation on three Laptops where both Local and Roaming parts
of the Profile are on an internal Hard Disk. So, in my case, there was no performance benefit
from the Roaming / Local split. Indeed, my 'real startupCache' has been the Roaming one as
I use my shortcuts (with "-profile") to start Fx and Aurora almost exclusively.

Since 27 April 2012 - when I first noticed the strange phenomena - NoScript has had
at least 30 Updates (on EACH Profile) while none of the other Add ons in Picture #01
has had a single Update.

Personally, I have 'no problem' with the salted Profile Names or the 'default Profile locations' e.g.

Code: Select all

C:\Users\UserNameHere\AppData\Roaming\Mozilla\Firefox\Profiles\v0kx56co.20-TestNR

New Work Around

I will from now on
1. Delete all my Local startupCache folders.
2. Use my shortcuts (that have "-profile" pointing to the Roaming Profiles).
3. Do all my Firefox and Add on updates using the shortcuts like I did from October 2011 to April 2012 on 3.6.xx
(opposite to WA3.)

4. If I need to 'open a link from a PDF' (or anything that 'launches the default browser') let it
launch Firefox, use my 'normal browsing Profile'.
5. If I need to create another Profile, start Fx using the 'built into Firefox' Profile Manager.

In 4 or 5:
If I'm 'locked out' / can't start Fx, then just delete the Local startupCache.
If I have 'bizarre' apparently updated NoScript information, don't worry - consider deleting the Local startupCache.

DJ-Leith