User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.0.10) Gecko/2009042315 Firefox/3.0.10 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.11) Gecko/2009060214 Firefox/3.0.11 I have my home directory at a remote location (on an XServe running OS X Server via AFP). Firefox 3.0.10 works fine. When I updated to 3.0.11, I saw that my Bookmarks were blank, history menu was black, the Search field was generic and didn't work, entering a url into the access field and hitting return doesn't respond. These function seem to work if I login to a local account with home directory on main drive, but not on any home directory located on a remote drive. When I downgraded to 3.0.10, all is fine again. Reproducible: Always Steps to Reproduce: 1.login to user account on remote server 2.start Firefox 3.0.11 3. Actual Results: Bookmarks were blank, history menu was black, the Search field was generic and didn't work, entering a url into the access field and hitting return doesn't respond. Expected Results: That all these functions work as in 3.0.10.

This also happens on an Intel Mac.

This bug is a duplicate of bug #417037

Apparently, this is to be treated as a new bug.

This problem does not exist in the latest nightly build of version 3.5 [Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1) Gecko/20090612 Firefox/3.5]. It seems to be specific for 3.0.11.

The list of fixed bugs for Firefox 3.0.11 can be found here: https://bugzilla.mozilla.org/buglist.cgi?keywords_type=anywords&keywords=fixed1.9.0.11+verified1.9.0.11 Shawn, could be bug 488710 a possible candidate? Reporter, could you please have a test-run with the following two builds? Is the first build working for you and the latter one not? http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/04/2009-04-17-04-mozilla1.9.0/ http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/04/2009-04-18-04-mozilla1.9.0/

possible, but I'd really hope not.

new based on dupe

The 4-17 nightly behaves normally (like 3.0.10). However, the 4-18 nightly has the same problems as 3.0.11.

Checkins on 1.9.0 in this timeframe: http://tinyurl.com/mt7e73 Shawn, looks like my assumption was correct. :( The upgrade to SQLite 3.6.7 regressed this bug. Asking for blocking1.9.0.12.

sadface Is this also broken on 1.9.1/mozilla-central? If so, we need to open up a ticket with the SQLite folks...

Also, can we get some test added to the normal QA process of releases so we don't break this again?

I can confirm that the 17/4 build works and the 18/4 build doesn't.

(In reply to comment #11) > Is this also broken on 1.9.1/mozilla-central? If so, we need to open up a > ticket with the SQLite folks... I created a fresh profile via an AFP connection on one of my NAS boxes and I'm able to reproduce this problem now. A nightly build of Grand Paradiso like Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.10pre) Gecko/2009042104 GranParadiso/3.0.10pre shows this problem. It is a build from before the version change. Firefox 3.0.10 works fine. Further I tried to reproduce it with a recent nightly on 1.9.1 and trunk but wasn't able to. The latest Firefox 3.5 RC preview build is fine. Bookmarks get loaded and no error is recognizable. Looks like we are really limited to the 1.9.0 branch here. So no respin for 3.5 seems to be necessary. Thanksfully. The following errors can be found in the Error Console: Error: [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]" nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)" location: "JS frame :: file:///Applications/GranParadiso.app/Contents/MacOS/components/nsBrowserGlue.js :: bg__initPlaces :: line 446" data: no] Source File: file:///Applications/GranParadiso.app/Contents/MacOS/components/nsBrowserGlue.js Line: 446 Error: uncaught exception: [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]" nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)" location: "JS frame :: file:///Applications/GranParadiso.app/Contents/MacOS/modules/utils.js :: anonymous :: line 97" data: no] Error: uncaught exception: [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]" nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)" location: "JS frame :: chrome://browser/content/search/search.xml :: get_searchService :: line 145" data: no] Error: uncaught exception: [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]" nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)" location: "JS frame :: chrome://browser/content/search/search.xml :: initialize :: line 527" data: no] Error: uncaught exception: [Exception... "Component returned failure code: 0x8007000e (NS_ERROR_OUT_OF_MEMORY) [nsIDocShellHistory.useGlobalHistory]" nsresult: "0x8007000e (NS_ERROR_OUT_OF_MEMORY)" location: "JS frame :: chrome://browser/content/browser.js :: prepareForStartup :: line 845" data: no] Error: uncaught exception: [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]" nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)" location: "JS frame :: file:///Applications/GranParadiso.app/Contents/MacOS/modules/utils.js :: anonymous :: line 106" data: no] (In reply to comment #12) > Also, can we get some test added to the normal QA process of releases so we > don't break this again? Al and Juan, I could step in here and run tests after we do a SQLite upgrade. It's very easy for me. So we should just note it somewhere.

As I said in comment #4: This problem does not exist in a recent nightly build (from 6-12) of version 3.5 (rv:1.9.1). I agree that it is presently restricted to the 1.9.0 branch and occurred between the 4-17 and 4-18 nightly.

Is there a bug on getting an AFP test included? This isn't the first time we've run into it, and it feels like the sort of thing we should be testing before we ship software

This needs to block. Shawn, I'm assigning this to you (for now?) to investigate, but feel free to pass on to someone who's better. Technically our code freeze is in a little over two days, but we'll take this after code freeze if need be.

We have two options here - 1) we can backout the SQLite upgrade on branch, 2) upgrade to what we have on 1.9.1. I'm more inclined to take what we have on 1.9.1 because we took the upgrade in the first place to get rid of some of our top crashes. With that said, I'm leaving this decision up to the release drivers. I can have a patch up Monday either way.

Is this firedrill-worthy? We're breaking users but how many?

I have 2,156 users at my school, plus another 170 remotely. You have to consider all the schools using Macs and those sysadmins telling them Firefox is better than Safari. I would be such a sysadmin who sets the default browser to Firefox.

(In reply to comment #20) > Is this firedrill-worthy? No. > We're breaking users but how many? It's unclear, but it'd only be a subset of Mac users, and a small portion at that. I can add a known issue to our release notes and we can recommend those users stick with 3.0.10 until 3.0.12 ships. Not ideal, but I don't think this is worth firedrilling for. Shawn: I'll talk with Dan and see what the best course is here, though I'm inclined to agree that upgrading again is the right way to go. Can we confirm that the newer SQLite fixes the problem on 1.9.0 and it's not some other patch we need?

yes, please. We must verify that the newer library fixes it ASAP before deciding anything.

I do not know how it could be possible for any of our own code to break this. comment 15 indicates that the newer SQLite does indeed fix this. I can't do a try-server build because the patch would be too large for the try server.

Shawn, if you could build it yourself and upload the dmg to a location I can download from I would like to verify the fix.

If I did this right, this should have the build: http://files.shawnwilsher.com/2009/6/15/GranParadiso.zip This is not a universal binary.

Nope that doesn't work. I get the following error when opening the application. Is it build the same way as nightly builds? Library not loaded: @executable_path/XUL Referenced from: /User/henrik/Desktop/GrandParadiso.app/Contents/MacOS/firefox-bin Reason: image not found

Shawn, it looks like your build contains several symbolic links in the "GranParadiso.app/Contents/MacOS" directory that link to a "/Code/moz/trunk/mozilla/obj-i386-apple-darwin8.11.1" directory. Try copying those files into the appdir and reuploading. Thanks!

Looks like I uploaded the wrong package. New one is up at the same place at 10.4 MB which seems much more realistic.

Shawn's build is working for me with an AFP home directory!

Patch will be too big to upload to bugzilla, but it's the standard SQLite upgrade, so I'll just need driver approval if we decide to upgrade.

(In reply to comment #30) > Shawn's build is working for me with an AFP home directory! I can confirm that Shawn's build has worked for me too. Thank you.

I can also confirm that Shawn's build (2009/6/15/GranParadiso) works for me on an Intel mac logged into a user account on our XServe via AFP.

I can verify this bug. I have had 7 users affected until I sent out mass email not to upgrade Firefox. I have over 50 Mac network home users.

Wow, you guys are really fast. Thanks for verifying the fix. So I'm the forth in the round who can say this is WFM.

Shawn: Wanna give me a placeholder to approve for 1.9.0.12? Also, anything else we should be worried about in this newer SQLite? I'm assuming it shipped with 3.5b4?

Hey guys, thanks a lot for your efforts. I can also confirm this build works for me on a Intel Mac in combination with an XServe user account through AFP.

I too can confirm that this build works on Intel Mac OS X 10.4.11 and 10.5.7 network accounts on our AFP servers. Great job and fast work, thanks :-)

This is the branch patch from attachment 362137 [details] [diff] [review] in bug 478297. r=asuth

Comment on attachment 383509 [details] [diff] [review] branch version of attachment 362137 [details] [diff] [review] Approved for 1.9.0.12, a=dveditz for release-drivers

Checking in configure.in; new revision: 1.2003; previous revision: 1.2002 Checking in db/sqlite3/README.MOZILLA; new revision: 1.32; previous revision: 1.31 Checking in db/sqlite3/src/sqlite3.c; new revision: 1.23; previous revision: 1.22 Checking in db/sqlite3/src/sqlite3.h; new revision: 1.26; previous revision: 1.25

Shawn, the current 1.9.0 nightly build should have this patch included or? When I run a test with the following build it still doesn't work for me: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.12pre) Gecko/2009061804 GranParadiso/3.0.12pre

Yeah, I pushed the exact changes that I used in my own build that I posted. There should be no difference here :/

The June 18th nightly works fine for me (Open Directory AFP login): Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.12pre) Gecko/2009061804 GranParadiso/3.0.12pre

Thanks for working on this guys. I have 20 AFP users off of one 10.4 Server. I am amazed at how fast the open source community works. I look forward to 3.012 and 3.5 final. 3.5RC appears to work fine over AFP home directories.

(In reply to comment #45) > Yeah, I pushed the exact changes that I used in my own build that I posted. > There should be no difference here :/ Shawn, no idea what happened on my box but somehow all bookmarks were deleted. That's why I thought the problem hasn't been fixed. Now after restoring the latest saved JSON backup everything is fine. I tried several paths to find out what could have been caused this problem for me but haven't had luck to reproduce. Al, can you create the Litmus test?

We have this problem as well.

I appreciate the quick fix on this, but how can we get the latest version with the implemented fix (3.0.12)? Is it coming out soon, or is the answer to go to 3.5RC3? Getting anxious! ;-)

3.5 is live!

I can confirm that 3.5 works for me (Open Directory AFP login): Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5

3.0.12 will not be out for a few weeks still, but 3.5 is available right now!

Marking as verified for 3.0.12. Others can verify, if they wish, using the nightly 1.9.0.12 build from ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla1.9.0/.

I have tested firefox 3.5 on Mac OS X with a Network Home that is hosted on an SMB server. I had the same issues as everyone else here. 3.5 now displays "The bookmarks and history system will not be functional". It appear the same sqlite is the issue.

(In reply to comment #56) > I have tested firefox 3.5 on Mac OS X with a Network Home that is hosted on an > SMB server. I had the same issues as everyone else here. 3.5 now displays "The > bookmarks and history system will not be functional". It appear the same sqlite > is the issue. That sounds like a different issue. Others have reported that 3.5 works just fine for them.

Yes, that does appear to be a different issue (not affecting me). When I use 3.0.11 or nightlies in the 1.9.0.x branch between 2009-04-18-04 and when this was fixed (2009-06-18-04), there was no warning displayed. The bookmarks, search field, and history simply did not work when logged in using Open Directory via AFP to a user directory on a remote server. On my setup, the 3.5 branch has always worked fine (at least so since trying it after 3.0.11 was released). Nathan may want to check to see if a different user with home directory based on this SMB server has the same issues. He may be experiencing something particular to his individual preferences.

Yep this seems to happen to all network users, local accounts are fine... I will submit a new bug.

(In reply to comment #59) > Yep this seems to happen to all network users, local accounts are fine... I > will submit a new bug. Nathan, have you filed a new bug?

Hi, yes I did, I can be found here https://bugzilla.mozilla.org/show_bug.cgi?id=502283

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv