Closed Bug 237128 Opened 16 years ago Closed 10 years ago

Mozilla do not start (leaving no warning/info etc) if I don't have access rights to ~/.mozilla

Categories

(Toolkit :: Startup and Profile System, defect)

x86
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla1.9.3a3

People

(Reporter: axelotto, Assigned: stransky)

References

Details

(Whiteboard: [good first bug])

Attachments

(3 files, 3 obsolete files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040310
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040310

Set the owner of .mozilla in your home folder to for example root, don't give
yourself permissons to modify that folder.
Mozilla will exit immediately on startup.
No warning/information is given.

Reproducible: Always
Steps to Reproduce:
1. Do a chown root on ~/.mozilla.
2. Do a chmod go-rwx on ~/.mozilla
3. Try to start mozilla with "mozilla".

Actual Results:  
Mozilla exits immediately.

Expected Results:  
Displayed a warning, eg "You do not have access rights to ~/.mozilla, cannot start".
Duplicate of bug 243163
*** Bug 243163 has been marked as a duplicate of this bug. ***
Confirming. After removing all read/write/examine permissions from my .mozilla
directory, mozilla exits without printing any error message every time it's
launched. A trunk build of firefox does the same thing. I haven't tested
thunderbird.
Assignee: general → jag
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Apps
Ever confirmed: true
QA Contact: general → pawyskoczka
Whiteboard: good first bug
I've also experienced this bug (or a bug with the same symptoms) when my hd is
full (on linux). Mozilla or Firefox will start to execute but bail out without
any message. These symptoms are probably more related to Bug #228978 though.
Product: Core → Mozilla Application Suite
Attached patch warn (obsolete) — Splinter Review
(You don't mind if I take on this, do you Peter?)

This patch prints a warning when the profile service class fails to init, which
is most likely caused by inability to read/write the profile dir.

Mikko: I believe the behaviour you described has changed to the behaviour in
bug 297142.
Attachment #185740 - Flags: superreview?(bryner)
Attachment #185740 - Flags: review?(benjamin)
Can you explain why NS_NewToolkitProfileService is failing? Note that the patch
here is for the toolkit, and will not affect seamonkey at all.
(In reply to comment #6)
> Can you explain why NS_NewToolkitProfileService is failing? Note that the patch
> here is for the toolkit, and will not affect seamonkey at all.

NS_NewToolkitProfileService() fails because it returns the return value of
nsToolkitProfileService::Init() (when Init() fails). Init() fails when it cannot
read files inside the profile home directory.

That's all assuming I understand the code correctly, of course :)

I'll also work up a patch for seamonkey when you're satisfied with the toolkit one.
Status: NEW → ASSIGNED
Assignee: jag → baafie
Status: ASSIGNED → NEW
Comment on attachment 185740 [details] [diff] [review]
warn

This patch has several things wrong with it:

1) the message shouldn't mention anything about the "profile service": you're
exposing an implementation detail to the user.

2) The error check should check for much more specific error codes like
NS_ERROR_ACCESS_DENIED

3) This doesn't show anything on windows because of the way windows consoles
work, and normally won't show anything on mac. Use ShowOSAlert instead (but
remember that it cannot show a message larger than 255 characters).
Attachment #185740 - Flags: superreview?(bryner)
Attachment #185740 - Flags: review?(benjamin)
Attachment #185740 - Flags: review-
Attached patch address comments (obsolete) — Splinter Review
Attachment #185740 - Attachment is obsolete: true
Attachment #186705 - Flags: review?(benjamin)
Comment on attachment 186705 [details] [diff] [review]
address comments

Get rid of "NS_FAILED(rv)" since we *know* that NS_ERROR_FILE_ACCESS_DENIED is
an error code.
Attachment #186705 - Flags: review?(benjamin) → review+
Attached patch address further comment (obsolete) — Splinter Review
Attachment #186705 - Attachment is obsolete: true
Attachment #187014 - Flags: superreview?(bryner)
Comment on attachment 187014 [details] [diff] [review]
address further comment

Looks ok, too bad we don't have a way to make this be localizable.
Attachment #187014 - Flags: superreview?(bryner) → superreview+
- Is this bug still valid?
- If it is, then: Bastiaan, are you still working on it?
  - If you aren't, "Assigned To" should revert to Nobody or to the default (jag)
  - If you are, maybe the patch should be unbitrotted, then reviewed again etc., approved if necessary, and landed?
- If the bug is _not_ valid anymore, it should be resolved (e.g. WORKSFORME)
QA Contact: pawyskoczka → jag
no reply to comment #13
Assignee: b.jacques → nobody
QA Contact: jag → ui-design
I am not sure if this problem is resolved or if someone is currently working on it.
Does this block any other current revision or version (features) of seamonkey?
Duplicate of this bug: 490597
Duplicate of this bug: 494179
Is this a Toolkit bug or SeaMonkey specific? Someone please update the bug if it's more general and dupe bug 448845 here if needed.
Yes, it's a general toolkit bug and affects all mozilla products (FF/SM/TB).
Component: UI Design → Startup and Profile System
Product: SeaMonkey → Toolkit
QA Contact: ui-design → startup
Duplicate of this bug: 448845
Comment on attachment 187014 [details] [diff] [review]
address further comment

ShowOSAlert() is not a part of the current trunk. I think we may switch it to PR_fprintf() or raise some Alert dialog box (what I believe is more appropriate especially when firefox is launched from GUI/menu).
Attached patch GUI versionSplinter Review
What about this solution? A dialog windows is raised when mozilla fails to load or create a profile and quits.
Attachment #407006 - Flags: review?(benjamin)
Attachment #407006 - Flags: review?(benjamin) → review+
No sr needed, asking for check-in.
Keywords: checkin-needed
Attachment #187014 - Attachment is obsolete: true
Assignee: nobody → stransky
How about ui-review?
Didn't know such thing exist...okay, asking now.
Keywords: checkin-needed
Attachment #407006 - Flags: ui-review?(benjamin)
Comment on attachment 407006 [details] [diff] [review]
GUI version

I'm not a ui reviewer, forwarding. Johnath, this is error UI, so I'd just somebody to look over the strings.
Attachment #407006 - Flags: ui-review?(benjamin) → ui-review?(johnath)
Attachment #407006 - Flags: ui-review?(johnath) → ui-review-
Comment on attachment 407006 [details] [diff] [review]
GUI version

Wow, Martin - this got lost in my queue for far, far too long. I don't know if you're still interested in seeing this fixed, but I think it should be pretty straightforward.

>diff -r 2a772c89e07a toolkit/locales/en-US/chrome/mozapps/profile/profileSelection.properties
>+profileMissing=Profile couldn't be loaded. Probably is missing or unaccessible.
>+profileMissingTitle=Profile Missing

profileMissingTitle looks fine to me, but profileMissing isn't quite right. The other strings in the file tend to reference the application name, for one thing, and the text also contains sentence fragments.

What do you think of?

profileMissing=Your %S profile cannot be loaded. It may be missing, on inaccessible.

The string substitution would require a minor code change, too, but I think it would be more consistent with our other text in this UI.

Again, apologies for the lag, let me know what you think?
Thanks! There is the updated version attached. Actually no code changes has been needed, even the first version uses FormatStringFromName().
Attachment #421417 - Flags: ui-review?(johnath)
Comment on attachment 421417 [details] [diff] [review]
first version + string update

>diff -r abb82f981e02 toolkit/locales/en-US/chrome/mozapps/profile/profileSelection.properties
>--- a/toolkit/locales/en-US/chrome/mozapps/profile/profileSelection.properties	Thu Jan 07 09:43:41 2010 +0100
>+++ b/toolkit/locales/en-US/chrome/mozapps/profile/profileSelection.properties	Wed Jan 13 12:08:47 2010 +0100
>@@ -35,3 +35,5 @@ profileExists=A profile with this name a
> profileExistsTitle=Profile Exists
> profileFinishText=Click Finish to create this new profile.
> profileFinishTextMac=Click Done to create this new profile.
>+profileMissing=Your %S profile cannot be loaded. It may be missing, on inaccessible.
>+profileMissingTitle=Profile Missing

You copied my text, but I had a typo and a grammatical error.  :)  profileMissing has ", on" when it should read "or". So, ui-r+ but please change profileMissing to read (I've double checked, this time):

profileMissing=Your %S profile cannot be loaded. It may be missing or inaccessible.
Attachment #421417 - Flags: ui-review?(johnath) → ui-review+
Attached patch string fixedSplinter Review
string correction :)
Keywords: checkin-needed
http://hg.mozilla.org/mozilla-central/rev/c0cf6270c8f2
Status: NEW → RESOLVED
Closed: 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: good first bug → [good first bug]
Target Milestone: --- → mozilla1.9.3a3
This needs a localization note, a localizer needs to know whether the %S is an application name or a profile name. Something like this may work here:

# LOCALIZATION NOTE (profileMissing): %S is an application name
Blocks: 289631
You need to log in before you can comment on or make changes to this bug.