I've been doing work on the FM][ backend recently in Mozilla. The problem is that when I change some values in a form, and click [Update], Mozilla will pester me with "Remember values in this form? [Yes] [Never for this site] [No]" .. However, despite continued clicks of [Never for this site], Mozilla continues to pester me each and every time I submit a form. I think it is because form manager uses the URL instead of just the base site name as a means for determining if it's supposed to fill out these forms. This mis-leading UI wording is VERY VERY frustrating. An example of the form is on http://web.thock.com/mozilla/form_bug.html
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is working fine for me on win32. tpreston, can you test this on linux and let me know if you can reproduce the failure. One thing that puzzles me is that the reporter mentions two different URL's -- one in the URL field at the top of the bug report and one in the description of the bug. The one in the URL field has nothing to do with form manger -- that one invokes password manager. The one in the description field indeed invokes form manager. But in both cases, if I click the "never" button, the next time I submit the form I do not get the do-you-want-to-save message.
It's the form manager which bothers me. When I click [Never for this site], I except that it will never pester me for site whose base hostname is "FRESHMEAT.NET" .. this is not the case. Instead it merely ads another FM autogenerated URL (like freshmeat.net/admin/34234/12/) to a small file somewhere. Since each different op on this page changes the next URL (as almost all data is stored in a URL hash), I am contiously pestered. This is bad UI design. Mozilla really SHOULD Never pester you for any forms on a website if you say [NEVER for this site]... not just turn around and pester you for forms with different URLs on the same site.
I'm still confused. You mention the URL freshmeat.net and say it is form manager. But that url contains a username/password field so the password manager gets invoked, not the form manager. Regardless of semantics, this is still working for me. When I click on never, the entry made in the password-manager dialog says that you will never be asked to save a login for "freshmeat.net". Furthermore, you are now at freshmeat.net/login and if you fill out that form and submit it, you indeed do not get the do-you-want-to-save dialog. Now if indeed there was some site that kept sending you to different hosts (not simply different paths) as you described, then what you are describing would be correct. I don't know what I can do about that. How would you go about defining the domain for which things should be rejected. And don't tell me "everything before the .com" because that doesn't work for url's like a.b.co.nz. Further complication comes about when different hosts in the same domain are actually different sites. For example, a site might allow different companies or individuals to put up their webpages under that sites domain. Now if you say never for one of these webpages, you don't want it to apply to the other webpages in that same domain. So per your latest description of the bug (not from the behavior at the URL you provided), I have to mark this as wont-fix because I don't know how to fix it.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WONTFIX
An example of the KIND OF forms I deal with, as a freshmeat admin, is on web.thock.com (as I wrote in my initial report). Now, if you want to see how my form manager data looks like after clicking NEVER FOR THIS SITE several times while working on Freshmeat, go load http://web.thock.com/mozilla/buggy_forms.png There you see how, despite the wording "FOR THIS SITE," I get pestered FOR THE SAME SITE. Either change the wording to "NEVER FOR THIS URL," or change the behaviour to actually exclude the site! (basehostname & port number would seem to be the sanest way of doing that) This is **NOT** the login manager -- it's just that you don't have access to the freshmeat admin backend (where the issue lies). The issues is your form manager and poor choice of words.
Status: RESOLVED → VERIFIED
This is indeed bug 63271 dupage. "a) you had provided a testcase people can actually test cases with" Sorry, I couldn't do that because of work (at the time) and because I couldn't just hand out access to FM :) "b) you didn't shout all the time" Yeah, I can't unsay things -- I acknowledge my comments weren't exactly helpful. I was very frustrated by this because I'd have to deal with several dialogs a minute in some cases. Especially with sleep deprivation I was going through at the time it was a very unpleasant experience. Thankfully it's over for now.
Component: Form Manager → Form Manager
Product: Core → Toolkit
QA Contact: tpreston → form.manager
You need to log in before you can comment on or make changes to this bug.