Show current profile name in preferences

NEW
Unassigned

Status

SeaMonkey
Preferences
--
enhancement
17 years ago
5 years ago

People

(Reporter: Ninoschka Baca, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [2012 Fall Equinox])

Attachments

(2 attachments, 7 obsolete attachments)

(Reporter)

Description

17 years ago
This is a feature request.

It would be nice look somewhere in the UI to determine what profile you are in. 

Adding it to the title bar would result in too much information and I don't know 
of any other logical area. If it was implemented wouldn't it apply to other 
components such as Browser, Composer...?
(Reporter)

Updated

17 years ago
Summary: Determining your profile with Mail open → [RFE] Determining your profile within Mail

Updated

17 years ago
Severity: normal → enhancement
OS: Windows 95 → All

Comment 1

17 years ago
I don't think we have plans to do this in this release.
Target Milestone: --- → M20
(Reporter)

Comment 2

17 years ago
The implementation of this would also effect the Browser. Some ideas discussed 
in the Mail Issues meeting today include:

1. If only 1 profile exists then don't display a profile name at all
2. If multiple profiles exist then expose the profile name in:
   - the menu, Edit|Preferences for <Profile Name>
   - In the title region of the preferences window, it could display
     "Preferences for <Profile Name>"
Assignee: putterman → ben

Updated

17 years ago
Component: Mail Window Front End → Browser-General
Product: MailNews → Browser
Target Milestone: M20 → Future
Component: Browser-General → Mail Window Front End
Product: Browser → MailNews
Assignee: ben → sspitzer
QA Contact: lchiang → esther
This can be done. Just ask the profile manager back end for the profile name.
Over to Mail FE...
Product: Browser → Seamonkey

Updated

12 years ago
Assignee: sspitzer → mail
Assignee: mail → nobody
Priority: P3 → --
QA Contact: esther → message-display
Summary: [RFE] Determining your profile within Mail → Determining your profile within Mail
Target Milestone: Future → ---

Comment 4

8 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED

Comment 5

8 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 6

8 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 7

8 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 8

8 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 9

8 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 10

8 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 11

7 years ago
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → EXPIRED

Comment 12

6 years ago
Still a valid enhancement request, especially see comment 3.
Status: RESOLVED → REOPENED
Component: MailNews: Message Display → Preferences
Ever confirmed: true
QA Contact: message-display → preferences
Resolution: EXPIRED → ---

Updated

6 years ago
Status: REOPENED → NEW
FYI: We have Help / Troubleshooting Information on trunk now, so there's at least a way to determine which profile is currently in use for the active session. It's not displaying the profile name, though.

Comment 14

6 years ago
Well, you could open "Tools->Switch Profile" to see the currently running profile - but displaying the name in the preferences would be a nice solution.
Summary: Determining your profile within Mail → Show current profile name in preferences

Comment 15

6 years ago
Toolkit profiles don't necessarily have a name. What should you do then?

Comment 16

6 years ago
You can only show what you have, of course.
Showing the path etc. of profiles unknown to the profile manager is not useful, imo. We should depend upon the profile manager's knowledge of things here.

Updated

6 years ago
Assignee: nobody → ewong
Status: NEW → ASSIGNED
Created attachment 519095 [details] [diff] [review]
Show current profile name in preferences. (v1)
Attachment #519095 - Flags: review?(iann_bugzilla)
(In reply to comment #17)
> Created attachment 519095 [details] [diff] [review]
> Show current profile name in preferences. (v1)

Nice!

Nits:
1. I suggest adding double quotes around the profile name and/or putting a "profile " in front of it. Otherwise it might confuse users depending on how the named their profile. E.g. I always name my fresh profile "fresh" so the dialog title was "Preferences for fresh"...
2. the "g" prefix in gProfileSrvc suggests this is a global variable, but currently it's not.

Comment 19

6 years ago
Comment on attachment 519095 [details] [diff] [review]
Show current profile name in preferences. (v1)

>+++ b/suite/common/pref/preferences.js
>+function StartUp()
>+{
>+  gProfileSrvc = Components.classes["@mozilla.org/toolkit/profile-service;1"]
>+                           .getService(Components.interfaces.nsIToolkitProfileService);
Need to define the variable, not global so var profileSrvc perhaps? Not sure if Services.jsm offers this one as a service.

>+  var selectedProfile = null;
>+
>+  selectedProfile = gProfileSrvc.selectedProfile;
Why setting to null and then from the profile service? Should we be looking at having a try/catch? We only use selectedProfile the once so why not just get selectedProfile.name from the beginning, then only do the following if it is not null?

>+  var prefStrBundle = document.getElementById("bundle_prefutilities");
>+  var prefProfile = prefStrBundle.getFormattedString("preferencesAccount",
>+                                                        [selectedProfile.name]);
Nit: needs lining up.
>+
>+  var p = document.getElementById("prefDialog");
>+  p.setAttribute("title", prefProfile);
Nit: inline, setting the var p offers no additional readability.
>+}

>+++ b/suite/common/pref/preferences.xul
> <prefwindow id="prefDialog" 
>             xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
>-            title="&prefWindow.title;" 
If for some reason we cannot get the selectedProfile.name perhaps best leaving a default here.
>             style="&prefWindow.size;"
>             windowtype="mozilla:preferences"
>             buttons="accept,cancel,help"
>-            autopanes="true"> 
>+            autopanes="true"
>+            onload="StartUp()"> 
Nit: missing ;
Attachment #519095 - Flags: review?(iann_bugzilla) → review-
Created attachment 519331 [details] [diff] [review]
Show current profile name in preferences. (v2)
Attachment #519095 - Attachment is obsolete: true
Attachment #519331 - Flags: review?(iann_bugzilla)

Comment 21

6 years ago
Comment on attachment 519331 [details] [diff] [review]
Show current profile name in preferences. (v2)

>+function StartUp()
>+{
>+  var profileSrvc = Components.classes["@mozilla.org/toolkit/profile-service;1"]
>+                             .getService(Components.interfaces.nsIToolkitProfileService);
Nit: needs lining up.
>+  var selectedProfile = profileSrvc.selectedProfile.name;
Here, if we are worried about not getting the information (as in profileSelection.js), I would do something like:

var selectedProfile = null;
try
{
  selectedProfile = profileSrvc.selectedProfile.name;
}
catch (e) {}

if (selectedProfile)
{
  var prefProfile = document.getElementById("bundle_prefutilities")
                            .getFormattedString("preferencesAccount",
                                                [selectedProfile]);
  document.getElementById("prefDialog").setAttribute("title", prefProfile);
}

(Could even use "let" instead of "var" within the if statement).

r=me with that fixed/addressed
Attachment #519331 - Flags: review?(iann_bugzilla) → review+

Comment 22

6 years ago
> try
> {
>   selectedProfile = profileSrvc.selectedProfile.name;
> }
> catch (e) {}
Hmm. Does the nsIToolkitProfileService potentially throw here?

Comment 23

6 years ago
(In reply to comment #22)
> > try
> > {
> >   selectedProfile = profileSrvc.selectedProfile.name;
> > }
> > catch (e) {}
> Hmm. Does the nsIToolkitProfileService potentially throw here?

We protect against it in profileSelection.js, so I would say yes, seems to be some sort of similar protection in toolkit js files too.
(In reply to comment #18)
> 1. I suggest adding double quotes around the profile name and/or putting a
> "profile " in front of it. Otherwise it might confuse users depending on how
> the named their profile. E.g. I always name my fresh profile "fresh" so the
> dialog title was "Preferences for fresh"...

Ian, what's your opinion about this?

Comment 25

6 years ago
(In reply to comment #24)
> (In reply to comment #18)
> > 1. I suggest adding double quotes around the profile name and/or putting a
> > "profile " in front of it. Otherwise it might confuse users depending on how
> > the named their profile. E.g. I always name my fresh profile "fresh" so the
> > dialog title was "Preferences for fresh"...
> 
> Ian, what's your opinion about this?

I think Edmund addressed this with the change to "Preferences for profile %S" and I am happy with that.
(In reply to comment #25)
> I think Edmund addressed this with the change to "Preferences for profile %S"
> and I am happy with that.

Oops, missed that change, sorry. Alright then!
Created attachment 519645 [details] [diff] [review]
Show current profile name in preferences. (v3)
Attachment #519331 - Attachment is obsolete: true
Attachment #519645 - Flags: review?(iann_bugzilla)

Comment 28

6 years ago
Comment on attachment 519645 [details] [diff] [review]
Show current profile name in preferences. (v3)

r=me though you might find that the patch for prefutilities.properties
 has been bitrotted.
Attachment #519645 - Flags: review?(iann_bugzilla) → review+

Updated

6 years ago
Attachment #519645 - Flags: ui-review?(neil)
Comment on attachment 519645 [details] [diff] [review]
Show current profile name in preferences. (v3)

>+function StartUp()
Startup please.

>+  try
>+  {
>+    selectedProfile = profileSrvc.selectedProfile.name;
>+  }
>+  catch (e) {}
>+
>+  if (selectedProfile)
>+  {
>+    let prefProfile = document.getElementById("bundle_prefutilities")
>+                              .getFormattedString("preferencesAccount",
>+                                                  [selectedProfile]);
Can you not do this inside the try/catch instead of using a separate if?

>+    document.getElementById("prefDialog").setAttribute("title", prefProfile);
Use document.title
Created attachment 520489 [details] [diff] [review]
Show current profile name in preferences. (v4)
Attachment #519645 - Attachment is obsolete: true
Attachment #520489 - Flags: ui-review?(neil)
Attachment #520489 - Flags: review+
Attachment #519645 - Flags: ui-review?(neil)
Comment on attachment 520489 [details] [diff] [review]
Show current profile name in preferences. (v4)

I tried this out, and it doesn't actually work, because profileSrvc.selectedProfile is the last one you chose in the profile manager; if you use -P <name> to choose a profile, it bypasses that, and you get the wrong profile name. (And I don't know what you're supposed to do if you use -profile to choose a profile...)

>+  try
>+  {
>+    selectedProfile = profileSrvc.selectedProfile.name;
>+    if (selectedProfile)
[Do you need the if?]

>+    {
>+      let prefProfile = document.getElementById("bundle_prefutilities")
>+                                .getFormattedString("preferencesAccount",
>+                                                    [selectedProfile]);
>+      document.title = prefProfile;
[Hardly worth the variable!]
Attachment #520489 - Flags: ui-review?(neil) → ui-review-
(In reply to comment #31)
> I tried this out, and it doesn't actually work, because
> profileSrvc.selectedProfile is the last one you chose in the profile manager

How about this:

1. Use profileSrvc.profiles (which is an nsISimpleEnumerator) to go through the nsIToolkitProfile objects
http://mxr.mozilla.org/mozilla-central/source/toolkit/profile/nsIToolkitProfileService.idl#51

2. Determine the current one by comparing the .rootDir property of the loop variable to the current profile's (from dirsvc "ProfD")
http://mxr.mozilla.org/mozilla-central/source/toolkit/profile/nsIToolkitProfile.idl#83
http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/content/aboutSupport.js#463

3. Get the name using .name
http://mxr.mozilla.org/mozilla-central/source/toolkit/profile/nsIToolkitProfile.idl#94
Created attachment 523297 [details] [diff] [review]
Show current profile name in preferences. (v5)
Attachment #520489 - Attachment is obsolete: true
Attachment #523297 - Flags: review?(iann_bugzilla)
Comment on attachment 523297 [details] [diff] [review]
Show current profile name in preferences. (v5)

credit goes to InvisibleSmiley.
Created attachment 523299 [details] [diff] [review]
Show current profile name in preferences. (v6)
Attachment #523297 - Attachment is obsolete: true
Attachment #523299 - Flags: review?(iann_bugzilla)
Attachment #523297 - Flags: review?(iann_bugzilla)
Created attachment 523301 [details] [diff] [review]
Show current profile name in preferences. (v7)

w/ changes mentioned on IRC by InvisibleSmiley
Attachment #523299 - Attachment is obsolete: true
Attachment #523301 - Flags: review?(iann_bugzilla)
Attachment #523299 - Flags: review?(iann_bugzilla)
Comment on attachment 523301 [details] [diff] [review]
Show current profile name in preferences. (v7)

Who ever gets to review this first... Contains string changes, so either makes b3 (within 24h) or will miss 2.1.
Attachment #523301 - Flags: review?(neil)
Comment on attachment 523301 [details] [diff] [review]
Show current profile name in preferences. (v7)

If there is only one profile, should we still display it?

>+    if (profile.rootDir.path == compTarget) {
Don't compare paths, use nsIFile's equals method instead.

>+  try
Don't need this try/catch.
Comment on attachment 523301 [details] [diff] [review]
Show current profile name in preferences. (v7)

>+preferencesAccount=Preferences for Profile %S
This doesn't look quite right to me. I notice that comment 25 has the word "profile" in lower case, which should help. (Or there's always "%S".)
(In reply to comment #39)
> >+preferencesAccount=Preferences for Profile %S
> This doesn't look quite right to me. I notice that comment 25 has the word
> "profile" in lower case, which should help.

That was my fault, I gave ewong the advice on IRC because I assumed we'd like to go with title case for the dialog heading.

> (Or there's always "%S".)

Right, which is what I suggested in comment 24. Either way.
(In reply to comment #38)
> Comment on attachment 523301 [details] [diff] [review]
> Show current profile name in preferences. (v7)
> 
> If there is only one profile, should we still display it?

I believe it'd be consistent if it was available.
Created attachment 523493 [details] [diff] [review]
Show current profile name in preferences. (v8) [Checkin: comment 44]
Attachment #523301 - Attachment is obsolete: true
Attachment #523493 - Flags: review?(iann_bugzilla)
Attachment #523301 - Flags: review?(neil)
Attachment #523301 - Flags: review?(iann_bugzilla)

Updated

6 years ago
Attachment #523493 - Flags: review?(iann_bugzilla) → review+

Updated

6 years ago
Attachment #523493 - Flags: ui-review?(neil)

Updated

6 years ago
Attachment #523493 - Flags: ui-review?(neil) → ui-review+
Or maybe "Preferences for %s profile" ?
Comment on attachment 523493 [details] [diff] [review]
Show current profile name in preferences. (v8) [Checkin: comment 44]

http://hg.mozilla.org/comm-central/rev/9b1e4c3f6bcf

With comment 43 incorporated after r=IanN over IRC for the change.
Attachment #523493 - Attachment description: Show current profile name in preferences. (v8) → Show current profile name in preferences. (v8) [Checkin: comment 44]
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago6 years ago
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.1b3

Updated

6 years ago
Depends on: 648086

Comment 45

6 years ago
I backed this out in bug 648086:
http://hg.mozilla.org/comm-central/rev/813c489a99d0
http://hg.mozilla.org/releases/comm-2.0/rev/ef507802e7e9
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
From https://bugzilla.mozilla.org/show_bug.cgi?id=648086#c5, 
should a flex'd (centered) label below the PrefWindow Title but above
both the left and right pane of the preferences window? 
ie.

PrefWindow Title--------------------------------------------------------------|
[ for profile 'profilename'                                                  ]|
|------------------------|  Browser                                           |
|Category                |                                                    |

Or will it push the category tree list and right pane down too much?

Updated

6 years ago
Status: REOPENED → ASSIGNED
Created attachment 531540 [details] [diff] [review]
Show current profile name in preferences. (v9) (revisited)
Attachment #531540 - Flags: review?(iann_bugzilla)

Updated

6 years ago
Attachment #531540 - Flags: review?(iann_bugzilla) → feedback?

Updated

6 years ago
Attachment #531540 - Flags: feedback? → feedback?(iann_bugzilla)

Comment 48

6 years ago
Comment on attachment 531540 [details] [diff] [review]
Show current profile name in preferences. (v9) (revisited)

Sorry, but just does not look right and pushes stuff too far down.
Attachment #531540 - Flags: feedback?(iann_bugzilla) → feedback-
completely stuck on this.  unassigning myself in hopes someone will have a better go at it.
Assignee: ewong → nobody
Status: ASSIGNED → NEW

Updated

5 years ago
Whiteboard: [2012 Fall Equinox]
Target Milestone: seamonkey2.1b3 → Future
You need to log in before you can comment on or make changes to this bug.