Closed Bug 553577 Opened 10 years ago Closed 9 years ago

failure to save searches to form history breaks the search bar

Categories

(Firefox :: Search, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 5

People

(Reporter: john.p.baker, Assigned: Gavin)

Details

Attachments

(2 files, 2 obsolete files)

I've just been investigating a user's problem when the search bar was apparently inactive - could type in box but nothing happened on submission. It would appear to be caused by a failure to write the search term to the formhistory database. I've left someone else investigating why the access is wrong but something like

477           // Save the current value in the form history
478           if (textValue) {
+               try {
479               textBox._formHistSvc.addEntry(textBox.getAttribute("autocompletesearchparam"),
480                                             textValue);
+               } catch (e) {
+                 Components.utils.reportError(e);
+               }
481           }
482 
483           this.doSearch(textValue, where);

may be appropriate.
Would it be possible to share the formhistory.sqlite file? If not, can you make a backup of that file and use a sqlite3 management software to remove as much as possible entries until the write action succeeds?
Summary: search bar inactive → search bar inactive if failure when adding searchterm to formhistory
Hello,
I had the same problem on Firefox 4 and I found the solution :
Export all data from the old formhistory.sqlite file (of my profile) with sqlitebrowser
Import in a new formhistory.sqlite file (from a new profile) all my data.

And it work !! :)

If you want, i can send you the problematic formhistory.sqlite
(In reply to comment #2)
> If you want, i can send you the problematic formhistory.sqlite

That would be great. You can even attach it to this bug, if no private data you don't want to share is included. If that's the case just send it to my address and I can investigate. Thanks.
OK no problem !
Attached file Testcase
Confirmed on OS X with Firefox 4.0. After using the same profile with Firefox 3.6 it works fine again. Look like a regression. Not sure which version of Firefox the original reporter was using but lets take this bug for the Firefox 4 issue.
Severity: minor → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 7 → All
Hardware: x86 → All
So starting with builds from 09110610 Firefox crashes when a search is started. That crash has been fixed sometimes later but lets focus on that date for now.

PASS: http://hg.mozilla.org/mozilla-central/rev/91e00d39570f
FAIL: http://hg.mozilla.org/mozilla-central/rev/f1c0c5a52b29

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=91e00d39570f&tochange=f1c0c5a52b29

Gavin, do you have any idea?
Well, in that pushlog the SQLite upgrade it the obvious contender for related-changeset. But that doesn't really help explain how the form history database got corrupted in the first place.

We should probably make such failures non-fatal as John suggests.
Attached patch patch (obsolete) — Splinter Review
Lets the search work even if saving to form history doesn't.
Assignee: nobody → gavin.sharp
Status: NEW → ASSIGNED
Attachment #522504 - Flags: review?(dao)
Attached patch patch (obsolete) — Splinter Review
This is the real patch...
Attachment #522504 - Attachment is obsolete: true
Attachment #522505 - Flags: review?(dao)
Attachment #522504 - Flags: review?(dao)
Summary: search bar inactive if failure when adding searchterm to formhistory → failure to save searches to form history breaks the search bar
Attachment #522505 - Flags: review?(dao) → review+
Attached patch for checkinSplinter Review
Attachment #522505 - Attachment is obsolete: true
http://hg.mozilla.org/mozilla-central/rev/d41a049ad2dc
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: fixed-in-cedar
Target Milestone: --- → Firefox4.2
Flags: in-testsuite-
Target Milestone: Firefox5 → Firefox 5
Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0a2) Gecko/20110426 Firefox/5.0a2
Status: RESOLVED → VERIFIED
Flags: in-litmus-
You need to log in before you can comment on or make changes to this bug.