450419 - OmniWeb's "Passwords not saved" placeholder isn't ignored as an account

Status: RESOLVED FIXED

(Camino Graveyard :: OS Integration, defect)

Description

[Greg. Dodwell]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.16) Gecko/20080803 Camino/1.6.3 (like Firefox/2.0.0.16)
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.16) Gecko/20080803 Camino/1.6.3 (like Firefox/2.0.0.16)

Saved form details (Keychain) are sometimes "remembered" for Gmail, sometimes not.

A. When failing, "Username" form shows "Passwords not saved". When this dialogue is deleted, and the first letter of my username is typed, my username and password both instantly appear in each correct dialogue box.

B. Otherwise, Username and Password both appear as expected.

About 50/50 whether A. or B. happens 

Reproducible: Sometimes

Steps to Reproduce:
1.Click on G mail bookmark icon in bookmark toolbar
2.Google Mail front page appears with login forms
3.
Actual Results:  
"Passowords not saved" in Username form box. Password form box empty. Delete the "Passwords not saved" dialogue, type in first letter of Username in the Username form box, correct Username appears in Username box, correct Password in Password box.

Expected Results:  
Correct Username and Password should appear in the right dialogue box within a couple of seconds.

Correct behavior about 40 - 50 percent of the time ...

Comment 1

[Stuart Morgan]

Hrm, that sounds like we are picking up the password-block marker from Safari, which we are supposed to screen out. I assume you've told Safari not to remember passwords on mail.google.com?

If you open Keychain Access (in /Applications/Utilities) and search for "saved", there will be an entry called something like "mail.google.com (Passwords not saved)". If you open that entry, and click "Show password", what is there (if it's a real password you use, just say that; no need to share actual password data)? We screen those entries out by looking for a password of " ", which is all I've ever seen Safari use, but it sounds like there may be another marker we need to look for.

What is your Mac OS X version, by the way?

Comment 2

[Stuart Morgan]

It turns out Safari doesn't localize that string (go Safari!), so if nothing else I'll blacklist that account name.

Comment 3

[Stuart Morgan]

Greg, in the future please post replies in bugzilla, rather than replying by private mail.

The problem is that OmniWeb uses "" as the password for those entries, rather than " " as Safari does (and they also don't set the keychain item flag that is there explicitly to identify this kind of item; sigh).

Comment 4

[Stuart Morgan]

Attachment: fix

Since it's not necessarily obvious: the reason I'm removing the first check rather than replacing it with the new isNonEntry is that it was a lookup from Keychain by username; there's no way we'll get one of these non-entries that way.

(And for the curious, A0 is non-breaking space. I guess they wanted to make extra sure not to collide with a real username?)

Comment 5

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 333699 [details] [diff] [review]
fix

sr=pink

maybe describe the "" v. " " (Omniweb v. Safari) difference in a comment so we don't forget about it and assume we can simplify to one or the other down the road?

Comment 6

[Stuart Morgan]

Landed on trunk and MOZILLA_1_8_BRANCH, with expanded comment about why we do it the new way.