User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050315 Firefox/1.0+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050315 Firefox/1.0+ If you install Firefox in a directory where the owner has read-write access but other (plain) users don't, then Firefox won't launch. Running it first as the owner and then as a (plain) user works. After checking the details of the directories, I discovered that Firefox needs to create the file "app-chrome.manifest" in the Firefox.app/Contents/MacOS/chrome directory. This is probably a result of the fix for bug 28365 where a "bad" instance of the app-chrome.manifest was removed from the distribution. Reproducible: Always Steps to Reproduce: 1. Install Firefox where other users but you have read-only access. Do not run it. 2. Log in as a user with read-only access to said folder. 3. Launch Firefox. No dice... Actual Results: Firefox did not finish launching Expected Results: Launch If you run it as a user with write capabilities to said folder, it will auto-create "app-chrome.manifest" and after that everything works as expected.
Ooops, I forgot a 3 in the bug reference. It's actually bug 283365.
Is this a regression? We previously had to create chrome.rdf and overlayinfo structures in the appdir, so I can't imagine that it ever worked with a readonly appdir. It works if you run once as a privileged users. I hope to fix this, but it probably won't be done for the 1.1 release.
Status: UNCONFIRMED → NEW
Ever confirmed: true
FWIW, it should be enough for a priviledged user to run "firefox -register" as that will do what is necessary without bringing up any browser UI.
*** Bug 287246 has been marked as a duplicate of this bug. ***
I experience the same symptoms if I update Firefox and forget to run the application from my own profile first. Other users, who don't have admin privileges, suddenly can't run it. Is that the same bug? It sounds like it, but I just wanted to check, as this one sounds like a problem with installing Firefox for the first time, while mine is about a problem after updating it. It seems that every time I run a new build (or even an old one that wasn't the last build run), Firefox seems to think it's being run for the first time. cheers
Created attachment 182040 [details] [diff] [review] Distribute chrome/app-chrome.manifest? If chrome/app-chrome.manifest is distributed, this bug disappears. Firefox can then be launched and run from a read-only disk image (such as the one it's distributed in) or from other read-only media (for example, if it's distributed on a CD-ROM). The patch updates the packager to not strip out chrome/app-chrome.manifest. The only problem is, app-chrome.manifest seems to have been removed on purpose (bug 283365) - but that was about a corrupt file being distributed with Thunderbird. It seems like the better idea by far would be to distribute app-chrome.manifest (non-corrupt) instead of requiring the app directory to be writable. I tested the patch. The app-chrome.manifest file that is produced during the build is not corrupt. "make -C .../browser/installer", and I can run Firefox straight out of the resultant read-only disk image. I can also copy Firefox to the hard drive and revoke write permission (chmod -R a-w) and run it that way, too. bsmedberg: this IS a regression, but a distant once. We could launch from an unwritable disk image in 0.8, but couldn't by 0.9. See bug 246789 (of which this is a mutual dup.)
Attachment #182040 - Flags: review?(benjamin)
It's a much closer regression, actually, I was wrong. That's what I get for spending so much time on the trunk. I just did some testing on the release builds. Read-only startup was first broken in 0.9 but fixed in 0.10.1. It also works in 1.0, 1.0.1, 1.0.2, and 1.0.3.
Comment on attachment 182040 [details] [diff] [review] Distribute chrome/app-chrome.manifest? This won't work consistently, as it relies on running the executable from dist/bin before packaging, which is not always the case. In addition, the thunderbird repackaging steps will cause problems with this file if tbird is run before repackaging (it replaces installed-chrome.txt with a custom-edited version).
Attachment #182040 - Flags: review?(benjamin) → review-
OK, I see. Are either of these good ideas, then? If app-chrome.manifest can't be created in the app, create and use a temporary one in a writable location (profile dir?) for one session only. or Generate app-chrome.manifest from installed-chrome.txt and friends at build time (with perl?) Even if these are only temporary workarounds, this is a regression from 1.0 so it might be worth it.
Got an e-mail that bug 295235 got resolved. Downloaded the latest Firefox nightly (20050614 - now called DeerPark) and the bug seems to have gone away. As such, I'm closing this one as fixed. BTW, it takes three appearences/attempts to start up DeerPark. Like it's trying to startup, it fails, it restarts, fails and finally it gets it right. If I rename my profile directory and force it to create a new one, it shows these symptoms at the first run *only* and then it starts up normally, so I guess something got ported from my old profile that makes it go in this 3-times-startup cycle. I think that this is a different bug and an already filled one. I'll look it up and if I find nothing, I'll file a new bug report...
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox1.1
I've noticed the latter, too. I think it's due to the profile migrator, which is far from seamless on OS X and becomes obvious every time you start a new build (see bug 251613). It seems it's just become more obvious in recent builds because of some sort of problem with old profiles. If a bug doens't already exist for that, you should definitely file a new one. It'll definitely need to be fixed before 1.1 or every home Mac user who upgrades will be noticing it, and it's unreasonable to expect them all to dump their old profiles. cheers
Comment #10 is by design, although the disappearing/reappearing dock icon is not.
It's by design that it does this *every* time you launch it with an old profile? Does this mean it's intended for this to happen to every user who migrates from 1.0?
> It's by design that it does this *every* time you launch it with an old profile? > Does this mean it's intended for this to happen to every user who migrates from 1.0? It restarts once every time you change buildids, and it restarts another time every time it needs to upgrade old extensions and such, so yes.
Oh, sorry, I see what you're saying! I thought that Socratis was seeing it every time he launched the *same* build. That was my experience with recent nightlies.. the profile migration thing would launch every time. The only way I could stop it was if I used a new profile... it would stop doing it after the initial launch. I just tried the latest nightly and it's stopped doing it, though.... works fine with my older profile. Anyway, sorry for the confusion and I'll stop spamming this bug :)
In response to resent comments and specially Comment #14 from Benjamin and Comment #15 from Wayne. Benjamin, the behavior you describe (i.e. DeerPark start thrice) is happening only the first time if you start with a new profile. Subsequent launches (same build, couple seconds later actually) behave normally. But, if I do it with my old profile it starts thrice *every* time, same build and everything else. I even managed to catch a glimpse of the processes firing at the activity monitor. PIDs 2675, 2676 and 2678, all identified as firefox-bin starting in succession. So, yes, Wayne what you see is accurate as well. Now, we have to nail it down as you said, but I'm not sure if this bug is the place... I still haven't found the time to look if an appropriate bug report exists already, but I'll post a message if I do. If you find something first, please post a message so that we can focus on that...
You need to log in before you can comment on or make changes to this bug.