Closed Bug 253950 Opened 20 years ago Closed 19 years ago

When the default profile is locked on startup, UI needs to be less confusing

Categories

(Toolkit :: Startup and Profile System, defect)

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

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.8beta2

People

(Reporter: harry, Assigned: benjamin)

References

Details

Attachments

(2 files)

Open a simple dialog "cannot open Firefox" instead of the profile manager
28.08 KB, patch
benjamin
: first-review+
darin.moz
: second-review+
Details | Diff | Splinter Review
Dialog
4.31 KB, image/png
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616
Build Identifier: 

When you start up Firefox, if the existing profile is locked, Firefox brings up
a Choose User Profile wizard without explaining why.  I've found that novice
users are completely bewildered by this dialog and often end up creating a new
profile without understanding what they are doing.  In our environment the
browser then doesn't work, because the new profile doesn't have the correct
proxy server configuration, and I then have to fix it for them - this is
creating a lot of work for me!


Reproducible: Always
Steps to Reproduce:
1. Create a dummy .parentlock symlink in your default profile to 0.0.0.0:0
2. Launch Firefox.

Actual Results:  
The Choose User Profile dialog appeared.

Expected Results:  
Bring up a window explaining that the browser can't be started because it is
already in use.  If it is on a remote computer, tell the user what computer it
is running on (reverse DNS lookup on the IP address) and suggest that they try
logging into that computer instead of the one they're on.  Also explain how to
delete the lock file, or provide a button to do it for them (with appropriate
warnings!).

If the user already has multiple profiles, it would be appropriate to allow them
to choose a different one or create a new one as it can then be assumed that
they know what they're doing.

However, if they currently only have one profile, they should not be
automatically offered the option to create a new one; instead, provide an Expert
or Advanced button leading to the create profile dialog.  If they still get into
trouble, at least they were warned!


This is related to 151188, the status of that bug dictates the best advice to
provide the user.  However, even if that bug is fixed (so that this situation
will usually only occur if there really is another instance of the browser
running) the user should be advised to shut down the other browser and
discouraged from creating a new profile unless they really know what they're doing.
Oops, the dummy .parentlock symlink has to identify a real computer or a live
process on the computer you're on.
confirming. should show explanation what's wrong.
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Not major, and not going to make 1.0. Patches welcome.
Severity: major → normal
Keywords: helpwanted
This often happens when there's a phantom process remaining (but no window). Is
it possible to make this process open a new window? If so, selecting an in-use
profile in the profile manager should cause a new window to be opened under that
profile.
In mu humble opinion Profile Manager should not appear if it wasn't invoked by
the user. If user just started firefox process, without -P switch, he does not
want profile manager.

On windows and mac (if I remember correctly) a phantom process running (as
explained by comment 4) simply means that firefox crashed. I've been thinking,
is it possible to automatically kill such process? At least it's a fair attempt
to recover from the problem.

Still, a simple dialog "firefox b0rked" would be more informative than a profile
manager in such situation. Even a most noobish user would know a solution -
restart computer. And it would work.
I just helped an 11-year-old who hit this problem (accidentally created a new
profile when his was locked, couldn't figure out how to get back to the old
profile).
*** Bug 274678 has been marked as a duplicate of this bug. ***
I agree it IS major.

Now, can we at least discuss possible solutions? My opionon is as follows:
firefox should NOT pop up profile manager in such case at all. I know it's
logical from programmer's point of view but it's completely illogical from
user's point of view.
What to do instead?
On windows, such situation can only occour if firefox crashed. Would it be
possible to kill firefox' process (which is already known to not respond to 'new
window' request) and re-try? It seems like a good solution to me.

Alternatively, firefox could just popup an error dialog and exit. It doesn't
look good but at least it would be possible to reboot computer and recover.

Any thoughts? Everything is better than profile manager, imho.
(In reply to comment #9)
> On windows, such situation can only occour if firefox crashed. Would it be
> possible to kill firefox' process (which is already known to not respond to 'new
> window' request) and re-try? It seems like a good solution to me.

I agree. If the old process is *always* of no value it should just be euthanased
and a new process started up - this would be the most seamless solution from the
user's perspective.
I think bug 263988 is a duplicate of this bug, (and probably more). 
I've found some pop-ups will cause the problem, firefox keeps running after it
is closed. When firefox restarted and profile prompt appears, close firefox,
goto task manager and stop firefox.exe, then you can restart firefox with no
profile prompt
I am nominating this for 1.1 blocking because it appears to be a huge support
issue -- people getting the profile manager dialog box and not knowing what to
do, creating a new profile and "losing" their settings and bookmarks.

Seems there is two options -

1)  Can we "kill" the firefox.exe process that is running and proceed normally
2)  A poorer option, but maybe the only one that is workable would be to force a
restart of the machine.  Message box would have to indicate that something has
gone wrong and this is required.  This sounds drastic but I think is FAR, FAR
better than current implementation, simply b/c once machine is restarted,
everything appears normal again, no other user action needed
Flags: blocking-aviary1.1?
This is on my 1.1 target list.
Flags: blocking-aviary1.1? → blocking-aviary1.1+
Target Milestone: --- → Firefox1.1
A lot of the comments lately have been ignoring the fact that the profile lock
won't necessarily be held by a process on the local machine.  Please keep this
in mind!

Also note that bug 263988 is not a duplicate of this issue.  This report was
about a UI issue which should be relatively easy to fix, not the more
complicated issue that Firefox sometimes mistakenly believes a profile to be in
use when it isn't.  In particular, resolving the latter problem won't fix the
former, because of the case when the profile really is still in use on another
computer.

The profile locking system does need to be fixed (ideally multiple Firefox
processes on the same or multiple computers should be able to share a profile
nicely) but this is a separate issue so it should be dealt with as a separate bug.

  Harry.

(In reply to comment #14)
> A lot of the comments lately have been ignoring the fact that the profile lock
> won't necessarily be held by a process on the local machine.  Please keep this
> in mind!

Actually, let me dissagree: if profile is locked because of a remote machine,
attempting to kill firefox.exe (on local machine) as well as displaying "it's
b0rked" dialog, are as valid as before. Of course kill attempt fails, yes, but
at least we tried.

As for my "harmless" above - I bet you can invent a situation when it isn't (I
can) but make sure that situation is any realistic.
Ooops, too much editing before sending the comment - last paragraph should read:
"I bet you can invent a situation when it isn't safe to kill local firefox.exe
when it was a remote machine that was keeping the desired profile locked, but
make sure that situation is any realistic."

Apologies for the bugspam.
> Actually, let me dissagree: if profile is locked because of a remote 
> machine, attempting to kill firefox.exe (on local machine) as well 
> as displaying "it's b0rked" dialog, are as valid as before. Of course 
> kill attempt fails, yes, but at least we tried.

The nature of the locking file allows firefox to distinguish between the local
and remote cases, so there's no point in trying to find a local instance of
firefox to kill if the lock is remote.  In the local case this is perfectly
sensible.  (Again, though, this suggestion really belongs with a different bug
report.)

"It's borked" is not a helpful message IMO.  At least in the remote case the
dialog needs to explain that only one instance of firefox is allowed at a time,
and preferably attempt to tell the user which computer the other instance is
allegedly running on.

  Harry.

(In reply to comment #6)
> I just helped an 11-year-old who hit this problem (accidentally created a new
> profile when his was locked, couldn't figure out how to get back to the old
> profile).

Could have been worse. Could have deleted profile. Don't put it past someone to
think that "profile"="running version".
Blocks: 272882
(In reply to comment #20)

> https://bugzilla.mozilla.org/show_bug.cgi?id=272882 &
> https://bugzilla.mozilla.org/show_bug.cgi?id=221245  are unresolvable because of
> this bug.

I don't see any connection between this bug and these ones.  What do you mean?
No longer blocks: 272882
I would just like to add that somehow, firefox doesn't show the profile manager
anymore in this case (I guess this is related to the single profile mode? Or
maybe my use of a shorcut with "-profile" to force my profile on my network
share?). Firefox just silently fails... I tried to delete my profile to find out
that some files were locked, then tought it was probably because I was logged on
with firefox on another computer.

If I saw that profile manager thingy, maybe I would have tought sonner what was
wrong. Any error message is better than nothing :)

Nothing important was in my profile, so it's not like I care much, you devs
don't need to worry :)
(In reply to comment #12)
> I am nominating this for 1.1 blocking because it appears to be a huge support
> issue -- people getting the profile manager dialog box and not knowing what to
> do, creating a new profile and "losing" their settings and bookmarks.
> 
> Seems there is two options -
> 
> 1)  Can we "kill" the firefox.exe process that is running and proceed normally
> 2)  A poorer option, but maybe the only one that is workable would be to force a
> restart of the machine.  Message box would have to indicate that something has
> gone wrong and this is required.  This sounds drastic but I think is FAR, FAR
> better than current implementation, simply b/c once machine is restarted,
> everything appears normal again, no other user action needed


A third option:

3. Put in a button in the profile manager which will "Attempt to kill all open
Firefox processes and restart Firefox with default profile."

This would probably fix 99% of the cases of problems.
Blocks: 263988
*** Bug 263988 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Keywords: helpwanted
This patch makes it so that the profile manager is not shown unless the user
explicitly asks for it using -P or -profilemanager. Instead, a simple dialog
box says "Firefox is already running, but is not responding. To open a new
window, you must restart Firefox. [OK]".

There is also glue for a platform-specific ability for this dialog to show two
buttons:

[Cancel] [Restart Firefox]

This ability, however, is not yet implemented on any platform. I hope to have
it implemented on windows for 1.8, and perhaps unix.
Attachment #177511 - Flags: review?(bugs)
Attached image Dialog — 

    
    

    
  
Comment on attachment 177511 [details] [diff] [review]
Open a simple dialog "cannot open Firefox" instead of the profile manager

r=ben@mozilla.org for the UI/AppRunner sections.

        Attachment #177511 -
        Flags: review?(bugs) → review+

    
  
Component: Startup and Profile System → XRE Startup
Flags: review+
Flags: blocking-aviary1.1+
Product: Firefox → Toolkit
Target Milestone: Firefox1.1 → mozilla1.8beta2

    
    

    
  
Comment on attachment 177511 [details] [diff] [review]
Open a simple dialog "cannot open Firefox" instead of the profile manager

Oops, changing products changes review flags.

        Attachment #177511 -
        Flags: second-review?(darin)

        Attachment #177511 -
        Flags: first-review+

    
    

    
  
Comment on attachment 177511 [details] [diff] [review]
Open a simple dialog "cannot open Firefox" instead of the profile manager

>Index: profile/dirserviceprovider/src/nsProfileLock.cpp

>+nsresult nsProfileLock::Lock(nsILocalFile* aProfileDir,
>+                             nsIProfileUnlocker* *aUnlocker)

nit: "* *" is an odd convention.


>Index: profile/dirserviceprovider/src/nsProfileLock.h

>+     * @param aUnlocker    [out] Optional. This is only returned when locking
>+     *                     fails with NS_ERROR_FILE_ACCESS_DENIED, and may not
>+     *                     be returned at all.
>+     * @throws NS_ERROR_FILE_ACCESS_DENIED if the profile is locked.
>+     */
>+    nsresult                Lock(nsILocalFile* aProfileDir, nsIProfileUnlocker* *aUnlocker);

If this were a XPCOM interface, then we'd have trouble mixing
exceptions with valid out params.  Not an issue here, but if
we ever convert this method to IDL, we'd want to return the
locked state using a boolean out param instead.


>Index: profile/public/nsIProfileUnlocker.idl

>+ * The Original Code is Mozilla XULRunner.

nit: Is it really?


>+  /**
>+   * Attempt to unlock the specified profile by attempting or forcing the

nit: "Try to unlock..." (so you avoid saying "Attempt" again.)


>Index: toolkit/locales/en-US/chrome/mozapps/profile/profileSelection.properties

>-profileLocked=%S cannot use the profile "%S" because it is in use.\n\nPlease choose another profile or create a new one.
>+profileLocked2=%S cannot use the profile "%S" because it is in use.\n\nTo continue, close the running instance of %S or choose a different profile.

nit: why change the name of the key?


>Index: toolkit/profile/public/nsIToolkitProfile.idl

> [scriptable, uuid(87cea5c2-b9ed-44f9-8984-e75bc9f7134a)]
> interface nsIToolkitProfile : nsISupports
...
>-    nsIProfileLock lock();
>+    nsIProfileLock lock(out nsIProfileUnlocker aUnlocker);

ding!  must rev interface's uuid.


>Index: toolkit/xre/nsAppRunner.cpp

>+static const char kProfileProperties[] = "chrome://mozapps/locale/profile/profileSelection.properties";

nit: wrap long lines to 80 chars


>+static nsresult
>+ProfileLockedDialog(nsILocalFile* aProfileDir, nsIProfileUnlocker* aUnlocker,
>+                    nsINativeAppSupport* aNative, nsIProfileLock* *aResult)
>+{
>+  nsresult rv;
>+
>+  nsCOMPtr<nsILocalFile> lf;
>+
>+  {
>+    ScopedXPCOMStartup xpcom;

nit: why is this level of scoping needed?  seems to me that you
can do away with it.


>+      PRUint32 flags = nsIPromptService::BUTTON_TITLE_OK * nsIPromptService::BUTTON_POS_0;

nit: wrap long lines (ditto elsewhere)


should there have been an implementation of nsIProfileUnlocker?


r=darin with nits picked

        Attachment #177511 -
        Flags: second-review?(darin) → second-review+

    
    

    
  
> >+ * The Original Code is Mozilla XULRunner.
> 
> nit: Is it really?

I wrote it from scratch, and it's part of XULRunner, so sure.

> nit: why change the name of the key?

Actually, I need to post this as a new policy. When changing the meaning or %S
formatting of a localized string, you must change the name, so that our
automated comparison tools can detect localizations which haven't changed to be
out of date. It's similar to a uuid change, in that respect.

> should there have been an implementation of nsIProfileUnlocker?

I'm going to leave that as a set of platform-specific bugs... I tried to write
one for windows, but got locked up in 7 hours of undocumented windows API hell.
Dbradley indicated he could help.

Fixed on trunk.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED

    
  
Blocks: 286355

    
    

    
  
*** Bug 248830 has been marked as a duplicate of this bug. ***

    
  
Blocks: 288458

    
    

    
  
*** Bug 301118 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 301323 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 301803 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 326832 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 328460 has been marked as a duplicate of this bug. ***

    
    

    
  
is there a way to get the defualt profile back?

if so could someone explain it in terms someone with basic computer knowledge could understand, it would be much appreciated. 



    
    

    
  
*** Bug 319002 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 316514 has been marked as a duplicate of this bug. ***

    
  
Component: XRE Startup → Startup and Profile System
QA Contact: benjamin → startup

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: