User Agent: Mozilla/5.0 (Ubuntu; X11; Linux x86_64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1 Build ID: 20111221233052 Steps to reproduce: Since Firefox 4.0 for Mac OS X, the Awesome Bar hangs after visiting a few websites or after a certain amount of time when the home directory is located on a networked filesystem. I have tested this with up to date versions of Mac OS X 10.5, 10.6, 10.7, and the latest developer seeds of 10.7. I have tried multiple NFS servers and using AFP from a Lion Server and from Netatalk on Linux. I have not tested CIFS or Samba. This issue does not occur on our Linux workstations. Steps to reproduce: 1. Set up an account in OS X with a home directory on an NFSv3 server or an AFP server. 2. Log in with that account and open Firefox 3. Browse a few sites for a few minutes. I start with www.ma.utexas.edu and the browse reddit.com. 4. Type a page title from your browsing history into the Awesome Bar. I type "math". Extra Notes: Sometimes this bug does not get triggered until you have been browsing for over 10 minutes. Other times, it is almost immediate. Actual results: A spinning partial circle icon is displayed to the left of the text you are typing in the Awesome Bar. It hangs there forever. Expected results: You should see pages from your history with the word you typed in the title. In my example, I should see at least one result with the title: "UT Mathematics"
I forgot to mention that the latest releases of the Firefox 3.6 branch work correctly in this environment.
There appear to be quite a few issues around sqlite and Mac on network drives. This might be a dupe of one of those issues.
I used to see the bookmarks issue of bug 701457. I just verified that is still occurs in my environment.
Bug 701457 appears to be fixed in the latest release(10.0), but this issue is still present.
Agreed. I've just reproduced 717406 using AFP homes on Intel 10.5.8 with FF 10.0.
For the record, this bug is definitely NOT a DUPLICATE of https://bugzilla.mozilla.org/show_bug.cgi?id=701457, which appears to have been fixed in 10.x.
For me, the awesomebar simply stops working after a while.
I have tested FF 11.0 under both Mac OS 10.5.8 and 10.6.8 in a networked homes environment and can't reproduce this issue now. It may have been fixed. Specifically, the Awesome Bar (I can't believe I just typed that phrase) correctly remembers history, autofills the URL while typing, history is available across tabs and no longer beachballs when accessed. This behaviour seems to persist across sessions: history from previous sessions is correctly remembered after FF 11 has been quit and restarted. Can anyone else corroborate?
After visiting 10 or 15 pages with FF 11.0 on OS X 10.7.3, the Awesome Bar stopped working.
I can't reproduce your results with 10.7.3 and I'm in a "hostile" network homes test environment (serving Network Homes over a wireless connection) to a very pokey Macbook Pro. For me, it's working fine. Hardly a large sample. Is it possible that there's a server-side-related or network bandwidth issue as well? We tested against the same 1.83 GHz 10.6.8 Core 2 Duo Mac Mini for 10.6.8 and 10.7.3, against a 10.6.8 XServe for 10.5.8.
I've verified this is still a problem with both NFS and AFP with Firefox 11 on OS X 10.7.3. It intermittent now. It happened on my first session within the first 5 pages. It never showed up in the 2nd session. The 3rd session triggered the problem in about 10 pages. The 4th session was also 5 pages. The 5th didn't have the problem. I keep going to the same pages in my tests. I also just found this: https://bugzilla.mozilla.org/show_bug.cgi?id=473624#c4
Clarification: We are *not* using NFS homes, only AFP.
I had a discussion with the developers of Places about this and the problem is that Firefox switched to using WAL (Write-Ahead Logging) for SQLite. See: http://www.sqlite.org/wal.html for more information. In particular point #2: All processes using a database must be on the same host computer; WAL does not work over a network filesystem. So basically this change to Places broke using Firefox profiles over a network file system. I tried building a version of Firefox with WAL turned off, but other things broke.
Firefox 11.0. AFP home directories. I've came to the conclusion that the culprit is "places.sqlite" (and maybe places.sqlite-journal). One of my users was dealing with this problem for months. As she's kind enough, we decided to test if a new Firefox profile could change something. One day before the experiment, and for no reason, her Awesome bar suddenly worked again. But we decided to give "the new Firefox profile" a try. So, on the same Mac, with the same user account, I first did a backup of the current Firefox profile (which was working). I created a brand new profile : the awesome bar didn't worked at all. Then I just copied the old-and-working places.sqlite file from the previous profile to the new one and everything worked well ! I deleted it, and tested again with a new empty places.sqlite : it failed. I've also noticed something kinda weird in my AFP server logs. I get hundreds ""Delete places.sqlite-journal" 0 0 0" AFP requests per second from this user's machine. So each time the file "places.sqlite-journal" is re-created, it's deleted immediately after. This particular behavior doesn't happen all the time. And when it is happening, Firefox does work well. I hope this can help to fix this issue. If I can do more, just tell me what :)
I've verified this is still a problem with both NFS and AFP with Firefox 18.0.1 on OS X 10.7.5. It happened on my first session within the first 3-5 pages. The same pattern occurred for subsequent sessions with the same test pages.