When home directory is on AFP server, 3.0.11 has problems with bookmarks, search field, etc.

VERIFIED FIXED

Status

()

Firefox
Bookmarks & History
--
critical
VERIFIED FIXED
8 years ago
8 years ago

People

(Reporter: Marty Sachs, Assigned: sdwilsh)

Tracking

({regression, verified1.9.0.12})

3.0 Branch
All
Mac OS X
regression, verified1.9.0.12
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.1.1 -
blocking1.9.0.12 +
wanted1.9.0.x +
in-litmus ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
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.
(Reporter)

Comment 1

8 years ago
This also happens on an Intel Mac.
Component: General → Places
QA Contact: general → places
Version: unspecified → 3.0 Branch

Comment 2

8 years ago
This bug is a duplicate of bug #417037
(Reporter)

Comment 3

8 years ago
Apparently, this is to be treated as a new bug.
(Assignee)

Updated

8 years ago
Keywords: qawanted, regressionwindow-wanted
(Reporter)

Comment 4

8 years ago
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/
(Assignee)

Comment 6

8 years ago
possible, but I'd really hope not.
Duplicate of this bug: 498071
new based on dupe
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 9

8 years ago
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.
Blocks: 488710
Flags: blocking1.9.0.12?
Keywords: qawanted, regressionwindow-wanted → regression
Hardware: PowerPC → All
(Assignee)

Comment 11

8 years ago
sadface

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

Comment 12

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

Comment 13

8 years ago
I can confirm that the 17/4 build works and the 18/4 build doesn't.
Duplicate of this bug: 498207
(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.
Severity: major → critical
(Reporter)

Comment 16

8 years ago
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.
Assignee: nobody → sdwilsh
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.12?
Flags: blocking1.9.0.12+
(Assignee)

Comment 19

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

Comment 21

8 years ago
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.
(Assignee)

Comment 24

8 years ago
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.
(Assignee)

Updated

8 years ago
Whiteboard: [building branch with upgraded SQLite for testing]
(Assignee)

Comment 26

8 years ago
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.
Whiteboard: [building branch with upgraded SQLite for testing] → [needs testing]
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

Comment 28

8 years ago
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!
(Assignee)

Comment 29

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

Comment 30

8 years ago
Shawn's build is working for me with an AFP home directory!
(Assignee)

Comment 31

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

Comment 32

8 years ago
(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.
(Reporter)

Comment 33

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

Comment 34

8 years ago
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.
Status: NEW → ASSIGNED
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?

Comment 37

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

Comment 38

8 years ago
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 :-)
Whiteboard: [needs testing] → [needs pretend patch]

Updated

8 years ago
Duplicate of this bug: 498688
(Assignee)

Comment 40

8 years ago
Created attachment 383509 [details] [diff] [review]
branch version of attachment 362137 [details] [diff] [review]

This is the branch patch from attachment 362137 [details] [diff] [review] in bug 478297.  r=asuth
Attachment #383509 - Flags: approval1.9.0.12?
(Assignee)

Updated

8 years ago
Whiteboard: [needs pretend patch] → [needs approval]
(Assignee)

Updated

8 years ago
Depends on: 478297
Flags: in-litmus?
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
Attachment #383509 - Flags: approval1.9.0.12? → approval1.9.0.12+
Whiteboard: [needs approval] → [needs 1.9.0 landing]
Duplicate of this bug: 498891
(Assignee)

Comment 43

8 years ago
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
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Keywords: fixed1.9.0.12
Resolution: --- → FIXED
Whiteboard: [needs 1.9.0 landing]
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
(Assignee)

Comment 45

8 years ago
Yeah, I pushed the exact changes that I used in my own build that I posted.  There should be no difference here :/
(Reporter)

Comment 46

8 years ago
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

Updated

8 years ago
Duplicate of this bug: 499209

Comment 48

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

Updated

8 years ago
Blocks: 499845

Comment 50

8 years ago
We have this problem as well.

Comment 51

8 years ago
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!
(Reporter)

Comment 53

8 years ago
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
(Assignee)

Comment 54

8 years ago
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/.
Keywords: fixed1.9.0.12 → verified1.9.0.12
Status: RESOLVED → VERIFIED

Comment 56

8 years ago
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.
(Assignee)

Comment 57

8 years ago
(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.
(Reporter)

Comment 58

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

Comment 59

8 years ago
Yep this seems to happen to all network users, local accounts are fine... I will submit a new bug.
Flags: blocking1.9.1.1-
(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?

Comment 61

8 years ago
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
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.