482300 - (Bob) Firefox does not display back buttons or allow bookmarks

Status: RESOLVED INCOMPLETE

(Firefox :: Bookmarks & History, defect)

Description

[Bob]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us) AppleWebKit/528.16 (KHTML, like Gecko) Version/4.0 Safari/528.16
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.7) Gecko/2009021906 Firefox/3.0.7

Firefox will not display the back buttons or allow users to post bookmarks.  We maintain a network home environment.  We have an Active Directory environment with SMB homes.  Our Macs are joined using Thursby's ADmitMac client.  some users are fine, but others (many/most??) have this problem.  

We have created ~/.MacOSX folders for each user in an attempt to work through this problem.  That has helped for some, but users could still be left with "places.*" files after app exits -which means at next launch they're faced with a "broken app" (from their perspective).  

Reproducible: Sometimes

Steps to Reproduce:
1. launch application
2. quit application
3. launch application
Actual Results:  
you might not get back buttons, etc. right away, or you might have to quit and re-launch the app more then once during the same console session to get corrupted places.* files

Expected Results:  
back buttons that work and bookmarks that can be saved.

Comment 1

[Shawn Wilsher :sdwilsh]

Take a look at bug 417037 as it sounds like you might be hitting some of the issues that were found there (note: bug title isn't completely accurate).

Comment 2

[Bob]

Yup.  In fact, you (sdwilsh) posted on 417037 and told me to open a new bug.

Comment 3

[Shawn Wilsher :sdwilsh]

Sorry - a lot of bugs fly past me :)

It's possible that the Thursby's ADmitMac client is the culprit here if it's not returning sane answers for file system api calls.

Comment 4

[Bob]

NP.  I can do some digging on the Thursby thing, but that seems unrealistic to me.  I've seen a lot of comments here and elsewhere (like even AFP548.com) where people are complaining about the same issue.  This is with SMB and AFP homes (where I'd expect no 3rd party plugins to address user filespace).

Comment 5

[Bob]

Wondering if anyone has further thoughts on this bug.  I need to make a recommendation soon on continuing support for Firefox (for Macintosh) here at the university.

Comment 6

[Shawn Wilsher :sdwilsh]

You best bet is probably to send a message to [e-mail] explaining your problem.  That's all I'll be able to do, and any questions they ask I'll just have to ask you, so we might as well cut out the middleman.

Comment 7

[Shawn Wilsher :sdwilsh]

So, bug 484883 may help.  There's no patch in there yet, but doing it may be a workaround for you.

Comment 8

[Derek Smith]

This bug is occurring on Intel and PPC Macs running OS X 10.5.4 and 10.5.6 with users' SMB homefolders while using Thursby's ADmitMac connecting to Win '08 DFS servers.

Deleting users' Firefox profile folders fixes the problem, but for only a short time before the problem recurs.

It is reproducible. Hundreds of our students & faculty have been experiencing this since upgrading our installed Firefox 2.x to Firefox 3.0.7 two weeks ago, after a web-based SIS vendor 'certified' Firefox 3.0.x for access to their system.

Much pain and tribulation, folks.

Comment 9

[Bob]

We've also tested the latest beta of the 3.1 branch.  Same issue.  Always happens though, attempting to fix (following the instructions posted on the Firefox/Mozilla website) does not even temporarily resolve the problem.  

Contacting the SQLite people isn't helpful for an end user or a tech representing end users.  This should be done by the developer.  …or maybe the developer should move their app over to a subsystem/method that works in a network home environment (it's not like this problem is "new").

Comment 10

[D. Richard Hipp]

I'm guessing that this is due to breakage in ADmitMac - that ADmitMac is not handling file locking properly.  However, since I do not having access to network at St. Cloud State Unverisity, there is no way for me to test this hypothesis.

If my guess is correct, one possible work-around is to modify FF to have an option to open all SQLite database connections using sqlite3_open_v2() and pass in either "unix-none" or "unix-dotfile" as the 4th argument (for unix builds only, obviously.)  These parameters cause alternative filesystem backends to be inserted that do *not* use posix advisory file locking.  "unix-none" does no locking at all - which will lead to problems if another process attempts to write to the database at the same time FF does.  "unix-dotfile" will use dot-file locking, which is safer, but can leave stale dot-file locks laying around after a crash.  Neither solution is perfect, which is why neither should be the default.  These should be provided as an obscure option to work around broken filesystems, such as we speculate we are dealing with in AdmitMac.

Comment 11

[Bob]

I don't think ADmit Mac is the problem here.  This problem has been around long enough that people in native Mac environments have complained about it referencing AFP homes.  Also, this is known to the SQLite folks vis-a-vis Linux.  Regardless, I've consulted with the Thursby (ADmit Mac) folks and they have investigated the issue as well.  

What database are you referring to in your "unix-none" scenario?  The places.sqlite?  If so, what besides FF is going to write to that db?

Comment 12

[D. Richard Hipp]

If the problem really is a filesystem bug, then the "unix-nolock" VFS should be used when opening *all* SQLite databases.  The use of "unix-nolock" as the 4th parameter to sqlite3_open_v2() simply tells SQLite not to try to use file locking on whatever database file it is opening (presumably because file-locking is busted in the underlying filesystem.)

The problem might be in the Mac, not ADmit Mac.  Or it might be some subtle interation between Mac, Admit Mac, and whatever SMB server you are using.  Either way, the simplest work-around is simply to disable file locking in SQLite.  Of course, you then run the risks of having two or processes step on each other - but if file locking is busted on your filesystem, I don't suppose there is really anything you can do about that.

Comment 13

[Shawn Wilsher :sdwilsh]

Note that bug 484883 is filed about providing the option to specify a different vfs for file locking in storage.

(In reply to comment #9)
> Contacting the SQLite people isn't helpful for an end user or a tech
> representing end users.  This should be done by the developer.  …or maybe the
> developer should move their app over to a subsystem/method that works in a
> network home environment (it's not like this problem is "new").
Expecting mozilla to test every possible OS/filesystem combination is pretty unrealistic IMHO.

Comment 14

[Derek Smith]

In FireFox 3.5.x, this bug is STILL occurring on Intel and PPC Macs running OS X 10.5.8 with users' SMB homefolders while using Thursby's ADmitMac connecting to Win '08 DFS servers.

Deleting users' Firefox profile folders fixes the problem, but for only a short time before the problem recurs. Deleting the profile folder has other deleterious effects, such as losing bookmarks, etc, much to the consternation of our users.

It is reproducible - ALL of our students & faculty have been experiencing this since upgrading to 3.5.x.

Because our SIS and grading/reporting software can only be used with Firefox (Safari is not supported) this has become a MAJOR ISSUE.

Comment 15

[Bob]

We discovered (by happenstance) that version 3.0.10 will work properly.  If you eliminate the Firefox user profile and create a new one, it works just fine …unless you need to authorize a web cert.  Then it will break again.  

I don't expect that the Mozilla team will ever "confirm" or fix this.  It's a shame really, in our labs (we support Macs in all the student labs) it gives Firefox (and the Mac) a bad rap and/or causes confusion/frustration because "this doesn't happen" on their Mac.  I can't recommend to the student over-site committee that we give up on all of the extra functionality that a network account give us though.

Comment 16

[Gervase Markham [:gerv]]

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

Comment 17

[Tyler Downer [He/Him]]

Reporter, are you still seeing this issue with Firefox 3.6.13 or later in safe mode or a fresh profile? If not, please close. These links can help you in your testing.
http://support.mozilla.com/kb/Safe+Mode
http://support.mozilla.com/kb/Managing+profiles

Comment 18

[Tyler Downer [He/Him]]

No reply from reporter, INCOMPLETE. Please retest with Firefox 4 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.