If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Status

SeaMonkey
MailNews: Account Configuration
P3
normal
VERIFIED INVALID
17 years ago
13 years ago

People

(Reporter: BenB, Assigned: Alec Flett)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
Subject:
From mailnews.js: pref("mail.allow_at_sign_in_user_name", false);  //strip off
chars following the @ sign in mail user name

Problem:
Many (20-30%, I'd guess) ISPs here is Germany require the full email address as
username. They have to provide descriptions to their users how to set the hidden
pref to true (i.e. hack the prefs.js).

Opinion:
Users having to hack prefs.js is very bad - unconvient, failure-prone and all.
The situation as described above led me to believe that the pref and especially
its default setting was a bad idea in the first place.

Solutions:
Several alternatives:
1. Change default
(|pref("mail.allow_at_sign_in_user_name", true);|)
- Breaks 4.x compatibility. (But I think, MSOE never strips the domain, so we
would show a behaviour similar to MSOE.)
- The problem the pref tried to solve (users being to dumb to differentiate
between email address and account username) appears again
+ The problem as described in the beginning disappears completely

2. Add UI for pref in account wizard
(next to account username textfield)
+ 4.x compat.
+ Users get aware that email address != account username
+ The problem as described in the beginning is *much* less worse, because
companies can easily add one step "check checkbox blabla" in a step-by-step
guide
- Account Wizard gets littered

3. Add UI for pref in account manager
(under "Advanced" or similar)
+ 4.x compat.
+ The problem as described in the beginning is less worse, because the user can
change the pref in the UI (more convient, less failure-prone)
- Companies still have to add *several* steps in a step-by-step guide, like
'open Account Manager, click on your email address on the right (compare bug
57128), open advanced, blabla'. This is because the user would have to use
different 2 dialogs to set up the account (which is a problem in itself, see bug
57126), which also makes it likely that he forgets to set the @-in-username
pref.

Suggestion:
IMO, 3. is not a good solution.

Comment 1

17 years ago
I think if 2 gets added, three almost has to.  It would be bad to have it so
easily set in the wizard but not easily changed once finish is clicked.  The
downside of UI clutter still remains, however.
(Reporter)

Comment 2

17 years ago
Jake, you're right. s/3. Add/3. Only add/
(Assignee)

Updated

17 years ago
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
(Assignee)

Comment 3

17 years ago
this is not a bug, this is a complaint with suggested solutions. Take this up on
the newsgroup, let's reach a resolution there, and then file a bug on the
solution decided.

Comment 4

17 years ago
Just to underline the importance of this: AAt least one of the biggest domain 
providers in Germany (1,300,000 domains!) *requires* a full username including 
the domain. And recently an US ISP posted a help request about this issue in the 
NGs. ok, I'll shut up now and go to discuss this in the NG.
Why shouldn't a complaint (in my eyes it *is* a bug) contain possible solution 
possibilities and be files as RFE?
QA Contact: esther → stephend
VERIFIED INVALID.  The valid bug is 53970 which has been FIXED.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.