1060845 - In search field of about:home and about:newtab, form history is lost when updated browser from Firefox32 to Aurora33/Nightly34

Status: RESOLVED WONTFIX

(Firefox :: Search, defect)

Description

[Alice0775 White]

[Tracking Requested - why for this release]:

[Tracking Requested - why for this release]:

Steps To Reproduce:
1. Start Firefox32
2. Open about:home and search from search filed
3. Repeat step2 several times

4. Open about:home, focus search filed and press downarrow key
   --- form history dropdown pops up

5. Start Aurora33.0a2/Nightly34.0a1 with the same profile
6. Open about:home, focus search filed and press downarrow key
   --- nothing pops up, form history is lost

Comment 1

[Alice0775 White]

Regression window(m-c)
Good:
https://hg.mozilla.org/mozilla-central/rev/6551323d96e6
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140801134649
Bad:
https://hg.mozilla.org/mozilla-central/rev/eed9fe35a00d
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140830030204
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6551323d96e6&tochange=eed9fe35a00d


Regression window(fx)
Good:
https://hg.mozilla.org/integration/fx-team/rev/f08fb8275e5b
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140801112450
Bad:
https://hg.mozilla.org/integration/fx-team/rev/fe53a2b0e7d0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140801120154
Pushlog:
http://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=f08fb8275e5b&tochange=fe53a2b0e7d0

Regressed by: Bug 612453 and Bug 1028985

Comment 2

[Sylvestre Ledru [:Sylvestre]]

Tracking because we are doing a lot on this topic in the 33 release and we want something clean.

Drew, can you help us here?

Comment 3

[Drew Willcoxon :adw]

Philipp, this seems partly like a UX question; do you have any thoughts?

The problem is that we're using a different key to store about:home/newtab form history starting in 33, due to bug 612453 and bug 1028985.  Your old form history from the inputs on about:home/newtab is lost in the sense that you can no longer access it from about:home/newtab, but it's still in the form history database.

The old key was "q", the new key is "searchbar-history", which is the same as the key used to store form history in the main chrome search bar, which means that about:home/newtab form history is shared with the search bar's starting in 33.

Mike made the change in his original patches and I'm guessing it was purposeful so that the form history of all the browser's search access points matches up, which makes sense.

I think the options are:

1. Change back to the old key
2. On upgrade to 33, copy history from the old key to the new key
3. Don't do anything, so that old history appears lost

2 seems like a nice option at first, but the potential problem is that the database doesn't know the difference between the "q" key used in about:home/newtab and the "q" key used by any random web page.  So doing 2 would mean that form history attached to random sites at the time of upgrade to 33 would now start appearing in the main chrome search bar, where it didn't before.

Comment 4

[Drew Willcoxon :adw]

I found bug 1007988, which indicates intent, but it doesn't say what should happen to existing form history.

Comment 5

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

I'm not sure I understand the technical limitations.

If a user has used the search field on about:home prior to updating and therefore has form history associated with that field, that history should also show up after the upgrade.

How does Firefox currently (before updating) make sure that my search history from that field doesn't show up in, for example, any bugzilla form field?

Comment 6

[Drew Willcoxon :adw]

(In reply to Philipp Sackl [:phlsa] from comment #5)
> I'm not sure I understand the technical limitations.

The form history databases is effectively a simple key-value store that doesn't contain any information about where form history came from.  There's no way to tell after the fact whether history that looks like it may have come from about:home/newtab actually came from there and not some random web page.

> If a user has used the search field on about:home prior to updating and
> therefore has form history associated with that field, that history should
> also show up after the upgrade.

That leaves options 1 and 2.  Option 1 means that the form history in about:home/newtab won't match the form history of the main chrome search bar, which is contrary to bug 1007988.  That's the status quo as of 32.  Option 2 means that some form history attached to random pages at the time of upgrade to 33 would now start appearing in the main chrome search bar, where it didn't before.

> How does Firefox currently (before updating) make sure that my search
> history from that field doesn't show up in, for example, any bugzilla form
> field?

It doesn't!  If two inputs have the same value for the name attribute, then they'll share the same form history.  Even for inputs "in the browser" like about:home/newtab's prior to 33.

The one exception is the main chrome search bar form history, which we don't want to appear on web pages.  We actually hardcode some checks for that, which is pretty bad:

http://mxr.mozilla.org/mozilla-central/source/toolkit/components/satchel/nsFormAutoComplete.js?rev=fb57f323afdc#171
http://mxr.mozilla.org/mozilla-central/source/toolkit/components/satchel/formSubmitListener.js?rev=67e9e1fd1b6d#157

Comment 7

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Thanks for the clarification!

Since it will be harder (if not impossible) for the user to remove unwanted results than it will be to recreate the ones that aren't there anymore, forgetting the suggestions on update seems to be the best solution.

If I'm not mistaken that means that this bug is a wontfix.

Comment 8

[:Gavin Sharp [email: [e-mail]]]

I concur!