User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040714 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040714 Mozilla and Netscape form manager utility incorectly enters street addres line1 into all street address lines on RFC3106 compliant web pages. Entries in street addresline2 and 3 are never entered into web forms. Line1 overwrites all street address entries. Reproducible: Always Steps to Reproduce: 1. Visit http://autofill.mozdev.org/autofilltest.html 2. Ensure you have data setup in Form manger to fill forms 3. Invoke form filling. Actual Results: Street address line1 is eneterd into all 3 address lines. Expected Results: line 1 line2 and line3 address info stored in form manager should be entered into the relevant fields on the web page form.
confirming, Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a3) Gecko/20040730 The Amazon Commerce Fields are showing correctly the 'Address Line 1' and 'Address Line 2' filled in from Primary Contact Information, the third isn´t asked for. The RFC3106 ECLM eCommerce fields are showing this bug 'ship to street line2' and 'ship to street line3' are showing the address from 'ship to street line1' bill and receipt street lines are showing the address of 'bill to street line1' The Prefill Form Data dialog is corrupt, also I can´t edit in Form Manager. Starting, as I never used Form Manager, I could enter pad1, pad2, pad3, sad1,sad2,sad3, bad1,bad2,bad3 into the addresslines, and it seemed they were shown correctly. When later on I tried to remove Sad2, bad2 was also removed. Things changed names, and so on, too complicated to describe now.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Created attachment 154906 [details] 10kb screenshot screenshot of Prefill Form Data is showing ShipTo.Street.Line.1 three times, and BillTo.Street.Line.1 six times, three times thereof I guess instead of ReceiptTo.Street.Line.1 .. Line.3 Related Bugs: Bug 253343 Form Manager info not being saved in Edit Form Info Bug 250502 form manager appears to store and retrieve data almost at random
broken in Mozilla 1.6, differently broken in Mozilla 1.4.2 the data from Prefill Form Data can be edited, and is transferred to the corresponding Location in the form on fill-in, i.e. the 3rd 'ShipTo.Street.Line1' goes to 'ship to street line3' Instead of editing, I also can select some other data, in line1 I get offered some other line 1 items, in line two some other line two items, useful for adresses, not at all usefull for phonenumbers, as I only get the different daytime numbers offered, not the cellphone, or the evening phone. Guess, that is another bug. Mozilla 1.6, 1.8a, Trunk: Edit Form Info: If only one category is open, and the others are collapsed, data can be edited and is retained. Open Category, edit, collapse category, open next one, edit .. is working. If you edit the ShipTo.Street.Line1 ..3 , and open Billto, the adresses from shipto are visible. If you edit these, while ShipTo is not collapsed, these changes also are made in Shipto. Mozilla 1.4.2: Edit Form Info: Data can be freely edited, when you change from ShipTo to BillTo, the shipto addresses stay for a second, and then get replaced by the BillTo adresses, or an empty field, if there are none.
Severity: normal → major
requesting blocking 1.7.3, maybe it could be fixed in time for Netscape 7.2
1.7.5 has shipped. Moving request to 1.7.6.
Flags: blocking1.7.5? → blocking1.7.6?
Not going to hold 1.7.6 for this. minus.
Flags: blocking1.7.6? → blocking1.7.6-
Does someone use Form Manager while this bug is still seen? See also Bug 194706 form manager mixes up data from to different input fields if label on html page starts with the same word Bug 198661 Form Manager shows & assigns incorrect names for fields Bug 253343 Form Manager info not being saved in Edit Form Info
Not blocking 1.0a - this bug is not a recent or severe regression.
Flags: blocking-seamonkey1.0a? → blocking-seamonkey1.0a-
Component: Form Manager → Form Manager
Product: Core → Toolkit
QA Contact: form.manager
This code / UI no longer exists.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.