896142 - Drop-down list of form offers the same item twice

Status: VERIFIED FIXED

(Toolkit :: Form Manager, defect)

Description

[Dan Jacobson]

Attachment: twice.png

User Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20130705 Firefox/24.0 Iceweasel/24.0a2 (Nightly/Aurora)
Build ID: 20130705004019

Steps to reproduce:

Filled in a form.


Actual results:

Was offered the same item twice.


Expected results:

Offer it only once please.


No don't ask me how to reproduce it!

Comment 1

[Loic]

Stop using broken website! :P

If we can't reproduce it, it will hard to fix it...

Comment 2

[Andre Klapper]

Needs way better and clear steps to reproduce. Cannot reproduce with "any" website.

Comment 3

[Dan Jacobson]

I don't know how it got in there,
and I tried to reproduce it by adding a trailing blank,
but apparently those are snipped so not a cause of it.

So all I can say is "examine the code to see the possible ways this could have happened." which is of course also difficult.

Comment 4

[[:philipp]]

there are similar reports by other users - it apparently started after the firefox 23 update:
https://support.mozilla.org/en-US/questions/967159
http://www.camp-firefox.de/forum/viewtopic.php?f=1&t=104661

no clear steps to reproduce it yet though...

Comment 5

[Ethan]

This problem is reproducible on MacOS X 10.6.8, Windows XP, and Windows 7.  All with 23.0.1 RELEASE.  I can reproduce reliably with new profile, or with clean formhistory.sqlite.

Please follow this path and you should be able to replicate the problem:

1) Clean profile.
2) Open FF and go to http://dnr.alaska.gov/ssd/recoff/sag/PlatSearchMenu.cfm
3) Enter '71-33' in PLAT, '3' in LOT, '1' in BLOCK.  Hit submit (or enter).
4) results page loads, click the 'Plat Number Search" link above the results (this returns you to the original page).
5) Enter '71-33' in PLAT again, you will see a single entry appear.  Enter '3' for LOT, and '1' for BLOCK just as before, you will see single entries remembered.  Everything looks NORMAL at this stage.  Submit the form.
6) results page loads again, click the 'Plat Number Search' link again to return back to the original form.
7) Click the PLAT entry and hit down arrow, or type in a '7', you will see 71-33 is now listed twice.  LOT also has duplicate entries for '3'.  The BLOCK entry is unaffected, it will only contain one entry for '1'.  
8) You can reproduce this again with different values, start at step 1 and use '82-251' for PLAT and '22' for LOT, and '1' for BLOCK.  At the end you should end up with duplicate entries for both 82-251 and 71-33, as well as 3 and 22.

Please note that there is more going on that I have observed using an existing profile.  In my existing profile I attempted to cleanup the duplicate entries, sometimes this results in all entries of '71-33' being removed, and they will not re-appear so long as duplicate data for 82-251 (or anything else) still exists.  I tried activating the formhistory debug option in about:config, the error console starts showing messages about duplicate entries being detected.  

Nearly all websites seem to trigger this error, but not ALL form fields do.  In my example above the BLOCK field never seems to get duplicate entries.

Comment 6

[[:philipp]]

thanks for reporting steps to reproduce the issue...

with the mozregression tool i found the following regression range, though i'm not technically advanced enough to pinpoint it to one of the specific changes:

Last good nightly: 2013-05-11
First bad nightly: 2013-05-12

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2013-05-11&enddate=2
013-05-12

Comment 7

[[:philipp]]

http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2013-05-11&enddate=2013-05-12

Comment 8

[Sören Hentzschel]

Attachment: three times the same item

three times the same item. screenshot taken from https://www.viewtrip.com/VTHome.aspx

Comment 9

[Loic]

Attachment: 896142.html (reduced testcase)

Regression confirmed with a reduced testcase.
Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=179e29a23c56&tochange=d68224f5325b

STR:
1) Enter "1" into field #1 and "2" into field #2 then submit.
2) Enter "1" into field #1 and "2" into field #2 then submit.
3) Double click in the field #1 (or use the down arrow)

Result: "1" is displayed twice in the drop-down list.

You need to enter something into the field #2 to repro the issue. Filling only field #1 is not enough.

Comment 10

[Loic]

Maybe bug 828312?

Comment 11

[Alice0775 White]

Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/7f4e7df5a393
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20130509 Firefox/23.0 ID:20130509205044
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/a53678fdc4bb
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20130509 Firefox/23.0 ID:20130509232646
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=7f4e7df5a393&tochange=a53678fdc4bb

Regressed by: Bug 566746

Comment 12

[bhavana bajaj [:bajaj]]

Needinfo request to understand https://bugzilla.mozilla.org/show_bug.cgi?id=909357#c2 .

Comment 13

[lacroixr44]

For the persons who worked on this BUG

I am using NOW Firefox 24.0b4 instead of FF23

My two problem as described in another topic (Firefox is saving limited form date (2 entries) and none on some lines, all settings are set to save form data) DISAPPEAR.

Two problem
The first problem :long time forts the first connection.
The second problem (memorization of some fields in forms) is still present but randomly : some fields are memorize twice, some not at all. All the the field identified as a password are correctly memorize. 

It is correct now.

Thanks for theses corrections.

Comment 14

[Neil Deakin]

Attachment: fix double entries, test not working yet

Comment 15

[lacroixr44]

HI
In fact I was WRONG in my first message.
With FF24.0b4, I still have theses two problems:
   1- some fields are twice
   2- and some fields in the the same form are not memorize.

Sorry for this very short happiness.
Thank to the persons who work on this bug

Comment 16

[Lukas Blakk [:lsblakk] use ?needinfo]

We have STR now and a WIP patch so hopefully will be able to fix this 23 regression in 24 and beyond.

Comment 17

[Neil Deakin]

Attachment: Cache the change object to update, otherwise the last one gets used for each item

Comment 18

[Mark Hammond [:markh] [:mhammond]]

Comment on attachment 795991 [details] [diff] [review]
Cache the change object to update, otherwise the last one gets used for each item

Review of attachment 795991 [details] [diff] [review]:
-----------------------------------------------------------------

::: toolkit/components/satchel/test/unit/test_history_api.js
@@ +394,5 @@
> +  yield promiseUpdate([
> +                       { op : "bump", fieldname: "field5", value: "value5" },
> +                       { op : "bump", fieldname: "field6", value: "value6" }]);
> +  results = yield promiseSearchEntries(["fieldname", "timesUsed", "firstUsed", "lastUsed"], { });
> +  

nit: trailing whitespace

Comment 19

[Neil Deakin]

https://hg.mozilla.org/integration/mozilla-inbound/rev/1eacd8262e0f

Comment 20

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/1eacd8262e0f

Comment 21

[Ethan]

Is this fix going to be merged into FF 24?  This bug is really disruptive and I would rather not have to put up with it until December...

Comment 22

[Mark Hammond [:markh] [:mhammond]]

Comment on attachment 795991 [details] [diff] [review]
Cache the change object to update, otherwise the last one gets used for each item

I think the patch is low enough risk and the problem large enough that we should uplift.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 566746
User impact if declined: Users will continue to see duplicate items in form fill dropdowns.
Testing completed (on m-c, etc.): Landed on m-c, patch includes tests.
Risk to taking this patch (and alternatives if risky): Low risk patch
String or IDL/UUID changes made by this patch: None

Comment 23

[Ethan]

(In reply to Mark Hammond (:markh) from comment #22)
> Comment on attachment 795991 [details] [diff] [review]
> Cache the change object to update, otherwise the last one gets used for each
> item
> 
> I think the patch is low enough risk and the problem large enough that we
> should uplift.
> 
> [Approval Request Comment]
> Bug caused by (feature/regressing bug #): 566746
> User impact if declined: Users will continue to see duplicate items in form
> fill dropdowns.
> Testing completed (on m-c, etc.): Landed on m-c, patch includes tests.
> Risk to taking this patch (and alternatives if risky): Low risk patch
> String or IDL/UUID changes made by this patch: None

Additionally, in many cases new form history data is NOT saved due to the duplicate data being present.  This aspect makes the problem even more disruptive.  In short this is not just a cosmetic issue.

Comment 24

[bhavana bajaj [:bajaj]]

Comment on attachment 795991 [details] [diff] [review]
Cache the change object to update, otherwise the last one gets used for each item

Given the low risk here I am approving the patch for our second last beta going to build tomorrow.Please make sure to have this checked in by then.

Comment 25

[Ryan VanderMeulen [:RyanVM]]

Looks like Neil pushed this to beta a few hours ago. Neil, were you going to push this to Aurora too?

https://hg.mozilla.org/releases/mozilla-beta/rev/42b3fc6937e7

Comment 26

[Ryan VanderMeulen [:RyanVM]]

Allow me...

https://hg.mozilla.org/releases/mozilla-aurora/rev/acc893e11f2b

Comment 27

[Neil Deakin]

Yes, thanks. I had to leave before doing so.

Comment 28

[Ray Satiro]

I exported my form history using form history control, exited firefox, deleted formhistory.sqlite, started firefox and imported form history. It removed 99 duplicates. Several hours later and I have a duplicate again in field 'email'. I'm using the latest Aurora.

gecko.mstone = 25.0a2
gecko.buildID = 20130910004002

Comment 29

[Tracy Walker [:tracy]]

Ray,  thank you for the follow up.  However, this particular bug is fixed. What you are seeing is likely a different manifestation of form item duplication. Please file a new bug with detailed reproducible steps to cause the bug.  

I haven't used the Form History Control add-on. Can you delete the duplicate in the email field using shift+alt(cmd on mac)+delete while highlighting the duplicate entry?  Then check to see if the duplication reappears in the field in question?   Also can you reproduce your issue with the Form control addon disabled?

Thanks again.

Comment 30

[Ray Satiro]

(In reply to Tracy Walker [:tracy] from comment #29)
> Ray,  thank you for the follow up.  However, this particular bug is fixed.
> What you are seeing is likely a different manifestation of form item
> duplication. Please file a new bug with detailed reproducible steps to cause
> the bug.  
> 
> I haven't used the Form History Control add-on. Can you delete the duplicate
> in the email field using shift+alt(cmd on mac)+delete while highlighting the
> duplicate entry?  Then check to see if the duplication reappears in the
> field in question?   Also can you reproduce your issue with the Form control
> addon disabled?

I don't have steps to reproduce but I filed bug 915500. I tried what you suggested to remove a duplicate entry on one of the entries and it removed both. I will try with Form History Control disabled as soon as I can.