Closed Bug 298390 Opened 19 years ago Closed 12 years ago

Signature should have a separate pane

Categories

(Thunderbird :: Message Compose Window, enhancement)

Product:
Thunderbird
Component:
Message Compose Window
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: elharo, Unassigned)

References

(Blocks 1 open bug)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Eudora 6 on Mac OS has a very nice feature. Although it automatically adds your
sgnature to each message as you'd expect, this comes up in what amounts to a
separate pane in the same window. This is not selected or editable by default
unless tghe user clicks in it. For instance, if I do a quick select all and
delete to get rid of the quoted text when replying, the signature is still
there. In effect there are two separate edit areas: one for the body, which I
almost always edit, and one for the signature that I almost never edit.
Thunderbird combines these into one area, which makes operations like select
alll a lot less useful.

Please copy this. 

Reproducible: Always

Steps to Reproduce:
0. Reply to a message
1. Select All
2. Delete
3. Signature vanishes

Actual Results:  
Signature vanishes


Expected Results:  
Only deleted the body of the message, not the signature.
Related to Suite bug 219197?
Perhaps related but definitely not the same issue. That bug suggests that it
should be possible to edit a new signature in Mail/Thunderbird. My request only
comes into play after a signature has been created. It has to do with how an
existing signature is displayed and edited (or not) in each message sent, not
with how the signature file itself is created in the first place. 
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
I'm going to reopen this because it's still a valid request for enhancement.
Expiring this after three months is annoying and makes me less likely to report
issues like this in the future. 

This is not a bug. It's an RFE. If a conscious decision is made to reject this
feature, fine. If a decision is made that this feature is not important enough
to implement in the current release, but maybe somebody will get to it some day,
fine. Leave it open. However just closing RFEs because nobody has had the time
to work on it  for three months is silly. There may be much more important
things in the queue, but I suspect eventually somebody will get around to this,
or make a conscious decision that this feature is a bad idea and reject it.
There's no hurry. We can wait.
Status: RESOLVED → UNCONFIRMED
Resolution: EXPIRED → ---
I agree - there should be something that sets the signature off from the body of the message. It's very counterintuitive to have two dashes to set off the signature because when I type two dashes at the start of a line into the body of the message, TB "SMTP-encodes" this as three dashes (IIRC). Having two dashes to set off the sig *in* the message compose window suggests that if I want to "expand" the signature, all I have to do is type my own two dashes, then a newline....which I presume is not the case. (And even if it is, it shouldn't be.)
note that it was WONTFIX'ed before in bug 37644
Not exactly - bug 37644 talks about a whole bunch of UI. I'm talking as much about reading messages as I am about composing. How about a simple <hr> at the bottom of the message view pane, below which lies the sig?

-----------------------------------
|Message....                      |
|                                 |
|                                 |
|                                 |
-----------------------------------
|Signature...                     |
-----------------------------------

This doesn't waste any screen space, and it removes a disincentive for top-posting, since the signature will always be able to be seen when reading the message. (Seeing the sig could be optional, too, in the compose window....which actually frees up space in the compose window.)
This would be helpful! It would especially come in handy for support teams, who's email messages are often several sets of replies (one reply after another).

Plus, my boss is having trouble with signature text displaying too narrow in html messages and maybe this would help resolve the issue (becuase the rest of the message is not diplayed too narrowly).
QA Contact: message-compose
Blocks: 428895
Assignee: mscott → nobody
Brian what are you thoughts on the matter ?
Can it be implemented MS Word header & footer style? In other words, make the signature part editable only once double-clicked?

I also suggest we make its behavior an option. Some people like to select both body and signature when ctrl+A (or Edit -> Select All), while others want this action to select the body and leave signature alone. Perhaps a first ctrl+A selects body and a second ctrl+A selects signature as well. What about that?
Also this is not Mac only, but Win and linux as well.
(In reply to comment #12)
> Also this is not Mac only, but Win and linux as well.

Maybe you should ping wayne to get more bugzilla rights.
OS: Mac OS X → All
Hardware: PowerPC → All
(In reply to comment #11)
> Can it be implemented MS Word header & footer style? In other words, make the
> signature part editable only once double-clicked?
> 
> I also suggest we make its behavior an option. Some people like to select both
> body and signature when ctrl+A (or Edit -> Select All), while others want this
> action to select the body and leave signature alone. Perhaps a first ctrl+A
> selects body and a second ctrl+A selects signature as well. What about that?

I myself think these are both good ways to implement this from the user’s perspective in the compose window.

In the message view window (and preview pane!), I think the real benefit here will come from having a separate signature pane/window so that the user will see the sig right away. (Disincentive to top-post!)
This might be possible for newsgroups, however for regular mail communications it would remove the control that many TB users rely on.  Creating a disincentive to top-posting is a theme for public communication / newsgroups, however in private communications, especially concerned with signatures, many people and businesses require more control than I believe this system would allow.  

I might be misunderstanding the proposal here, let me know if I've lost a key aspect.
Dear Bryan,

Yes, I think you are misunderstanding the proposal.

The idea is to have, as an option, something that sets the signature off from the message body. The discouraging of top-posting is my own interpretation of what may prospectively happen as a result of implementing it.

What skill set would be required for someone to make this change in the code?
This shouldn't be too difficult to start coding.  However as with any significant user experience change I'd recommend creating it inside an extension first.  Sometimes that's not possible to do, but for this I believe it's very possible and would allow two very useful things; understanding the scope of the problems and immediate testing from others.

take a look at bug 391272 comment #41 for how to get started.  I working with a number of other people on extensions like this.
I would recommend against putting the signature in a separate pane unless that pane scrolls along with the message text area.  I don't think people would appreciate several lines of their composer window real estate eaten up by a pane with a fixed position and whose content is almost never changed.
Yeah -> WONTFIX
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago → 12 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.