Closed Bug 286421 Opened 19 years ago Closed 19 years ago

Won't start if no write priviledges for chrome directory. Needs to create app-chrome.manifest

Categories

(Toolkit :: Startup and Profile System, defect)

Product:
Toolkit
Component:
Startup and Profile System
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.8final

People

(Reporter: socratis, Assigned: benjamin)

References

Details

Attachments

(1 file)

Distribute chrome/app-chrome.manifest?
755 bytes, patch
benjamin
: review-
Details | Diff | Splinter Review 
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.
Blocks: 246789
*** 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
Flags: blocking-aviary1.1?
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.
Depends on: 295235
Blocks: 295554
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
Closed: 19 years ago
Resolution: --- → FIXED
Flags: blocking-aviary1.1?
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...
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: