Using: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5b) Gecko/20030827 To reproduce: 1) Open: http://www.thebulkclub.com/powerofnumbers.asp 2) In the form field labeled "# Emails Sent", highlight all chars and hit delete 3) Double click in the same form field results: The users email address is pasted into the field expected results: Nothing is pasted into the field. Now ignore the fact for a moment that this is a UCE vendors site. If I'm trying to highlight all chars in a field by double clicking, I certainly don't want my email address to be pasted into the field. If I accidentally submitted the form, my email would be posted to the script for the form. If this is a "works as designed", I *really* don't like it.
Created attachment 130806 [details] bulkmail_bug.html Adding test case distilled from original bulkmail_bug.html -jim
My bad. The instructions for the testcase weren't clear. To reproduce with the above testcase: 1) Highlight all chars in the field labeled "test 1" 2) Hit delete 3) Double (or triple) click on the same blank form field results: email address appears in form field. expected results: Nothing is inserted into form field
Unable to reproduce with the latest trunk build on windows XP.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031217 Confirmed. I see this as expected behaviour, and form fill tool is doing it's job with double click on input box.
Yes. Field is named Emails. Form manager is invoked on doubleclick, fills out with what it has collected as default Primary Contact email address. Disable form manager if this is a problem. Form manager doesn't initially fill out because a default value exists.
Created attachment 137623 [details] testcase, probably not quite minimal but close Testcase seems to show bug dependent on the word email in the title and <input type="text">
Ok, there's "email" in the page title of the first attached testcase. If you remove this word from the title, it does NOT fill the field anymore. Naming of the fields does not matter; I exchanged the first two fields and it still filled the first one doing the equivalent steps, did not fill the second. Possibly dangerous? If there is "credit card" or something in the title fields might tend to be filled accordingly...
re my last comment 6 : The input type simply cannot be anything other than text--if it's unspecified then the bug still appears.
Created attachment 137624 [details] Minimal testcase <html><head><title>email</title></head><body><input type="text"></body></html> is all that is needed to reproduce the bug.
Oops, that last comment/testcase still has type="text" - it's unneeded, but doesn't change the bug. Sorry for the spam.
It doesn't make sense for Form manager to reach all the way back to the title for context in trying to fill the field, so it's a bug, but merely lame, not evil. The original bulkmail page worked as intended since the word "email" was gleaned in nearby context as the best guess.
Created attachment 137681 [details] Credit Card from Form Manager This one pulls the Credit Card number if a user has one in Form Manager.
To reproduce with the credit card attachment: http://bugzilla.mozilla.org/attachment.cgi?id=137681&action=view 1) Add a fake credit card to Form Manager 2) Follow the steps in comment #2 results: Card Number is pasted into field. Note that this example has a simple trick to "hide" the title info by adding a long string of periods. I'm still playing with hidden form fields and doubleclick events. I should get a real job. :/
Jim, <title> is a red herring: even assuming Form Manager didn't walk back as far as the title a malicious page could still play games with you. Once you have a form manager that fills fields without user confirmation using data originally entered on another site we've got issues. Leave aside ways you could fool the algorithm with text hidden in an invisible <span> or in the title, a straightforward form correctly labelled with the data the page wants exhibits all of the potential pitfalls here. There is already bug 63320 to change the double-clicking behavior, which IMHO is the user surprise and possible privacy leak issue. I'll modify this bug to cover wallet looking back too far for context. I remember morse mentioning pages that broke if he limited the context to the form itself, but surely we can think of some better limit than reaching all the way back into the <title>
Andreas, I haven't yet been able to successfully add wallet data to a hidden form field via a doubleclick (onclick="doubleclickVar.onClick()) type event but I'm no coder, just a QA guy. My tests to date have been with something akin to a "this paged has moved, click here to continue" that triggers a double-click. I do agree with Dan that the whole double-click deal has many rather thought provoking (and touchy) issues after reading bug 63320. The unfortunate thing is that bug has had no movement in some time. I just worry a bit that this might be something latent no one has exploited yet. That being said, Dan was far more level headed than I when I worked with him at NSCP, so I'll defer to his judgement.
Andreas: Wallet explicitly skips hidden fields -- no worries there. First there's the obvious privacy issues of sending information the user hasn't seen or approved, and second, since wallet is intended to help people it should only do what a user could do and a user can't fill a hidden field. Thanks for the kind words, Jim. I'm more of a "stuckee" than an owner for Form and Password manager so I'm not sure I'll be able to help much here. I do, however, find myself with a bit more time on my hands than I expected, unfortunately.
Filter on "Nobody_NScomTLD_20080620"
Wallet is dead, and password manager does not have this problem.