64230 - Need to know which account is default when you have multiple mail accounts

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Account Configuration, defect, P2)

Description

[esther]

Taken from bug 45695 so it can be fixed earlier than other issues in that bug.
In Account Settings dialog, Indicate which account is the default. Parenthesis
around the word 'default following the account, "(Default)" following account
name. If that is not possible, bold the account name of the default account. (P2).

Comment 1

[scottputterman]

marking nsbeta1+ and moving to mozilla0.8. reassigning to racham

Comment 2

[scottputterman]

moving to mozilla0.9

Comment 3

[Sheela Ravindran]

cc myself

Comment 4

[Ninoschka Baca]

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

Comment 5

[scottputterman]

marking nsbeta1- and moving to future milestone.

Comment 6

[Curtis Nelson]

Not sure if this is the bug to add this to, but it seems like in addition to
knowing what account is the default, the default should actualy be used "by
default" when sending email from the browser.  If I'm viewing my secondary email
account, switchover to the browser, find a nice site, send the link to a friend,
shouldn't the default account be used?  At the moment, the current active
account in the mail screen is used.

Comment 7

[Ninoschka Baca]

The following description is by design.

If Mail and the Browser are open at the same time, then a Send Page from the
browser determines what mail account is currently selected and prefills the new
message/compose window with that account's address.

If only the Browser is open then a Send Page would use the default mail account
since it has no way to determine which account to use.

Comment 8

[jglick]

Default account should look like: "<AccountName> (Default)"

Comment 9

[(not reading, please use [e-mail] instead)]

taking.

Comment 10

[varada]

Attachment: Patch V1.0

Set the label for the default account to include the "(default)" string. When
there is a change in default accounts remove the label from the old default and
then set the label for the new account.

Comment 11

[varada]

re-assigning to varada as per putterman.

Comment 12

[varada]

Attachment: Patch V1.1

"(default)" should be removed from old default account when new default account
is set.

Comment 13

[(not reading, please use [e-mail] instead)]

some initial comments:

1) you are just adding and removing "(default)" from the treecells, yet this
tree is built from rdf.  What happens when the xul template is rebuilt?  (is it
rebuilt on add or remove server?)  I'm worried that the label changes will be
blow away if the tree is rebuilt from the datasource.

2) even if we do it this way, what if the pretty name contains (default) [say
the user set the pretty name that way.]  This code will break.

3) even if we do it this way, "(default)" is hard coded instead of in a string
bundle.

4) is the account manager tree wide enough to see the "(default)" string that
you added?  I think it won't be, and it will be cropped (and therefore what's
the point, since we can't resize the tree?)  can you screen shot how this looks?
 I think we're going to need change some widths, which will affect some panels.

More advanced things:

5) currently, it looks like settings as default is not something that "cancel"
will undo.  (related, removing an account or adding an account is also not
undone by cancel.)  let's check with jglick.  how we fix this bug depends on
this decision.

6) while you're here:  we should be disabling the default button if the selected
account is default.

7) while you're here:  what happens if we delete the default account?  do we
choose a new default?

8) while you're here:  do we re-sort the folder pane after we change the default
account?

Comment 14

[jglick]

Attachment: Example

>4) is the account manager tree wide enough to see the "(default)" string that
>you added?  I think it won't be,

I think you're right, in many cases it won't be wide enough. Other options
would be to make the default account Bold, but that makes the width issue
(cropping of acct name) worse. How about a "*" to the left of the account name?
On the left so it is always visible, even if text gets cropped.

1)*AccountName (no space)
Or
2)* AccountName (space)
Plus
3)Add a "*" to the "Default" button

Thoughts?

Comment 15

[jglick]

>5) currently, it looks like settings as default is not something that "cancel"
>will undo.  (related, removing an account or adding an account is also not
>undone by cancel.)

Ideally, "Cancel" should cancel any actions taken by the user. But, we aren't 
consistent in prefs. Actions taken on text fields, check/radio buttons, menu 
buttons in prefs seem to accurately be canceled if you Cancel Prefs. But 
clicking buttons that cause actions and then clicking Cancel doesn't always seem 
to work in Prefs (like Clear History).

>6) we should be disabling the default button if the selected account is 
>default.

Agree.

>7) what happens if we delete the default account?  do we choose a new default?

Yes, next account down becomes default. We need to have a default account, 
correct?

>8) do we re-sort the folder pane after we change the default account?

No. Default account doesn't haven't to be the first account in folder pane. 
Eventually, we should have Move Up/Down buttons in Acct Settings so users can 
re-order accts. When accounts are re-ordered in Acct Settings, we would update 
the folder pane to reflect that order.

Comment 16

[timeless]

*s look bad, let's try bold?

Comment 17

[jglick]

Attachment: Example 2

4. Default acct as bold text example. Yeah, i guess bold works too. It does
take up more horizontal space, but doesn't really matter since there is no
"(Default)" at the end to get cropped.

Either the * or the bold indicator is fine with me.

Comment 18

[Scott Brawner]

>The following description is by design.

>If Mail and the Browser are open at the same time, then a Send Page from the
>browser determines what mail account is currently selected and prefills the new
>message/compose window with that account's address.

The same does not happen when merely clicking on a link within a web page. The
default account is always used. Shouldn't these types of thing be consistent
with each other? Should another bug be opened about this?

Comment 19

[(not reading, please use [e-mail] instead)]

taking all of varada's bugs.

Comment 20

[Samir Gehani]

Mail triage team: nsbeta1+/adt3

Comment 21

[Stefan Borggraefe]

>6) we should be disabling the default button if the selected account is 
>default.

This was fixed with the checkin for bug 140649.

Comment 22

[Stefan Borggraefe]

Attachment: Make the default account bold in Account Manager

Tested the following:
- Setting accounts as Default Account
- Removing accounts: When the default account is deleted the first account    
  becomes the new Default Account. When there are no more accounts with an
  incomingServer with canBeDefaultServer == true, the "Local Folders" account
  becomes the new Default Account.
- Adding accounts: There is one situation where a new default account is
elected
  after doing this. When you deleted all accounts, the Local Folders account
  is the default account. Now create a new account, that has the ability to
  be the default account. It becomes the new default account immediatly.
  Because of this markDefaultAccount() has to be called in onAddAccount().

I think this looks all correct.

Comment 23

[Stefan Borggraefe]

Taking bug.

Comment 24

[Stefan Borggraefe]

Attachment: Corrected patch

Sorry, I uploaded the wrong patch the first time.

Comment 25

[[e-mail]]

Comment on attachment 135475 [details] [diff] [review]
Corrected patch

You should use <treecell properties="isDefaultServer-rdf:<blurb>"/> to
automatically set the isDefaultServer-true property on the treecell when the
tree loads (and if you're lucky, when you change the default). See
folderPane.xul for how these properties work.

Comment 26

[Stefan Borggraefe]

Attachment: Use the RDF datsource directly to style the default account

Like Neil said. Works great. :-)

I removed the IsDefaultServer attribute from the treeitem, because it is
unused.

Comment 27

[[e-mail]]

Comment on attachment 135905 [details] [diff] [review]
Use the RDF datsource directly to style the default account

Mozilla's themes don't use "bolder" - please change it to "bold".

The old IsDefaultServer dates back to 2000-04-17 when we didn't have an
outliner. Unfortunately the CSS was split up on 2001-08-31 but I guess that
attribute used to have some CSS that got lost.

Comment 28

[Stefan Borggraefe]

Comment on attachment 135905 [details] [diff] [review]
Use the RDF datsource directly to style the default account

I'll change the CSS from bolder to bold before checkin.

Comment 29

[Stefan Borggraefe]

Comment on attachment 135905 [details] [diff] [review]
Use the RDF datsource directly to style the default account

Requesting approval for 1.6b. Nice UI-enhancement (you now get visual feedback
when pressing "Set as Default" and you can identify the default account much
easier), very low risk.

Comment 30

[Asa Dotzler [:asa]]

Comment on attachment 135905 [details] [diff] [review]
Use the RDF datsource directly to style the default account

a=asa (on behalf of drivers) for checkin to 1.6 beta.

Comment 31

[Stefan Borggraefe]

Attachment: Patch with the change bolder -> bold

Otherwise unchanged. So this has r/sr/a.

Comment 32

[Christian :Biesinger (don't email me, ping me on IRC)]

checked in

Comment 33

[Frederic Bezies]

This causes a big bad xul error in Thunderbird CVS builds.

Just look at this thread for a screenshot :

http://forums.mozillazine.org/viewtopic.php?p=272654

Comment 34

[Mickey Stein]

Confirming #33's regression. Built today on fedora core 1 , gcc 3.3.2, optimized
for athlon xp & sse. Exact same error as #33.

Comment 35

[Mickey Stein]

Adding these 3 lines to AccountManager.dtd takes care of the problem:

<!ENTITY addAccountButton.accesskey     "a">
<!ENTITY setDefaultButton.accesskey     "d">
<!ENTITY removeButton.accesskey     "r">

The keys are apparently undefined when they're parsed in AccountManager.xul.

I'm on my way out and don't have time to do the fix, but I tested it by
modifying chrome's en-US.jar file, and I think the original is from either:

~mozilla/mail/components/prefwindow/locale/AccountManager.dtd

Which I think is the culprit. 

or

/d2/src/firebird/mozilla/mailnews/base/prefs/resources/locale/en-US/AccountManager.dtd

Which bears the path of the en-US .jar file, but doesn't quite match the guilty dtd.

Comment 36

[timeless]

so file a bug against thunderbird. even provide a patch, note that thunderbird
uses /mail/ so that's the one you want to patch. please don't spam seamonkey bugs.

Comment 37

[Frederic Bezies]

In answer to comment #36, I filled bug #226544.

Comment 38

[Scott MacGregor]

This patch added access keys like: 

setDefaultButton.accesskey

but I don't see any definitions of this entity in lxr:

http://lxr.mozilla.org/seamonkey/search?string=setDefaultButton.accesskey

are these strings defined some where or is this broken in Seamonkey?

Comment 39

[Stefan Borggraefe]

Attachment: Fixes the regression

Sorry, this was my mistage. :-( When I created attachment 136067 [details] [diff] [review], part of the
fix for bug 68341 creeped in.

This patch removes these accesskeys again...

Comment 40

[Scott MacGregor]

I took the liberty of checking this patch in since this would clearly be a
seamonkey 1.6b stopper.

Comment 41

[Asa Dotzler [:asa]]

Comment on attachment 136140 [details] [diff] [review]
Fixes the regression

a=asa (on behalf of drivers) for checkin to 1.6 beta.

Comment 42

[Tobias Fischer]

Think the Accesskey regression was in Seamonkey too, see
http://bugzilla.mozilla.org/show_bug.cgi?id=226523
Because there were now actuall Tinderbox Builds at the Moment I can't verify this. 

Comment 43

[Malte Rücker (mbr)]

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