Firefox behaves differently with same profile folder on different machines
Categories
(Toolkit :: Add-ons Manager, defect)
Tracking
()
People
(Reporter: contact, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:99.0) Gecko/20100101 Firefox/99.0
Steps to reproduce:
Firefox does not behave the same way when a profile folder is transferred from one computer to another. Here is a test with a fresh profile, and a roundtrip.
On computer A :
- cd /tmp
- mkdir tmp2
- firefox --no-remote --profile tmp2
- within firefox, install extension newTabTools (https://github.com/darktrojan/newtabtools) ; which provides an alternate page for new tabs
- open a new tab, validate Firefox confirmation dialog about some extension changing the new tab setting
- using the newTabTools interface, add a tile to website https://lemonde.fr (for example)
- close Firefox
- rsync -a tmp2/ computerB:/tmp/tmp6
On computer B :
- firefox --no-remote --profile /tmp/tmp6
- within Firefox, open a new tab
- instead of newTabTools interface, an XML error page referring to that extension's newTab.xhtml appears (moz-extensions://[bunchofletters]/newTab.xhtml)
- close Firefox
On computer A :
- rsync -a computerB:/tmp/tmp6 tmp6
- firefox --no-remote --profile tmp6
- open a new tab : newTabTools works properly
Firefox version is 99.0 on both computers.
Actual results:
Extension behaviour depends on which computer Firefox is run, even though the profile folder is the same.
Expected results:
Firefox and its extensions' behaviour should be entirely determined by the content of the profile folder.
|
||
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Toolkit::Startup and Profile System' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
On computer B, the console shows (a dozen of times)
IPDL protocol Error: Received an invalid file descriptor.
I do not know if this is related, but it does not appear on computer A.
|
||
Comment 3•3 years ago
|
||
It would probably be helpful to provide the specific error you see.
|
||
Comment 4•3 years ago
|
||
Hello,
I tried an approach to the issue on the latest Release (99.0.1/20220411174855) under Windows 10 and could not reproduce the issue you are having i.e. transferring profiles from one device to another does not cause the mentioned problems.
As for my approach,
On Device A:
- I’ve created a profile on Device A
- proceeded to install the mentioned add-on (and set the page provided by the add-on as the new tab page when prompted)
- added a tile for https://lemonde.fr/
- I’ve accessed about:profiles, located the profile and navigated to the profile folder by clicking on the “Open folder” button corresponding to the “Root Directory” entry. The path to the profile folder on Windows looks similar to
C:\Users\user_name\AppData\Roaming\Mozilla\Firefox\Profiles\profile_folder - I copied the profile folder and transferred it to Device B
On Device B:
- launched Firefox with the profile manager and created a dummy profile (profileB) but did not launch the browser. This causes a profile folder to be created at
C:\Users\user_name\AppData\Roaming\Mozilla\Firefox\Profiles\, which is empty - I copied the contents of the profile folder I transferred from Device A in the newly created profile folder above
- Launched Firefox.
After doing the above actions, on Device B, the extension is present in the browser, does not throw errors to console when opening a new tab and moreover, the tile I added on Device A for https://lemonde.fr/ is present on the new tab page of Device B.
I will however further investigate the issue and will update the bug with any findings.
|
||
Comment 5•3 years ago
•
|
||
This looks definitely like a duplicate of Bug 1429838, which is due to the fact that the absolute paths to the extension xpi is part of the details included in the profile (in extensions.json to be precise).
In particular
-
based on comment 0 it looks that the path to the profile on device B is different from the path to the profile on device A, and so:
- on Device B, running Firefox from the profile copied will hit Bug 1429838, in particular because the extensions will not be available at the absolute path listed in the extensions.json file part of the Firefox profile copied from Device B
- on Device A, when the profile is copied back from Device B but in a different path, the extension listed extensions.json file will be available at their original absolute path on Device A (unless removed from that path, e.g. if that profile has been moved instead of copied then it wouldn't work on Device A neither)
-
based on comment 4, the Firefox profile seems to be stored in the same absolute path on both Device A and Device B, and so it is expected to don't be able to reproduce the issue described in comment 0 (because it would not be recreating the condition needed to hit Bug 1429838).
The XML error on the extension newTab.xhtml is also something that Bug 1429838 would be able to trigger (e.g. because the page, or other resources needed by that page if the page have been able to be restored by the session restore, would be failing to be loaded because the extension xpi file is not at the path that Firefox expects and so the extension assets would not be reachable anymore).
Does this correspond with what you can also verify locally?
Let me know if there are other elements that doesn't seem to match Bug 1429838 and I'll re-open this bug.
Thank you so much for this ! Indeed, just renaming /tmp/tmp2 to /tmp/tmp1 locally exhibits the unwanted behaviour.
Regarding my use case, I did
rsync -a --delete $localPath/ $remoteMachine:$remotePath
sedParams='find $remotePath -type f -exec sed -i "" -e "s:$localPath:$remotePath:g" {} \;'
ssh $remoteMachine '$sedParams'
and this seems to be a valid workaround.
Description
•