User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11) Gecko/20060728 Firefox/18.104.22.168 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) Gecko/20060728 Firefox/126.96.36.199 I am running Firefox 188.8.131.52 on WindowsXP SP2 on a managed network that uses "roaming profiles" (I can log onto any computer on campus and my personal settings will load). Occasionally, and for no apparent reason, the name Windows uses to refer to my account changes (not my login name). For example, say my login name is "user". I have a directory C:\Documents and Settings\user. For some reason, Windows decides to change the way it refers to me and now stores my settings in a folder C:\Documents and Settings\user.DOMAIN . The next time, I'm C:\Documents and Settings\user.DOMAIN.000, then .001, etc. (all this is done behind the scenes, I still login as "user" and there is no obvious indication that my internal settings directory has changed again). Here's where the problem is: Firefox stores paths to settings directories as absolute paths, even those in the "Documents and Settings" hierarchy. So, when Windows randomly decides to change the name of my settings directory, Firefox uses cached, absolute paths to directories which still exist, but are empty. The major issue I had was my FoxLinks extension breaking (it quit working entirely, no error messages, just acted like it wasn't installed). Whenever I opened the "Tools->Extensions" menu and tried to open the configure dialog for FoxMarks, the Extensions window would freeze up, refuse to respond, and would not close until Firefox was forcibly killed (I could still use the browser in the background though). I have been working with the FoxMarks developers to solve the problem, and we have discovered that because Firefox is using a cached path to the settings directory, when Windows changes my internal directory name, the extension cannot find all of its parts anymore. This problem happens every time that Windows changes my internal directory name. The only fix is uninstalling and reinstalling the effected extension. FoxLinks is the only extension I have installed, so I cannot give any other examples of things that break when the internal directory path is changed. If Firefox stores paths as relative to the users's Application Data folder, it can use one of Windows' built-in environment variables to complete the path (%APPDATA% or something similar) I know that this is a duplicate of bugs #165841 and #186774 (which lists more duplicates), but this bug/chain is listed as RESOLVED, when it clearly is not. Reproducible: Always Steps to Reproduce: 1. Install Firefox and the FoxLinks extensions onto a Windows XP computer on a managed network that uses Roaming Profiles 2. Wait until Windows decides to change the internal name of your settings directory (I don't know how to force this) 3. Start Firefox and try to use FoxLinks (including accessing the configuration dialog in the "Tools->Extensions" box) Actual Results: FoxMarks will not sync or update itself, and the "Tools->Extensions" window will freeze when the FoxMarks configure button is clicked. Expected Results: FoxMarks should have periodically sync-ed itself with the server, and should have displayed a configuration dialog when the configure button was clicked. Again, I know this is a duplicate, but I report it again because it is previously indicated as RESOLVED and the problem is still occuring.
Just to confirm, you don't lose your bookmarks or other settings when Windows decides to change the path in C:\Documents & Settings ? Just this FoxMarks extension misbehaves ? If that's true, then your profile is not being lost completely, but something within that profile is using an absolute path. I'm pushing this over to Extension/Theme Manager since there seem to be absolute paths in extensions.ini, but I would _guess_ this is a FoxMarks problem.
Component: OS Integration → Extension/Theme Manager
QA Contact: os.integration → extension.manager
Summary: Hard-coded paths break with XP's roaming profiles. → Hard-coded paths break with XP's roaming profiles
Version: unspecified → 1.5.0.x Branch
(In reply to comment #2) > My bookmarks and other settings seem to be okay (except they lose their > FoxMarks capabilities), and everything except Foxmarks is the browser default. The two parts of this sentence aren't consistent, which is it ?
So when a profile directory changes it looks like the EM doesn't notice (since it uses extensions.cache to check for extension changes and that uses relative directories). This would mean that extensions.ini has invalid info and so the chrome registry tries to load the extensions from the old place. Thats definately a problem. This should affect all extensions, does trying to view the options of other extensions also hang the EM window?
I believe fixing Bug 337053 would fix this but it would be a good thing to verify the behavior
I think I can confirm this albeit in a slightly different manner. I renamed my profile directory and changed profiles.ini to point to it. When starting firefox all those extensions in the profile were no longer working and had no icons in the Addons manager. The extensions.ini file was not updated for the new path. Really I think this and bug 337053 are really just two forms of the same issue, the profile folder path changing and Firefox not noticing.
(In reply to comment #3) > (In reply to comment #2) > > My bookmarks and other settings seem to be okay (except they lose their > > FoxMarks capabilities), and everything except Foxmarks is the browser default. > > The two parts of this sentence aren't consistent, which is it ? > Sorry, two thoughts in one sentence that don't fit together well. I meant to say: FoxMarks seems to be the only thing that is affected. I have no themes, extensions or customizations installed other than the FoxMarks extension, so I can't say if it is only this extension that is affected.
Confirming this, not sure if it should be a dupe but given the two bugs are fairly different circumstances just marking as dependant, though I fully expect that fixing bug 337053 would resolve this.
Status: UNCONFIRMED → NEW
Depends on: 337053
Ever confirmed: true
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 344671
You need to log in before you can comment on or make changes to this bug.