The Awesome Bar hangs when using Mac OS X with a networked home directory.




6 years ago
5 years ago


(Reporter: Jeff Strunk, Unassigned)


(Blocks: 1 bug)

9 Branch
Mac OS X

Firefox Tracking Flags

(Not tracked)




6 years ago
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 and the browse
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"


6 years ago
OS: Linux → Mac OS X

Comment 1

6 years ago
I forgot to mention that the latest releases of the Firefox 3.6 branch work correctly in this environment.

Comment 2

6 years ago
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.
Blocks: 719952

Comment 3

6 years ago
I used to see the bookmarks issue of bug 701457. I just verified that is still occurs in my environment.
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 701457

Comment 4

6 years ago
Bug 701457 appears to be fixed in the latest release(10.0), but this issue is still present.
Resolution: DUPLICATE → ---

Comment 5

6 years ago
Agreed. I've just reproduced 717406 using AFP homes on Intel 10.5.8 with FF 10.0.

Comment 6

6 years ago
For the record, this bug is definitely NOT a DUPLICATE of, which appears to have been fixed in 10.x.

Comment 7

6 years ago
For me, the awesomebar simply stops working after a while.

Comment 8

6 years ago
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?

Comment 9

6 years ago
After visiting 10 or 15 pages with FF 11.0 on OS X 10.7.3, the Awesome Bar stopped working.

Comment 10

6 years ago
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.

Comment 11

6 years ago
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:

Comment 12

6 years ago
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.


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.

Comment 14

6 years ago
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 :)


5 years ago
Component: Untriaged → Storage
Product: Firefox → Toolkit

Comment 15

5 years ago
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.
You need to log in before you can comment on or make changes to this bug.