503492 - search toolbar doesn't work; search box unresponsive when executing a search

Status: RESOLVED INCOMPLETE

(Firefox :: Search, defect)

Description

[George5]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.5) Gecko/2008120121 Firefox/3.0.5
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.5) Gecko/2008120121 Firefox/3.0.5

When trying to use the search toolbar I can type in the search box but cannot search. When trying to hit enter, or click the magnifier icon, nothing happens.

This problem occurs at our office, many users run in to this problem but not all. The problem started after upgrading to Firefox 3.xxx. Before there were no problems. As multiple users have this problem, I was able to reproduce it mutiple times using different versions of Firefox.

The problem occurs under Mac OS X 10.5.3 through 10.5.7 (if applicable).
Also tried this with Firefox 3.0.3 3.0.5 3.0.11 and Firefox 3.5 All have the same problem.

With the users that have this problem, it happens all the time.

Reproducible: Always

Steps to Reproduce:
Hard to say. After upgrading to firefox 3.0 search box fails to work.

1.
2.
3.



When tested no plugins, themes, or add-ons are used. Other than standard that come with installing the browser.

Also there a few suggestions I already tested with varying results.

- removing or renaming the formhistory.sqlite
Works temporarily. Let's you use the search box apporximatly 1-3 times. Varies.

- removing or renaming the search.sqlite
Crashes the browser on first attempt to open. After that, same as above, works temporarily.

- creating a completely new profile
Works temporarily. Let's you use the search box a couple of times (varies, 3-10 times). But ultimately stops working.

- clearing private data (Firefox 3.0.xxx ONLY)
Also not a permanent work around. When letting firefox clear history on shutdown it works when restarting firefox (obviously). After that, when the browser is running, the user can only use the search box a couple of times (varies, 5 or so) before the search box becomes unresponsive again.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #0)
> - removing or renaming the search.sqlite
> Crashes the browser on first attempt to open. After that, same as above, works
> temporarily.

Please open "about:crashes" in the location bar and give us the appropriate link with the crash id.

> - creating a completely new profile
> Works temporarily. Let's you use the search box a couple of times (varies, 3-10
> times). But ultimately stops working.

Can you please zip the whole profile and attach it to this bug?

Comment 2

[George5]

Attachment: Complete profile where search box doesn't work

I tried the about crashes. But there is nothing there. The browser does not crash, it is just the search box that doesn't function properly.



Unrelated to the problem. I got an error trying to upload the profile. What should the content type description be?

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+2]]

George, thanks for the test profile but when copying all the files into an existing profile on my side and starting Firefox I cannot reproduce the problem. The search functionality is not blocked and I can start a search by hitting enter or clicking the search icon. Can you please do the same on your side? Means creating a new profile with Firefox and after a shutdown replacing all the files with this test profile. Does the problem persist for you?

Comment 4

[George5]

I don't know what to say. I tried the profile again, following what you write above. But the problem persists for me.

Are you using Mac OS 10.5? Because the problem doesn't occur under Windows XP?


Also maybe IMPORTANT? I failed to mention this before because I forgot. But we use a proxy to connect to the internet. But like I mentioned before not all mac's with firefox encounter this problem.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Was the proxy information entered into the profile? I don't think so. Looks like you are using the system proxy. George, do you have a change to test the search functionality outside of the company without a proxy set? Would be good to know if that is the cause. And yes, I'm on OS X and tested it with Firefox 3.5.1.

Comment 6

[George5]

I checked. The proxy information was indeed entered into the profile. I will test the  profile outside the company but that will take about a week. I cannot get access to a mac before that time.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Ok, so we have to wait. So you don't have a DMZ available you could use to directly connect to the internet?

Comment 8

[Peter Beckman]

I'm going to throw my hat in the ring on this bug.  I've search bugzilla for a recently opened bug relating to the integrated search toolbar not working, and working again after removing a .sqlite file in the profile.

I posted my process here: https://support.mozilla.com/tiki-view_forum_thread.php?forumId=1&comments_parentId=399500

However it may be that in a few days things will be corrupt again, similar to the opener's situation.

I'm using a profile I started fresh when 3.5 came out.

I followed a process mentioned in a blog about how to recover from a corrupted .sqlite file.  I used the same process using my formhistory.sqlite and found the following interesting:

// Broken formhistory.sqlite file
sqlite> select count(*) from moz_formhistory;
1918

// Dump to a file, read it back in
sqlite> .read was_formhistory_sql
SQL error near line 1: PRIMARY KEY must be unique
SQL error near line 1879: moz_formhistory.fieldname may not be NULL
SQL error near line 1880: moz_formhistory.fieldname may not be NULL
SQL error near line 1881: moz_formhistory.fieldname may not be NULL
SQL error near line 1882: moz_formhistory.fieldname may not be NULL
SQL error near line 1883: moz_formhistory.fieldname may not be NULL
SQL error near line 1884: moz_formhistory.fieldname may not be NULL
SQL error near line 1885: moz_formhistory.fieldname may not be NULL
SQL error near line 1886: moz_formhistory.fieldname may not be NULL
SQL error near line 1887: moz_formhistory.fieldname may not be NULL
SQL error near line 1888: moz_formhistory.fieldname may not be NULL
SQL error near line 1889: moz_formhistory.fieldname may not be NULL
SQL error near line 1890: moz_formhistory.fieldname may not be NULL
SQL error near line 1891: moz_formhistory.fieldname may not be NULL
SQL error near line 1892: moz_formhistory.fieldname may not be NULL
SQL error near line 1893: moz_formhistory.fieldname may not be NULL
SQL error near line 1894: moz_formhistory.fieldname may not be NULL
SQL error near line 1895: moz_formhistory.fieldname may not be NULL
SQL error near line 1896: moz_formhistory.fieldname may not be NULL
SQL error near line 1897: moz_formhistory.fieldname may not be NULL

I opened up the broken formhistory.sqlite file and tried a few things:
sqlite> select * from moz_formhistory where fieldname is null;
SQL error: database disk image is malformed
sqlite> select * from moz_formhistory;
[...]
1878|searchbar-history|firefox rules|1|1249452582092832|1249452582092832
47|||||
48|||||
36|||||
62|||||
45|||||
49|||||
53|||||
55|||||
52|||||
35|||||
37|||||
41|||||
35|||||
38|||||
35|||||
70|||||
79|||||
54|||||
39|||||
1898|exchange|478|1|1249495711716646|1249495711716646

It's clear there was some period of time where adding things to the formhistory was either broken or corrupted.  Maybe it will happen to me again.  Georges5 it'd be useful if you can save the formhistory.sqlite file when it becomes corrupt again after working and see if you are seeing the same troubles.

Comment 9

[Peter Beckman]

I failed to mention, I too am on a Mac, OS X 10.5.7
Darwin max 9.7.0 Darwin Kernel Version 9.7.0: Tue Mar 31 22:52:17 PDT 2009; root:xnu-1228.12.14~1/RELEASE_I386 i386 i386

I was running 3.5 just fine until I got a notice to update to 3.5.2 beta.  I'm not sure if I was running 3.5.1 prior to that.  Is there an "about:versionhistory" that shows me all the previous versions with their date of release, as well as date/time I installed them?  That would be wicked sexy and handy for this sort of thing.

Comment 10

[Peter Beckman]

The timestamps prior to and just after the corrupted period:

Wed, 05 Aug 2009 06:09:42 GMT
[..corruption..]
Wed, 05 Aug 2009 18:08:31 GMT

Please note my computer is on America/New_York time zone, so those may be local times rather than GMT.  I'm not sure when I updated, but I'm guessing this might indicate that it was earlier this week, which matches the timestamp on the Firefox binary:

/Applications/Firefox.app/Contents/MacOS/updates:
[...]
-rw-r--r--@  1 beckman  admin  151043 Aug  3 11:04 last-update.log

Is there a log of what AddOns you've updated or installed and when that occurred?  There probably should be, along with their versions.

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Peter, please report it as its own bug. It is definitely another issue. Please CC me to the newly filed bug. Thanks.

Georg, do you have any update for us?

Comment 12

[Ryan Flint [:rflint] (ping via IRC for reviews)]

Incomplete pending a response to comment 11.