Ok, the first thing I noticed about firefox 2.x (after upgrading from the last amd64-stable version, 1.5.0.9, I think) was that it doesn't ask for a master password when it first finishes loading a page which requires a password previously saved. But this is somehow related to some security bug, right? Anyway, after entering a username, two dialogs pop up at once asking for the master password. The second dialog is completely at the same position as the first one, therefore covering it. I've tried the following: 1) After entering the master password in the second dialog and clicking OK fills the password field, and then just closing or clicking cancel or OK (even using an empty or wrong or correct password) in the first one makes the first dialog disappear. 2) Closing (X) or clicking cancel in the second dialog and interacting with the first one results in the second dialog reappearing. 3) Closing both dialogs results in a single master password prompt being displayed (as would be proper). 4) Entering the correct password in the first dialog and pressing ENTER (as the buttons there don't even show mouse-over effects) results in that dialog disappearing (password field is not filled in webpage). When interacting with the second dialog the first dialog reappears. Entering the correct password in the second dialog and pressing ENTER (as now the buttons over there don't show mouse-over effects) results in that dialog disappearing (password field is again not filled in webpage). When interacting with the first dialog the second dialog reappears. And this could probably go on forever... I may not have looked through all possible cases, but i guess this would be enough for this bugreport at this time. (I'm tired also). However, using a clean profile, the master password dialog appears when I enter the first character(s) into the username field. After entering a correct password, it shows me a list of usernames that which match the entered text. Is this the correct behaviour? (I would not like to switch to a clean profile, as it would result in a major loss of passwords, bookmarks, settings, addons etc.) Please help!
There are way to migrate your passwd/bookmarks/etc to a new profile ... You should read a bit more about how mozilla works before filing bugs with us. This is not a problem with out build it is an issue with upstream breaking compatibility with profiles from older versions.
(In reply to comment #1) > There are way to migrate your passwd/bookmarks/etc to a new profile ... You > should read a bit more about how mozilla works before filing bugs with us. > This is not a problem with out build it is an issue with upstream breaking > compatibility with profiles from older versions. Sorry, I didn't know I had to know something most regular firefox-users don't know to file a bug. I searched this bugzilla, I searched the mozilla bugzilla. I think it would be a bit much to ask users to do a research project on firefox before filing a bug. This is still a bug as firefox is expected to work properly after an upgrade. At minimum, a notice to the ebuild, stating that profiles might break due to the upgrade, would be nice. (including references to documentation on how to migrate your profile to the new firefox) :) The current notice states: "Before filing any bugs, please move or remove ~/.mozilla and test with a clean profile directory.". If you read my first post, you will see, that I did indeed test this with a clean profile before filing this bug. :D Anyway, something like this would do: "An upgrade to version #.# might break users' profiles. If you experience any issues, please test with a clean profile directory. In case the problem disappears see the Firefox Users Profile Migration Guide at $URI on how to migrate your profile. If you still experience the issue, please file a bug." Please correct this issue. Thanks :)
I fail to see how this is an upstream issue when this behavior does not occur with www-client/mozilla-firefox-bin-2.0.0.1. As I know you're well aware, migrating to a new profile is not a fix for this bug, just a workaround.
Hasn't occured in recent 2.0.0.* versions. However I'm still using a migrated profile. Closing.
