Closed Bug 1230872 Opened 7 years ago Closed 7 years ago

Wrong value from datalist inserted when using input with autocomplete=on

Categories

(Toolkit :: Autocomplete, defect)

42 Branch
x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla44

People

(Reporter: bugzzilla, Unassigned)

References

Details

(Keywords: regression, testcase)

Attachments

(3 files)

Attached file autocomplete.html
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0
Build ID: 20151029151421

Steps to reproduce:

Have an <input> with type=text an autocomplete=on (or default) and associated <datalist>. I type some letters to narrow down the autocomplete list, then I select one of the items from the datalist with the mouse or the keyboard.

There have to be a few items in the input history of the form. With only the items from the datalist there is no problem.

Workaround: set autocomplete=off to restrict input history to datalist.

Example attached.


Actual results:

Some empty items are displayed at the top of the list, after typing the initial letters. Wrong option from datalist is inserted into the <input> element.


Expected results:

Selected option should have been inserted.
OS: Unspecified → Windows 7
Hardware: Unspecified → x86_64
Attached image screeshot.png
Component: Untriaged → Layout: Form Controls
Product: Firefox → Core
I tried with my current profile, I see some blank items when typing some letters (like "and" or "ama") but I can't reproduce it with a fresh/different profile.

Could you attach a screenshot of the empty items at the top of the list, please.
Is it reproducible with a fresh profile?
Flags: needinfo?(bugzzilla)
Attached image Screenshot
Flags: needinfo?(bugzzilla)
The problem does not happen with a new profile. This is just what I'd expect, because with a new profile you don't have an input history for the form. That's just like using autocomplete=off, as mentioned above.

The bigger problem for me is not the empty lines, but that the wrong text is entered into the input field when you select one of the non-empty lines. That makes the whole autocomplete feature useless.
Additional observation:

If you type in letters, then switch to a different window, then go back to the input field, the autocomplete list is displayed correctly. The formerly empty lines are then the input history, followed by the datalist items. Also, selecting an item from the list then enters the correct text.

So the Problem only appears when you type in new letters while the input field has the focus (i.e. the drop-down list is re-generated) and you have an input history besides the datalist.
Component: Layout: Form Controls → Autocomplete
Keywords: testcase
Product: Core → Toolkit
Supposing this is a regression, it would be nice to get a regression range.

I just tried in Nightly on my Mac but I am unable to reproduce, so far. Would you mind checking if thisi s reproducible in Firefox 43 Beta?
Could you please provide steps to reproduce the bug starting from a fresh profile?
just to keep this on my radar.
Flags: needinfo?(mak77)
Marco, where are stored history entries from input fields? places.sqlites?

If I know that, I'll copy the storage file and test with a custom profile and mozreg.
formhistory.sqlite
I tested different builds (Release, Beta, Aurora, Nightly) with the formhistory.sqlite from my current profile showing the issue and only Nightly doesn't reproduce the issue.
So I tested with mozregeression to find a working range and it appears it has been recently fixed by Bug 720589:
https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=73f07190af6de7bc7f8da17541814e05b5571759&tochange=432bea2c0c685740470dd5e1e25dd90ecba395c1

Reporter, can you download Nightly (see https://nightly.mozilla.org/), create a new profile and copy formhistory.sqlite from your current profile to this new profile then load it with Nightly to test if it's fixed on your side too.

.
Flags: needinfo?(bugzzilla)
Thank you for the regression hunting, much appreciated.
We plan to uplift the fix to 44, so I will immediately start that process.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(mak77)
Depends on: 720589
Can't recreate the problem with Nightly, so it seems to have the correct fix.
Flags: needinfo?(bugzzilla)
I can reproduce the problem on Firefox41 to Aurora44.0a2.
However, I cannot reproduce on Firefox40 and Nightly45.0a1.

STR
1. Disable e10s
2. Open testcase and type 'and' + ENTER  (without quotation marks)
3. (optionally) Open testcase and type 'andy' + ENTER

4. Open testcase again
5. Type 'and'



Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e5738a6a2678&tochange=29ac9cb43e83

Suspect: Bug 1162329



And Fixed window:
https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=73f07190af6de7bc7f8da17541814e05b5571759&tochange=432bea2c0c685740470dd5e1e25dd90ecba395c1

Fixed by: 432bea2c0c68	Marco Bonardo — Bug 720589 - mMatchCounts may be accessed with a nonexisting index. r=neil
Fixed by Bug 720589
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
You need to log in before you can comment on or make changes to this bug.