Created attachment 394022 [details] Screenshot of the Firefox 35 Profile Manager.png The profile manager appears to be broken in Firefox 35. I have configured Firefox to always show the Profile Manager on startup. Until version 34, it always pre-selected the last used profile in the list box so I could usually just press the Return key to continue. After upgrading to version 35, Firefox creates a new unwanted "dev-edition-default" profile which is always pre-selected in the Profile Manager regardless of the last profile used. Even when I select another profile and check the "Use the selected profile without asking at startup" checkbox, Firefox will NOT default to the selected profile at next startup, but start up using the unwanted "dev-edition-default" profile it previously generated. This is a really annoying regression and I don't know of any workarounds. I tried removing write access to the ~/.mozilla/firefox folder and ~/.mozilla/firefox/profiles.ini file, but then Firefox 35 refused start and even show the Profile Manager. This seems to be Firefox-specific so I'm currently omitting my "emerge --info". [ebuild R ~] www-client/firefox-35.0 USE="bindist dbus gstreamer hardened minimal startup-notification system-cairo system-icu system-jpeg system-libvpx system-sqlite wifi -custom-cflags -custom-optimization -debug (-gmp-autoupdate) -jit (-pgo) -pulseaudio (-selinux) {-test}" LINGUAS="et -af -ar -as -ast -be -bg -bn_BD -bn_IN -br -bs -ca -cs -cy -da -de -el -en_GB -en_ZA -eo -es_AR -es_CL -es_ES -es_MX -eu -fa -fi -fr -fy_NL -ga_IE -gd -gl -gu_IN -he -hi_IN -hr -hu -hy_AM -id -is -it -ja -kk -km -kn -ko -lt -lv -mai -mk -ml -mr -nb_NO -nl -nn_NO -or -pa_IN -pl -pt_BR -pt_PT -rm -ro -ru -si -sk -sl -son -sq -sr -sv_SE -ta -te -th -tr -uk -vi -xh -zh_CN -zh_TW"
I would like to confirme a problem with profile. fiefox-35.0 seems to be a dev edition and as such create a new dev profile and switch to it by default. I have been using firefox on gentoo for some time now and it's the first time I encounter this issue. It's anoying as after upgrading I thought I had lost all bookmark/passwords (My heart sank for a few secondes)and had to copy some files from old "normal" profile to get them back. And if next version is not a dev edition will have to do the same. Until now I never had to do a manipaltion after upgradin firfox... we can use the sync feature of firefox to do this ,but I don't use it by default. In case of a dev edition a warning/comment would be nice or maybe another ebuild.
Some information on reverting to the old setup here, IMHO it would be a good idea to try to apply this via the ebuild by default (for USE=bindist of course): https://developer.mozilla.org/en-US/Firefox/Developer_Edition/Reverting
(In reply to Ben Kohler from comment #2) > Some information on reverting to the old setup here, IMHO it would be a good > idea to try to apply this via the ebuild by default (for USE=bindist of > course): > > https://developer.mozilla.org/en-US/Firefox/Developer_Edition/Reverting This didn't work. The only side-effect to the instructions was that I have also lost my custom firefox theming and am unable to restore it by disabling/enabling it from the about:addons page. ;(
To work around this issue, I renamed the original firefox profile directory to the new developed edition profile directory name. 1. Go to ~/.mozilla/firefox 2. Make a backup of the original profile folder (ex. abc123.default). 3. Remove the developer edition profile directory, but remember its name (ex. abc123.dev-edition-default) 4. Rename the original profile directory to the name of the deleted developer edition profile directory.
Option 2 from https://support.mozilla.org/en-US/kb/recover-lost-bookmarks-firefox-developer-edition (Uncheck "Allow Firefox Developer Edition and Firefox to run at the same time" in about:preferences) seems to work as a workaround. This seems to be implemented by touching ~/.mozilla/firefox/ignore-dev-edition-profile , though, so I don't see a way the ebuild could handle it. I also don't understand why this is connected to bindist. I thought that just controlled branding.
(In reply to William Throwe from comment #5) > I also don't understand why this is connected to bindist. I thought that > just controlled branding. That's also what "quse -D bindist" or ${PORTDIR}/profiles/use.local.desc says about firefox: www-client/firefox:bindist - Disable official Firefox branding (icons, name) which are not binary-redistributable according to upstream.
I'm not sure if this is related, but another regression I'm experiencing after upgrading to Firefox 35 is that saved passwords are no longer filled in. I don't even get a master password prompt any more. Fortunately I can copy-paste the usernames/passwords from the saved passwords dialog from the settings dialog (which does correctly prompt my master password).
(In reply to William Throwe from comment #5) > Option 2 from > https://support.mozilla.org/en-US/kb/recover-lost-bookmarks-firefox- > developer-edition (Uncheck "Allow Firefox Developer Edition and Firefox to > run at the same time" in about:preferences) seems to work as a workaround. > This seems to be implemented by touching > ~/.mozilla/firefox/ignore-dev-edition-profile , though, so I don't see a way > the ebuild could handle it. No such file was generated when I unchecked the box from the preferences dialog, which I accessed from the main menu (Edit -> Preferences). When I manually created this file, I could successfully get rid of this bug. And I can also confirm than unchecking that checkbox from about:preferences instead of the settings dialog also creates that file. Therefore the actions proposed by comment #5 or touching the ~/.mozilla/firefox/ignore-dev-edition-profile file seem to be valid workarounds at this point. PS: This did not solve the possibly unrelated issue with saved passwords not being filled in.
(In reply to Jaak Ristioja from comment #6) > (In reply to William Throwe from comment #5) > > I also don't understand why this is connected to bindist. I thought that > > just controlled branding. > > That's also what "quse -D bindist" or ${PORTDIR}/profiles/use.local.desc > says about firefox: > > www-client/firefox:bindist - Disable official Firefox branding (icons, > name) which are not binary-redistributable according to upstream. I believe that the unbranded firefox *is* the developer edition (at least as of firefox 35), so that's likely why there are issues relating to developer-edition and USE="bindist". As to the issue in general.... I don't know, yet.
*** Bug 542040 has been marked as a duplicate of this bug. ***
(In reply to Ian Stakenvicius from comment #9) > I believe that the unbranded firefox *is* the developer edition (at least as > of firefox 35), so that's likely why there are issues relating to > developer-edition and USE="bindist". The developer edition/channel is a pre-beta channel, currently offering version 41.0a2. If it's upstream's intention that building unbranded firefoxen should result in them behaving like developer channel builds, I can't find anything about it. But they're not great at keeping their build documentation up-to-date, so you'd probably have to ask them directly.
A bug report I found upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=1096314
OK so at this time I don't know how to deal with this from within the ebuild. However, if any if you want firefox to use regular profiles instead of forcing the developer profile, do this: touch ~/.mozilla/firefox/ignore-dev-edition-profile Then, you can run 'firefox -P' to choose whatever default profile you want to continue using, as per the way things used to be.
Firefox-40.0.3 and firefox-41_beta* on mozilla-overlay have a proposed fix; I've un-done the code changes that setting MOZ_DEV_EDITION causes, which includes the changes to profiles code; this puts everything back to the way it was prior to firefox-35. Please test, if this solution is acceptable then I'll use it for the next release.
*** Bug 541278 has been marked as a duplicate of this bug. ***
Firefox-41 in the main tree (gentoo repo) has the implemented fix; could I get some comments as to whether it works as expected/desired? I'd like to close this, alternatively adjust the solution as might be needed... Has any expected functionality been lost here? If there's a true need for the MOZ_DEV_EDITION code I can likely add a flag (default-off) to keep it in place...
(In reply to Ian Stakenvicius from comment #16) > Has any expected functionality been lost here? I couldn't find any lost funtionality. > If there's a true need for the MOZ_DEV_EDITION code I can likely > add a flag (default-off) to keep it in place... I think when extension signing is enforced upstream (scheduled for Fx 44 last I looked), there should be a way to disable it in unbranded builds. I don't know if the MOZ_DEV_EDITION code affects that or not.
I have lost track of my original bookmarks/tabs etc., but let me just add that at the moment I have: $ ls -latr ~/Desktop/Old\ Firefox\ Data/2czh3u8v.default drwx------ 16 xx xx 4096 Oct 28 18:54 . ... $ ls -latr ~/.mozilla/firefox/ total 24 drwx------ 2 xx xx 4096 Mar 15 2010 Crash Reports drwx------ 6 xx xx 4096 Oct 17 2012 .. drwx------ 11 xx xx 4096 Oct 26 12:06 xqyip8gr.dev-edition-default drwx------ 5 xx xx 4096 Oct 28 18:54 . -rw------- 1 xx xx 216 Oct 28 21:06 profiles.ini drwx------ 11 xx xx 4096 Dec 4 14:31 xo5u46y6.default-1446054844755 $ Upgradded www-client/firefox-40.0.3 to www-client/firefox-41.0.2 on Oct 26. Upgraded www-client/firefox-41.0.2 to www-client/firefox-42.0 on Nov 21. Upgraded to www-client/firefox-42.0-r2 on Dec 2.
If you feel I have closed your bug and it is still a current issue, please reopen and update it completely. We will not work bugs that have no ebuild in tree any longer or can not be reproduced with a current system. Thank You for your support and understanding The Mozilla Team
