Closed Bug 93972 Opened 25 years ago Closed 24 years ago

autocomplete="off" should stop session history from re-filling forms

Categories

(Core :: Layout: Form Controls, defect, P3)

Product:
Core
Component:
Layout: Form Controls
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.5

People

(Reporter: arun, Assigned: pollmann)

Details

(Keywords: topembed)

Attachments

(6 files)

patch 1: don't store form value in SH if autocomplete='off'
738 bytes, patch
Details | Diff | Splinter Review
patch 2: look for autocomplete='off' on both input and containing form
1.28 KB, patch
Details | Diff | Splinter Review
patch 3: Same as 2, but do a case-insensitive comparison
1.53 KB, patch
Details | Diff | Splinter Review
patch 4: merge two checks for autocomplete attr to one method (per jst's sr)
1.68 KB, patch
Details | Diff | Splinter Review
test case, last two input should not store value when leaving, then using 'back' to return to page
462 bytes, text/html
Details
Wallet Patch 1: Make wallet look for autocomplete attribute.
2.94 KB, patch
Details | Diff | Splinter Review
Currently, the attribute autocomplete="off" can be applied to prevent Password Manager from filling in passwords that it stores. However, it should be applicable to form elements beyond the scope of wallet. In general, it should completely prevent Form Manager from filling in values from Session History if applied to *any* form element -- both from within the <form> tag or from within any input tag inside the form tag (any child node of the form tag).
Nominating topembed and nsenterprise. Also, this is where the spec. that Microsoft wrote resides: http://msdn.microsoft.com/library/default.asp?url=/workshop/author/forms/autocomplete_ovr.asp Scroll down to about 2/3 of the way and you'll see what MS recommends for autocomplete. I'm *very keen* on seeing this addressed, and hopefully can convince folks in NSCP CPM of this need :-) IMHO, this ought to be simple, since morse put in a fix for autocomplete="off" already.
Keywords: nsBranch, nsenterprise, topembed
I'm very confused. Form manager never fills in values from session history. Can you give a concrete example of what you are referring to.
This bug does not belong to form manager -> HTML forms, which is where the saving/restoring is done.
Assignee: morse → rods
Component: Form Manager → HTML Form Controls
QA Contact: tpreston → madhur
bbaetz, thanks for reassigning new component correctly. morse, you'll find that reading bug 93027 will be instructive -- it will shed light on the thinking behind this bug. you could perhaps help this bug along a lot, since it was your patch that got some autocomplete="off" functionality working in the first place.
Summary: autocomplete="off" should work beyond password manager/wallet → autocomplete="off" should stop session history from re-filling forms
Eric, I think this is more or less yours, if not, send it back. Or if you are swamped with topembed bugs.
Assignee: rods → pollmann
Marek, Just like Bug 93027 , this bug, too, should be given topembed+ permission for branch check in (0.9.2). These two bugs are "cognates", and are important check ins!
assuming that madhur@netscape.com verifies the fix on the trunk and you don't see any major regressions for a day, please check it into 0.9.2
sr=jst
r/sr=vidur
Fix checked in to the trunk. Marking FIXED and vtrunk to trigger verification.
Status: NEW → RESOLVED
Closed: 24 years ago
Keywords: vtrunk
Resolution: --- → FIXED
Target Milestone: --- → mozilla0.9.4
madhur@netscape.com, could you verify the fix on the trunk? when this is done pollmann@netscape.com will be able to check-into 0.9.2 branch.
will verify on trunk as soon as sweetlou is up and running.
verified this on window 2000 - build id : 2001-08-17-06trunk. The autocomplete="off" attribute is working as desired from both the form tag as well as the input tag. Marking it verified fixed. Can be checked-into 0.9.2 branch. Removing vtrunk keyword.
Status: RESOLVED → VERIFIED
Keywords: vtrunk
Checked into the branch, thanks!
If the password is already present in the password file, I'm pretty sure that any field with autocomplete=off is autoprefilled. The patch applied only disables the saving of the passwords but doesnt fix the actual autoprefill of forms/input with autocompete=off. That would be correct solution! Using a old profil of Mozilla, Mozilla still prefills my autocomplte=off form! But a new profile doesn't.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
I did notice that, and thought that I had filed a bug. I can't find it now, though.
Eric is no longer here . . . ---> Kevin
Assignee: pollmann → kmcclusk
Status: REOPENED → NEW
Target Milestone: mozilla0.9.4 → mozilla0.9.5
I'll take this.
Assignee: kmcclusk → kin
In the text widget, there is no way to tell if the value is being set via the password manager or by some other means. So I just attatched a patch that makes wallet check for the autocomplete attribute. Let me know if this is ok?
Status: NEW → ASSIGNED
This bug sure has morphed. It started out as a problem with session history which was fixed. The bug should have been closed at that point and a new bug opened on password manager if that is now of concern. Gemal statemant is accurate. If you have an old profile for which a username/password has been saved for a field having autocomplete=no, then you will get a prefill when you return to that page. But it's got to be a profile that predates the implementation of autocomplete=no on the save side. Furthermore, sites that were concerned with passwords being saved (i.e., those that went to the trouble of adding the autocomplete attribute) were also ones that didn't allow N6 users in the first place. They did version sniffing and blocked N6 users from using their site (e.g., Wells Fargo). So based on that, I don't see how a user could ever have saved a login for such a site in the first place. The only way to demonstrate this problem is with a hypothetical site set up just for the purpose of making this problem visible. Therefore my recommendation as module owner would be not to include this patch and close the report out as WONT-FIX. Otherwise we are just adding lines of unnecessar code to bloat the product.
Wish something was said about this earlier. :-) I agree with morse. Rather than mark this bug as WONTFIX, I'm going to reassign it back to pollmann@netscape.com and mark it FIXED since he fixed the original reported bug.
Assignee: kin → pollmann
Status: ASSIGNED → NEW
Resolving bug as FIXED based on comments above.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Priority: -- → P3
Resolution: --- → FIXED
That's exactly why I'm against morphing bugs. The bug as stated is indeed fixed. The bug as morphed is wont-fix. You just can't win. :-(
Actually there's already a bug for the morphed behavior that is described here. That bug is bug 95351
verifing bug based on the above comments.
Status: RESOLVED → VERIFIED
I really wish there was a way to tell Mozilla to IGNORE the autocomplete=off attribute! Sites like salomonsmithbarney.com and etrade.com are now using this "feature," and all it does is prevent me from using Mozilla the way I would like. Why should a website get to decide if I want to save my password locally or not?
no_spam@winzig.com: see comments 11-14 on bug 124065.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: