Closed Bug 1019885 Opened 5 years ago Closed 5 years ago

Saved password exceptions dialog shows "[object Object]"

Categories

(Toolkit :: Password Manager, defect)

x86
macOS
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla32

People

(Reporter: Dolske, Assigned: Paolo)

References

Details

(Keywords: regression, Whiteboard: p=1 s=33.1 [qa!])

Attachments

(2 files)

I'm assuming this may be a regression from bug 853549, so presumptively assigning :). If I go into Prefs -> Security -> Exceptions (for saved passwords) I get a dialog with a single line containing "[object Object]".

Looks like my logins.js data is correct, at the end is:

  "disabledHosts":[{"id":271,"hostname":"https://www.paypal.com"}]

(Although why is there an id in there? I though we nuked that.)
Attached image screenshot
No errors in the browser console, the debugging output seems normal:

Login Manager: Getting a list of all disabled hosts
PwMgr json: _getAllDisabledHosts: returning 1 disabled hosts.
(In reply to Justin Dolske [:Dolske] from comment #0)
> (Although why is there an id in there? I though we nuked that.)

You probably ran an early version of the patch and had an old-format database.

Confidently closing as INVALID, feel free to reopen if that happens again after nuking logins.json (and triggering the preference to reimport old passwords).
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID
(In reply to :Paolo Amadini from comment #2)
> (In reply to Justin Dolske [:Dolske] from comment #0)

> You probably ran an early version of the patch and had an old-format
> database.

I have the same problem and didn't try any earlier patches.
Removing logins.json presumably will be dataloss of new saved passwords between checkin of Bug 853549 & now?!
Flags: needinfo?(paolo.mozmail)
I see the same thing, and didn't test intermediate patches either.
Status: RESOLVED → REOPENED
Flags: firefox-backlog+
Resolution: INVALID → ---
It's a bad regression then! :-(

Will look into this as the first thing tomorrow.
Flags: needinfo?(paolo.mozmail)
I also definitely didn't test intermediate patches.
Detailed steps to verify:

* Create a new profile using a version older than the Nightly channel.
* Go to a site that asks for a password.
* Enter the password, then choose "Never remember password for this site" from the drop-down.
* Open the same profile in Nightly (with this patch applied).
* Open the preferences, select "Security", then "Exceptions" near "Remember Passwords for Sites".
* The name of the site for which passwords were disabled should appear there.
* Go to the same site, enter a password and ensure that the browser does not ask to save it.

Marco, this bug should be added to the current iteration.
Flags: needinfo?(mmucci)
Whiteboard: p=1 [qa+]
Added to Iteration 32.3
Status: REOPENED → NEW
Flags: needinfo?(mmucci)
Whiteboard: p=1 [qa+] → p=1 s=it-32c-31a-30b.3 [qa+]
Attached patch The patchSplinter Review
The issue was in the migration code - unfortunately I didn't update the disabled hosts import code to the new format. Sorry if I dismissed this bug initially, I thought I tested that case but I probably didn't after the latest changes.

I also added code to fix the broken JSON file, I tested it using the STR above but executing the broken Nightly before the fixed one, and it seems to fix the format as expected.
Attachment #8434174 - Flags: review?(dolske)
Status: NEW → ASSIGNED
Attachment #8434174 - Flags: review?(dolske) → review?(MattN+bmo)
Comment on attachment 8434174 [details] [diff] [review]
The patch

Review of attachment 8434174 [details] [diff] [review]:
-----------------------------------------------------------------

::: toolkit/components/passwordmgr/LoginStore.jsm
@@ +269,5 @@
>  
> +    // Due to bug 1019885, invalid data was created by the import process in
> +    // Nightly.  This automated procedure fixes the error.  This is provided as
> +    // a convenience to Nightly users and can be safely removed after Nightly
> +    // users are updated to the new version.

Followup bug to actually remove this?

Technically this should probably be a version bump, but I suppose it's fair to treat it as a temporary fix for a Nightly bug.
Attachment #8434174 - Flags: review?(MattN+bmo) → review+
Blocks: 1021031
https://hg.mozilla.org/mozilla-central/rev/275b8b4d30ec
Status: ASSIGNED → RESOLVED
Closed: 5 years ago5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
Hi Florin, can someone be assigned as the QA contact for verification of this bug.
Flags: needinfo?(florin.mezei)
Flags: needinfo?(florin.mezei)
QA Contact: andrei.vaida
Whiteboard: p=1 s=it-32c-31a-30b.3 [qa+] → p=1 s=33.1 [qa+]
I was able to confirm the fix for this issue on Nightly 33.0a1 (2014-06-10), using:
 * Windows 7 64-bit [1],
 * Ubuntu 14.04 LTS 32-bit [2],
 * Mac OS X 10.9.2 [3],
with the instructions available in Comment 7.

[1] Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
[2] Mozilla/5.0 (X11; Linux i686; rv:33.0) Gecko/20100101 Firefox/33.0
[3] Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Firefox/33.0
Status: RESOLVED → VERIFIED
Whiteboard: p=1 s=33.1 [qa+] → p=1 s=33.1 [qa!]
You need to log in before you can comment on or make changes to this bug.