1.42 KB, patch
|Details | Diff | Splinter Review|
1.71 KB, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008053008 Firefox/3.0 Build Identifier: version 22.214.171.124 (20080421) So far, I noticed the reply form on Thunderbird positions the cursor below the original message by default. It is more logical and frequent for email clients and web-interface email apps to default the reply message above the original. Reproducible: Always Steps to Reproduce: 1. Fresh install Thunderbird 2. Send yourself a message to the account. 3. Reply to message. Actual Results: Default reply cursor positioning is below original message Expected Results: Default reply cursor positioning is above original message
I don't agree, replying above the quoted text is an error, as the correct way in e-mail is replying below what we're answering to, followed by our signature.
Perhaps you are right. I don't pretend to know the correct way, but all popular emails out there are defaulted the other way, with the reply above the original. Gmail, Yahoo, Horde (colleges and universities use mostly), even Zimbra I think, by default have the reply above. Additionally, other email clients like Outlook, Evolution, also have the reply above if I remember well. Also, for usability purposes, it seems to me quicker and easier not having to scroll down through old messages to see the reply.
The User has options to set in Account Settings... to select the placement of the signature and were the cursor goes to start a reply. It's in the Composition&Addressing settings per account. Therefor this RFE should be closed: WORKSFORME
(In reply to comment #1) > I don't agree, replying above the quoted text is an error, as the correct way > in e-mail is replying below what we're answering to, followed by our signature. I have seen thousands of mails sent by houndreds of users in the last 15 years, NONE of them had the answer BELOW the quote. In my opinion it is very reasonable to put the answer ABOVE the quote. Thus the receiver can immediately read the answer and does not have to scroll to the bottom.
(In reply to comment #3) > The User has options to set in Account Settings... to select the placement of > the signature and were the cursor goes to start a reply. It's in the > Composition&Addressing settings per account. > Therefor this RFE should be closed: WORKSFORME You are right, the user CAN set this in the account settings. But the DEFAULT settings should be the way the utmost majority of the users want it. It is the default setting that is wrong, therefore this RFE should NOT be closed.
There isn't really a right or wrong about it, this is a design decision. The classical quoting style (per Usenet) is to place the quote on top, and either to reply inline to address specific comments in an item-by-item way, or after the quote to retain the natural chronological order of reading. The reply-on-top style is primarily common in the commercial world, so you see the most recent response first and then a paper-trail of all previous replies in an upside-down order. It would be fairly easy to resolve this bug as there are various won't-fixed previous bugs to dupe it to (e.g., bug 360902, which was duped itself against the won't-fixed bug 242961 and also points to the discussion in bug 20966). However, I'm not doing so at this time, occasionally revisiting long-standing defaults whether or not they are still appropriate should be a good idea. In contrast to other defaults which were changed recently, this specific one here doesn't have any strong usability issues caused by the default. It is in compliance with Usenet recommendations and suggests cleaning up the message of old quotes before replying. A compromise would be bug 227376, supporting this etiquette while making it easier to reply above the quote if desired.
"The reply-on-top style is primarily common in the commercial world." Isn't this piece of software meant for "average" people such as myself and countless others who live in "the commercial world"? I asked 4 friends of mine who use TB and they say it's the first thing they change when they have to install TB on a PC. Why? Because nobody in the "commercial" aka real world cares to read the old stuff first. You wanna get to the newest part of the mail forst and that is why most people's reply starts from the top. As per Usenet - most of us non-technical folks have no idea what it is. :)
(Quoting Matt from bug 851725) > Much as I personally disagree with the notion, I am, I think, a minority. > The crowd has spoken, and it is top posting they want. > > I don't think the default should change for NNTP. People on newsgroups are > still quite strict about top and bottom posting. That may be tricky to do given that mail.identity.default.reply_on_top applies to all identities. Thus, you'd have to set an explicit reply_on_top value for those accounts for which you want an exception from the default when it is created.
(having said that, Thunderbird's account-creation code for new mail accounts already /is/ the exception as it's independent from the general account setup, thus it could have a different default from other account types; see bug 798932 for an example where it's already done in current code for POP-account setup.)
I would like to plead again for putting in the value mail.identity.default.reply_on_top;1 - even if this might cause in some cases that existing acounts change behavior from "reply below quote" to "reply above quote" undesirably. Reasons are: - some newbies get completely confused and think "reply below quote" is the new standard to answer e-mails, and they reply to e-mails with "fullquote and answer below" (I have seen that with several people for whom I installed thunderbird) - people using newsgroups do for sure have enough skills to change reply behavior as they need. - last not least (and as was said before here)- the default settings should follow the needs of the majority of users. So IMHO default should definitely go back "reply above quote" - like it was before 2008.
I can hardly believe, that since 2008: - the status of this "bug" is still NEW - it is still assigned to nobody - it is still not resolved It seems as if the Thunderbird developers want to prevent new users from changing to Thunderbird or at least they make it unnecessarily difficult and confusing for them. Any (ANY!) email client on this planet places the cursor by default on top of the message when the User answers an email. Except Thunderbird. Any (ANY!) email client on this planet by default sorts the mailbox by date descending. Except Thunderbird. There is another thread for this issue...
(In reply to crimle from comment #14) > - the status of this "bug" is still NEW > - it is still assigned to nobody > - it is still not resolved As you can see, it's a bit controversial, thus people are reluctant to take it as it may be difficult to get review approvals for it. On the other hand, I'm not aware of any current e-mail client defaulting to "reply below the quote" like Mozilla applications do. A Google search for "reply above" on getsatisfaction.com/mozilla_messaging gave me more than 600 hits (2,700 when omitting the quotes), thus confirming Matt's point (and my impression) that indeed it is a frequent problem for the users and an unexpected behavior. From the technical point of view it's fairly straight-forward to solve this. There is already a hook for NNTP accounts defaulting to plain-text composition at the time an account is created, thus I'd rather go with enforcing it at the time the account is set up rather than changing the default as such, which would also affect existing accounts. I've modified the title a little and moved it to the Account Manager component to reflect the change of focus. I'll come up with a patch given that the 24.0 timeframe would seem to be a good opportunity to introduce such a change with a new branch.
FWIW, i agree we should make reply on top the default. (I think this has stalled mostly because it's not just flipping the default pref.)
Created attachment 757556 [details] [diff] [review] Proposed patch [checkin: comment 26] This patch adds an explicit value for identity.replyOnTop during the account creation procedure for "imap" and "pop3" server types in createAccountInBackend(), similar to the "nntp" override for the composeHtml attribute. The default pref remains unchanged, thus existing identities aren't affected. As a drive-by fix, I've added a comment for the nntp part, given that the old Account Wizard has one there as well to explain the override. SeaMonkey uses mailnews/base/prefs/content/AccountWizard.js instead, so this should be NPOTB for the suite. Note that I've commented out modifying the sigBottom attribute as well, though this setting frequently goes along with replying above the quote. Given the unsolved issues with multiple identities when the signature doesn't have a separator coming with it (bug 218346), it seems to be unsafe to change that at this time. If so desired, it should be revisited once the signature-related issues are fixed. Given that there are other precedences already of hard-wiring setup defaults into the accountcreation code, I don't see a problem using constants here as well. If however you'd like "new-account" preference settings for these defaults, I can certainly retrieve the values assigned and added to all-thunderbird.js from Services.prefs rather than a constant, but I've started with the simplest solution.
Comment on attachment 757556 [details] [diff] [review] Proposed patch [checkin: comment 26] Mmmm, long-standing internet flame wars. My favourite thing to wade into the middle of! "Thanks", everyone. ;) (In reply to harry_cube from comment #13) > - last not least (and as was said before here)- the default settings should > follow the needs of the majority of users. Do you _know_ what the majority of Thunderbird's 20 million users want or need? Or are you assuming they are all like the people you are in contact with? (In reply to rsx11m from comment #15) > A Google search for "reply above" on getsatisfaction.com/mozilla_messaging > gave me more than 600 hits (2,700 when omitting the quotes), thus confirming > Matt's point (and my impression) that indeed it is a frequent problem for > the users and an unexpected behavior. That's a deeply biased search, since none of the people who prefer "reply below" will have left a comment. Or are you proposing that the 19,999,400 other Thunderbird users all prefer "reply below"? ;) Having said all that, it does seem like the world is moving towards "reply above", so setting that for new accounts seems reasonable. So ui-r=me. (I think I would prefer it if we could copy the pref from the existing default account, if one existed, since then old users who set up new accounts wouldn't be surprised. Rsx11m, do you think you could make that change?) And the code looks good, so I'll steal the review from mconley, and say r=me, too. Thanks, Blake.
Thanks Blake. (In reply to Blake Winton (:bwinton) from comment #18) > That's a deeply biased search, since none of the people who prefer "reply > below" will have left a comment. Or are you proposing that the 19,999,400 > other Thunderbird users all prefer "reply below"? ;) No, I'm not assuming anything. Some people want to see "hard numbers" as evidence that something is wanted, and that's the only number I could come up with. :-D Personally, I'm not deeply determined in one way or the other. It depends on the environment and which kind of people one is communicating with. > I think I would prefer it if we could copy the pref from the existing > default account, if one existed, since then old users who set up new > accounts wouldn't be surprised. This sounds like a good idea, though it would make the code a bit more complicated. Thus, if MailServices.accounts.defaultAccount is defined I'd copy replyOnTop and sigBottom from that account, then overriding the constant. Not marking checkin-needed yet to look into the extended solution.
Created attachment 758220 [details] [diff] [review] Proposed patch (v2) Extended version, copying signature-placement attributes from the default identity (if it is valid) of the default account (if it exists). Note that the check for accounts.length is necessary for this to work because accounts.defaultAccount can't be accessed before at least one account was created. Each mail account has at least one identity, thus we should be fine in this case. If there is no default identity or if it's not valid, the constant default for replyOnTop prevails.
Created attachment 758719 [details] [diff] [review] Proposed patch (v3) So, I've looked further into the default-account issue and found that the tests have to be a bit more extensive than just checking if it exists. As it turns out, also non-mail accounts (like the RSS account) may end up being set as the default account. I've managed to do this by cancelling the initial account setup first, then creating the RSS account, and only after that creating the e-mail account. Thus, if you create an feeds or news account first, the new e-mail account won't be set as the default account. The new patch corrects this behavior by: (1) testing if the claimed default account indeed has the canBeDefaultServer attribute set before using it to copy the replyOnTop and sigBottom attributes; (2) setting the default account only if the new account has canBeDefaultServer set to true, and (3) not just if none has been defined already, but also if the one defined has canBeDefaultServer set to false and is thus invalid in this role. This should work now correctly for all types of existing account at the time the new mail account is created. Ideally this would be fixed at the RSS end as well to avoid the account being set as the default to start with, but then you'd still end up with Local Folders as the default account, thus the check is still needed.
(In reply to rsx11m from comment #21) > also non-mail accounts (like the RSS account) may end up being > set as the default account. I've filed bug 880464 on this issue.
After some discussion with aceman and looking into the related bugs, currently !MailServices.accounts.defaultAccount can't be true due to bug 342632. This case would apply only if no account exists and is caught in the current patch. Once bug 342632 is fixed, it would be possible to have no default account defined even when at least one account exists, but this case is covered as well. Thus, no impact of those new insights on the proposed patch.
Created attachment 759768 [details] [diff] [review] Proposed patch (v4) I have moved hunk #2 to bug 880464 in order to consolidate setting of the default account in that bug, thus we have a cleaner scope here and can concentrate on the issue of the default reply positions for new mail accounts. I'd nevertheless recommend to test this patch along with attachment 759766 [details] [diff] [review] applied to ensure that you get the full picture.
(In reply to rsx11m from comment #19) > Not marking checkin-needed yet to look into the extended solution. As discussed with Blake per e-mail, let's get the already approved patch checked in to establish the feature change in time for the approaching 24.0 cut-off. I'll then unbitrot the (v4) patch for adding the dependency on the default account if one has been defined already. In this way, we can allow this part to slip into the aurora phase if necessary, as Blake's schedule permits to review it. -> Push for attachment 757556 [details] [diff] [review] on comm-central, please.
Created attachment 764268 [details] [diff] [review] Unbitrotted patch (v5) [checkin: comment 31]
Comment on attachment 764268 [details] [diff] [review] Unbitrotted patch (v5) [checkin: comment 31] With my UX hat on, it looks good, so ui-r=me. And I can't find any problems with the code, so r=me, too. Thanks, Blake.
Thanks Blake, push for comm-central please once it's open again. I'll request approval for comm-aurora in a moment.
Comment on attachment 764268 [details] [diff] [review] Unbitrotted patch (v5) [checkin: comment 31] [Approval Request Comment] Regression caused by (bug #): follow-up to attachment 757556 [details] [diff] [review] which landed for 24.0 on trunk. User impact if declined: would see different behavior in 24.0 vs. 25.0, thus not obeying default-account choices previously made. Testing completed (on c-c, etc.): developed and tested on a 24.0 build. Risk to taking this patch (and alternatives if risky): low
Though I don't know if this is relevant enough to be highlighted in the release notes (change of defaults are frequently a surprise with users caught off guard, thus it may be worth it), setting the "relnote" keyword for consideration.