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
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.
(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.
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
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).
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+
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?
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
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).
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)
No sr needed, asking for check-in.
Attachment #187014 - Attachment is obsolete: true
How about ui-review?
Didn't know such thing exist...okay, asking now.
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+
string correction :)
Status: NEW → RESOLVED
Closed: 10 years ago
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
You need to log in before you can comment on or make changes to this bug.