Closed Bug 297534 Opened 19 years ago Closed 16 years ago

Want to entirely disable marking a message as read when viewed

Categories

(Thunderbird :: Preferences, enhancement)

Product:
Thunderbird
Component:
Preferences
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Thunderbird 3

People

(Reporter: ilya.konstantinov+future, Assigned: mkmelin)

References

Details

Attachments

(3 files, 11 obsolete files)

proposed fix, v2
38.77 KB, patch
mnyromyr
: review+
Bienvenu
: superreview+
Details | Diff | Splinter Review
screenshot, v2
56.21 KB, image/png
Details
nits from comment 150, v2
7.32 KB, patch
Details | Diff | Splinter Review 
After unchecking:
[ ] Mark message read after...
I intuitively expected that it'll disable automatic marking of messages as
"read" and that I'd have to mark them manually from now on (which is what I
wanted to do).

This option could be probably better phrased as:
[ ] Do not mark messages as read unless displayed for more than [__] seconds.

Alternatively, we can add another option and make the original option a sub-option:
[ ] Mark messages as read automatically
    [ ] Do not mark messages as read unless displayed for more than [__] seconds.
Duplicate of/related to bug 234121?
Bug 234121 is certainly related, but my issue still stands:
The phrasing of this option is ambiguous and should be cleared up. At the same
opportunity, this feature might be disambiguated into two features as I've
described in my GUI mockup.
The current phrasing (in nightly builds, not in the 1.0.x branch) is:
  Wait [NNN] seconds before marking a message as read

Not ambiguous, IMO.
Severity: minor → enhancement
Hardware: PC → All
Summary: Unchecking "Mark message read after..." option doesn't disable marking-as-read → Want to entirely disable marking-as-read
Version: 1.0 → Trunk
(In reply to comment #3)
> The current phrasing (in nightly builds, not in the 1.0.x branch) is:
>   Wait [NNN] seconds before marking a message as read
> 
> Not ambiguous, IMO.

1) Contains two operators ("wait" + "mark as read") which is always a bad idea in any dialog box question or setting. 

2) Since most users intuitively expect only the important one (mark as read), this is a second cause of confusion, even for users who notice the double operator *and* understand which is the less important but grammatically decisive operator (wait).

3) Necessity to enter a high number to activate current main operator is clumsy and requires multiplication by 3600 to get an hour value. In addition, entering numbers higher than 77777 or less, depending on different bug reports, breaks the setting.

1.5 (20051201)

I don't think this is a question of ambiguous wording, it doesn't work right period.  I have tried 1.0.7 and 1.5 (20051201).  As far as I can tell, there is no way to have it NEVER mark as read.  If I uncheck the box, it's marked read immediately.  If I check it, it will eventually be marked read even if I enter 99999.  

Since I manage my inbox like gmail, and use read-unread toggling in conjunction with "show threads with unread" to manage which messages appear in the view, this is a really annoying bug with no apparent workaround.
Bug 234121 fixed all my complaints about the wording, but the wording was a minor part of this bug anyway. The real issue is the lack of "never automatically mark as read" functionality.

BTW, verified -- The original code is indeed mscott's.
Still a problem in 1.5 (release), and maybe even worse since any large value set in the renamed "Wait x seconds before..." field seems to result in the message getting marked read immediately as does unchecking the box.
There is no option to never mark a message read, and if I enter a very large value for it to wait until marking it read, it doesn't work correctly and still marks it immediately read.

This is most definately a bug. Even if there is still a missing feature for telling TB never to mark a message as read, this particular feature is broken in that it a) doesn't work with large numbers entered and/or b) does not declare or check for an upper limit to an entry of number of seconds to wait until marking a message as read.

Please adjust Severity to MAJOR from ENHANCEMENT, as this is a loss of critical functionality and there is no workaround.

Please fix soon!
Actually, this times a computer isn't able to know, whether I've read a message or not, without getting this knowledge from me. 

I would prefer this issue to be fixed, preferably by adding one or two extra options, to stay downwards compatible and get an extra option to configure this behaviour in the mail window.

for example:

[] Mark messages as read automatically (message window) (here:mailnews.mark_message_read.auto)
[] Mark messages as read automatically (preview window) (here:mailnews.mark_message_read.auto3pane)

which could be implemented in mailWindowsOverlay.js as following

function OnMsgLoaded(aUrl) {
[..]
    var markReadOnADelay = gPrefBranch.getBoolPref("mailnews.mark_message_read.delay");
    var markReadAuto = gPrefBranch.getBoolPref("mailnews.mark_message_read.auto");
    var markReadAuto3Pane = gPrefBranch.getBoolPref("mailnews.mark_message_read.auto3pane");

    if (msgHdr && !msgHdr.isRead)
    {
      var wintype = document.firstChild.getAttribute('windowtype');
	  if ((markReadAuto3Pane && wintype == "mail:3pane" ) || markReadAuto) {
		  if (markReadOnADelay) // only use the timer if viewing using the 3-pane preview pane and the user has set the pref
		  {
			ClearPendingReadTimer();
			gMarkViewedMessageAsReadTimer = setTimeout(MarkCurrentMessageAsRead, gPrefBranch.getIntPref("mailnews.mark_message_read.delay.interval") * 1000);
		  }
		  else
			MarkCurrentMessageAsRead();
	  }
    }

agreed.  want it toi work like opera/m2, where nothing is "automatically" marked  as read.  otherwise i know i will automatically "mark as read" things that i haven't dealt with yet.

intend to switch over to TB from opera/m2, but won't until this is taken care of.

First, it doesn't work right. Set 99,999 seconds before it is mark as read but thunderbird marks it in like 5 seconds ...

Second, it i uncheck the "mark as read" box it, thunder marks as read immediately.  It should be disabling mark as read. And if i wanted it automatic, then should check box and set 0 seconds there. Logical?
(In reply to comment #11 and #5)
> First, it doesn't work right. Set 99,999 seconds before it is mark as read but
> thunderbird marks it in like 5 seconds ...
> 
> Second, it i uncheck the "mark as read" box it, thunder marks as read
> immediately.  It should be disabling mark as read. And if i wanted it
> automatic, then should check box and set 0 seconds there. Logical?

No, not logical; you haven't understood the logical structure of the UI's sentence. Did you read comment #3?

Yes, we know it doesn't work right, but there is the additional problem caused by the ambiguous wording. The current wording is *not* as you and the original bug reporter incorrectly state. The correct one is "Wait ... seconds before marking a message as read" and if that does not have a check mark, it means "Don't wait ...seconds before marking a message as read" which can mean several different things. 

In any case, not putting a check mark does not mean "Don't *mark* (as read)"; instead, it means "Don't *wait* (before marking as read)". The main verb of the sentence is "wait" not "mark". 

The developer's choice of choosing that to mean "Don't wait ...seconds before marking a message as read - mark as read after the default time of 5 seconds" is not incorrect; it's the UI's wording that is clumsy because it also enables other possible logical and grammatically illogical but "natural" or expectable interpretations.

> No, not logical... Did you read comment #3?

I still think that this is a side issue. The main problem is that there is a useful functionality missing from Thunderbird - viz. the ability to disable the automatic marking of messages "as read".

Whatever the exact text in the UI, this feature is important to me (and presumably to several others given the number of votes for this bug). Please can we get the new feature, rather than arguing about the semantics of the dialog box text?

P.S. I attach a patch that was originally uploaded to bug 234121 (it seems to have been deleted) that I have been using quite happily for about a year now.

Chris.
I agree.  This bug has 31 votes, 14 people watching it, and a submitted patch.  I don't know if this is a lot (can't figure out how to get bugzilla to sort by votes) but it seems to be important to several people.

Can we get the patch applied so people can start using a nightly build with the fix?  If not, what is the reason - what are the developers waiting on?  If it's semantics of the wording, then lets work that out through discussion and get a fix applied.

This is an important feature, because it allows thunderbird to be used in a "gmail" like fashon, by leaving everything in a single folder, and selectively hiding messages by "archiving" (or marking as read).
Chris, if you think your patch is fit to be checked into the trunk, please request a review and a super-review (r/sr) for it. Otherwise, it'll never get noticed.

Chad, this bug is surely important (I am myself a fan of this way of managing mail). Unfortunately, no valid fix has been proposed for it.  In my opinion, Chris' patch is not fit to be checked in yet, because his solution is not clean enough.

Chris' patch changes Thunderbird's behavior to:
1. If the "[x] Wait [N] before ..." checkbox is unchecked, mark messages as read immediately.
2. If the [N] is 0, never mark messages as read.

If we change Thunderbird that way, we'll make the UI more confusing to the users, cause we'll be adding a new feature ("Never mark as read") without changing the Options dialog. Chris' patch does not modify the Options dialog in any way that suggests "0" is a special value which makes messages never get marked as read.
I'm not familiar with creating patches, however, for those who are not afraid to edit their configuration files here is the fix for this bug. (FYI: This change is extremely easy with WinRAR, because after making the change to the file WinRAR automatically prompts you to update the file without extracting everything.)

Change:

else

To:

else if(wintype != "mail:3pane")

Location:
Line 2286 of
%ThunderbirdFolder%\chrome\messenger.jar\content\messenger\mailWindowOverlay.js

That's it! After this update, if the "Wait..." box is unchecked, mail is never marked as read when using the preview pane.

What's wrong with the way outlook works:
The option is named "[X] Mark item as read when viewed in the Reading Pane".
If the checkbox is off, the message is never marked as read.
I'm sure that quite a few people use Outlook (2003) and I haven't heard any complaints about this behavior.
Genady, Nobody said "[X] Mark item as read when viewed in the Reading Pane" is a bad idea. However, this bug isn't talking about the reading pane only.

First, let's have this bug handled without separating behavior for Reading Pane and New Window. You're welcome to open a new bug proposing to separate the behavior.

Right now, there's no patch which alters both the UI and the underlying mark-as-read code. Nobody yet said: "My plan is to solve this bug by doing ... and I'm willing to write a patch for it. Will it be accepted?"
(In reply to comment #15)
> 
> Chris' patch changes Thunderbird's behavior to:
> 1. If the "[x] Wait [N] before ..." checkbox is unchecked, mark messages as
> read immediately.
> 2. If the [N] is 0, never mark messages as read.
> 
> If we change Thunderbird that way, we'll make the UI more confusing to the
> users, cause we'll be adding a new feature ("Never mark as read") without
> changing the Options dialog. Chris' patch does not modify the Options dialog in
> any way that suggests "0" is a special value which makes messages never get
> marked as read.

I didn't look at Chris' patch myself, but if what Ilya said is true, the wording is confusing in another way: If the checkbox is unchecked, it should mean "Don't wait" - i.e. Mark as read immediately.

This is better:

[ ] Mark a message as read [__] seconds after displaying it

(or something similar in structure).
Here, users can intuitively expect that to mark a message as read immediately he/she has to check the checkbox and enter 0 in the text field.
Fair enough.  It was clearly stated why the current patch isn't production-worthy, and that's all I can ask for, unless I step up and submit a patch myself :).

However, if the hack mentioned to ActionMailer::Base.server_settings in the comments works, that would be good enough for me.
Flags: blocking-thunderbird2?
This is my first ever filing of a patch, so I hope I did it right!!
Submitting it for review, please.

This was actually a quite simple fix - I'm no code expert, but unless I'm missing something obvious, the problem was brought about due to clumsy/lazy coding.

***
1) I took a look at Outlook Express's Option's dialog to see how they worded it, and it was straightforward and intuitive, surprise-surprise. TB devs would be wise to actually take a look at existing programs for implementation ideas once in a while...

So the first thing to do was change the wording to something similar.
In the 'en-US.jar' (or other localized version) is a file called 'advanced.dtd'.
I changed 3 lines + the comment above it. So now the Options dialog reads:
"Mark message as read after it has displayed for [__] second(s)."

***
2) The original script code ('mailWindowOverlay.js', inside the 'messenger.jar' read:
"if (markReadOnADelay && wintype == "mail:3pane")..
[--code to mark-after-delay--]
      else
        MarkCurrentMessageAsRead();
    }"

So it was no wonder that the Mark As Read could not be turned off!!

I fixed up the IF statement section by first checking to see whether we are using the Preview Pane ('3pane'), and if it is, then it checks to see if the mark-as delay is enabled - if it is, then it executes it. If it is not set, then nothing happens (yay!). If we are not using a 3pane view (ie: messages are viewed in a message window), then we follow a similar check to see if the mark-as delay is enabled or not.

The result is that Mark as Read can now be turned completely off;
additionally whatever delay options are chosen (on/off + # of seconds delay) - it is the same for both viewing messages in the Preview pane and in (2-pane) message windows.

***
NOTE:
1) It was suggested in this Bug Thread that an additional Option be added to ask the user if they want the Mark-As settings to be also work on the message window. This could be added, but for now I just wanted to address the issue at hand and applying the settings to both views was the best solution without adding extra items to the Advanced Options.

2) I noticed that the 'accessibility keys' (the underlined letters in Options dialogs/Menus) is in a very poor state right now, especially in the Advanced Options. Reason - multiple options share the same underlined access key/letter (ex: 'd' on 'seconds' in the mark as read line).
I haven't looked for a separate Bug filed for this but it needs attention. Not enough letters in the English alphabet for all the options, perhaps an 'advanced2.dtd' is needed?

3)Obviously as I made changes to a .dtd file inside 'en-US.jar', translations would be required for non English versions.

4) Ditto all-of-the-above for SeaMonkey, if anyone cares.
Attachment #212205 - Flags: review?(I_am_RenegadeX)
Comment on attachment 212205 [details] [diff] [review]
Patch to allow Mark As Read to be disabled + add delay to pane view

You can't request yourself to review your own patch. ;)
Attachment #212205 - Flags: review?(I_am_RenegadeX) → review?(bienvenu)
Wow Renegade, thanks for stepping up on this.  I hope a dev applies this, or points out any problems with your patch.  Looks like you've done the hard work, just needs to get finished up now...
Comment on attachment 212205 [details] [diff] [review]
Patch to allow Mark As Read to be disabled + add delay to pane view

I'm confused, you just removed our default behavior which is to mark a message as read after you read it.

We are no longer calling MarkCurrentMessageAsRead in the default case which is incorrect.

FYI, the timer seems to be working fine for me using a trunk build from today, it waits the specified amount of time before marking the message as read in the 3-pane. I'm not sure why that feature isn't working for some of you.
Attachment #212205 - Flags: review?(bienvenu) → review-
(In reply to comment #24)
> (From update of attachment 212205 [details] [diff] [review] [edit])
> I'm confused, you just removed our default behavior which is to mark a message
> as read after you read it.
> 
> We are no longer calling MarkCurrentMessageAsRead in the default case which is
> incorrect.

mscott - you said my patch "REMOVED our default behaviour", ".. which is to mark a message as read after you read it."

.. Depends how you define 'default behaviour'. If 'default due to sloppy coding' is changed, then yes, guilty as charged!
.. and it depends on whether we're talking 3-pane view, or with the Preview disabled (therefore reading messages in a separate message window) - as the original code totally ignored marking as read for the latter, thus there are presently 2 different 'default' behaviours!

Before I even get to discussing my patch, consider for a second the existing situation and the code behind it:
The Advanced Option dialog reads:

'wait [x] seconds before marking as read' .. (which is *disabled* by default).

From 'mailnews.js' (http://lxr.mozilla.org/mailnews/source/mailnews/mailnews.js), (packaged in the 'prefs' folder):
--------
// set to true if viewing a message should mark it as read only if the msg is viewed for a specified time interval in seconds
pref("mailnews.mark_message_read.delay", false); 
pref("mailnews.mark_message_read.delay.interval", 5); // measured in seconds
--------

Now you stated that the current 'default behaviour' is to "mark a message as read after you read it".
In that case, it would follow that the delay *should* have been set to TRUE, and that the delay.interval *should* have been preset to '0' seconds. However, that is not the case.

Anyhow, we are here discussing this Bug because the current situation is that no consideration is given to the fact that a user may want to totally disable 'mark as read'. You make a valid point in that you believe that the default behaviour that the user sees (regardless of the code behind it) is for messages to be marked As Read immediately upon viewing. Whether that is what users want or need is probably up for debate, but if that's the desired behaviour, no problem - my patch could be annoted to add a modification to the 'mailnews.js' file:

--------
- // set to true if viewing a message should mark it as read only if the msg is viewed for a specified time interval in seconds
- pref("mailnews.mark_message_read.delay", false); 
- pref("mailnews.mark_message_read.delay.interval", 5); // measured in seconds
+ pref("mailnews.mark_message_read.delay", true); // when set to false, mark as read will be disabled
+ pref("mailnews.mark_message_read.delay.interval", 0); // measured in seconds; setting to 0 will immediately mark the currently viewed message as read
--------

Thus the default 'fresh-install' Advanced Options dialog entry would read:
**
(checked) "Mark message as read after it has displayed for [0] second(s)."
**
.. which is straightforward and intuitive. If a check in the box means that a message will be Marked, unchecking clearly means that messages will not be Marked.

I would personally suggest a default delay.interval of '3' seconds.. but whatever.

IDEALLY the pref's name should therefore be changed from 'mailnews.mark_message_read.delay' to something like 'mailnews.mark_message_read_toggle'.
'mailnews.mark_message_read.delay.interval' is fine as-is.

Would THAT be possible?
Scott,

The quick check of the feature in a trunk build, is by no means a guarantee that this works. It's not a consistent behavior. Sometimes having a long delay actually works, never causing emails to be marked read, but other times, it just doesn't work. 

With that said, I *completely* agree with RenegadeX (comment #25) that the current intended design of this feature is confusing in itself. It's not friendly for those users who prefer to never have emails marked as read automatically, in the preview pane. The suggested change in comment #25, definitely gets my vote.
Right, a quick check of the trunk build is not conclusive.  If you read the history on this bug (I think it's a comment on another closed duplicate ticket), you will see that different values for the timeout cause different behavior.  I believe someone even described the reason why.  Sorry I'm too lazy to find the reference now.

My setting is currently "7777" which causes a long delay in marking read, but higher or different values can cause it to be marked as read immediately.
I agree with the others that there should be a choice other than "some long time", which is NOT the same as "NEVER".
To Worcester12345: Nobody proposed to close this bug and say that 'setting a high-enough timeout is good enough'. Stop arguing against what nobody even proposed.

--

To RenegadeX: What worries me about your patch is not only the 'new user profile scenario' (e.g. fresh install) but also the 'upgrade scenario'. Will prefs which users had before upgrading to your patch suddenly take on a new meaning?

Right now, we have:
 mailnews.mark_message_read.delay
 mailnews.mark_message_read.delay.interval

You want to change the meaning of "mailnews.mark_message_read.delay". This is not okay for the upgrade scenario!

Instead, you should introduce a new pref:
  mailnews.mark_message_read = true by default
 Ilya Konstantinov  has a patch, which I haven't tried

What I would like is 

1) so long as the message is not opened (only viewed in the main Tb window), it is not marked as read.

2) when opened in a separate window, it is marked as read (but can be remarked with "M").

Does the "never" here exclude 2?
Jim, I never submitted a patch to this bug.

As to your proposal, you're talking about separating the behavior for Preview Pane and Message Window. It's a good idea but it goes further than what THIS bug tries to solve. Please open a new bug about it.
Hey, just wanted to take some time to give a little love to the people who make open source work.

Ilya Konstantinov, I'm assuming you are a TB committer.  Thanks a lot for giving this bug some attention and feedback on the submitted patches.

RenegadeX, thanks a lot for submitting the patches with description and explanation.  It looks like you are close to having an acceptable patch - just need to ensure the behavior remains the same for people who are upgrading?

Good Job!
-- Chad

Ok, I have updated the patch to change the pref name.
The patch now alters 4 files:
- 'advanced.dtd' - contains the revised en-US (localized) Advanced Options dialog box entries.
- 'advanced.xul' - contains the revised pref name; 'mailnews.mark_message_read.delay' has been changed to 'mailnews.mark_message_read' - and will be either true (mark as read enabled) or false (mark as read not enabled).
- 'mailnews.js' - sets mark as read to 'true'(ie: 'ON') by default.
- 'mailWindowOverlay.js' - the script that activates the mark as read settings

Note: At this time, we don't need to check to see if we are in 3-pane view or not (my patch gives the same prefs to both views); additionally, the 'msgHdr && !msgHdr.isRead' if-statement does not appear to be required in order for the mark as read function to work as intended (either view). However, I left both the 'msgHdr' AND pane-view if-statement items in place in case they will be of use in the future. I'm not a coder, so if they have a use here, it's beyond my scope of understanding!
Attachment #212205 - Attachment is obsolete: true
2 things:
1) mscott- could you explain what the "if (msgHdr && !msgHdr.isRead)" statement acutally does and why it is needed (message-marking seems to work even if it is removed). See
http://lxr.mozilla.org/mailnews/source/mail/base/content/mailWindowOverlay.js#2346

2) Based on the comments I've seen here and elsewhere, I set about working on a 'separate mark-as-read prefs for 3-pane & messageWindow' patch (enable/disable for each + separate delays). Wasn't too difficult to accomplish (even for me!) and it works great!

However, this admittedly goes beyond the scope of this (297534) Bug. Obviously adding prefs for this means adding items to the Advanced Options dialog.. and adding things always seems to involve mucho-discussiono about the best way to do something...

I could not find an already-filed Bug for this, so will file one unless someone can point me to it. Of course, that that Bug would depend on the approval/resolution of this Bug, I assume I should wait?
*** Bug 314245 has been marked as a duplicate of this bug. ***
Has anyone discovered a workaround for this until a fix finds its way into a Thunderbird release?
> Has anyone discovered a workaround for this until a fix finds its way into a
Thunderbird release?

Yeah.  Forward all your mail to your Gmail account, use it as your email client, and forget about using Thunderbird on a daily basis.  That worked for me :)
(In reply to comment #36)
> Has anyone discovered a workaround for this until a fix finds its way into a
> Thunderbird release?
>

The suggestion given in comment #27 is the closest you will get to a workaround (other then not using TB):

"My setting is currently "7777" which causes a long delay in marking read, but
higher or different values can cause it to be marked as read immediately."
In reply to comment #25:

This solution also has my vote.

I agree that the current behavior of the 'wait' option is faulty. This is because two different settings result in the same behavior:
1. unchecking the option results in immediately marking the message as read.
2. checking the option and setting it to 0 seconds also results in immediately marking the message as read.

For me this is clearly not working as intended by the developer(s). The coding example from before also supports this opinion.

As to how to resolve this issue: you may never change the behavior as it appears to the unsuspected user. So, when an update or a patch is installed it must seem that nothing has changed.

Most of the people here agree that the first setting should result in 'never' marking the message as read (review pane or not is another discussion). So during an update setting #1 should be converted to setting #2. So, during an update the current behavior of the application is not changed, but still the 'new' functionality will be available to the users who will go looking for it.

I'm not at all sure if this 'update' proposal is at all possible in the TB install process, but i think it is worth a closer look.
(In reply to comment #36)
> Has anyone discovered a workaround for this until a fix finds its way into a
> Thunderbird release?
>

Oh! I just thought of another workaround. Create a filter that marks all incomming messages as 'Marked'. This message property is not at all effected by the issue at hand.

Glad to to be at service.

Sander Pors
(In reply to comment #37)
> > Has anyone discovered a workaround for this until a fix finds its way into a
> Thunderbird release?
> 
> Yeah.  Forward all your mail to your Gmail account, use it as your email
> client, and forget about using Thunderbird on a daily basis.  That worked for
> me :)

I concur. Last time I used Thunderbird was back in February .. I gave up on it, unfortunately. Just too frustrating. I spent more time tracking down extensions from France & China, and working on Bugs than I did actually using the thing.

Unfortunately for TB, the gap between what the devs want and what the majority of users want seems to be too large for its own good. I don't know of one person in real life who uses Thunderbird - many had tried it, but all went back to their old MS apps. TB had the exact same potential that FF had to become a success, but it lacked innovation and intuitiveness, IMHO.

Anyhow, the patch that I'd posted in the this thread way back in Feb. works - it provides options to please everyone, and it's there for the taking should anyone wish to patch their own copy of TB, improve upon it, or turn it into in extension, if that's possible.
(In reply to comment #41)
...
> Anyhow, the patch that I'd posted in the this thread way back in Feb. works -
> it provides options to please everyone, and it's there for the taking should
> anyone wish to patch their own copy of TB, improve upon it, or turn it into in
> extension, if that's possible.

This has been blocking the release of 2 for a while now, and hopefully since there is your patch, it will be checked in and fixed once and for all. Just give them time to get to it. It shouldn't be long now.


Worcester12345 in comment #42:
> (In reply to comment #41)
> ...
> > Anyhow, the patch that I'd posted in the this thread way back in Feb. works -
> > it provides options to please everyone, and it's there for the taking should
> > anyone wish to patch their own copy of TB, improve upon it, or turn it into in
> > extension, if that's possible.
> 
> This has been blocking the release of 2 for a while now, and hopefully since
> there is your patch, it will be checked in and fixed once and for all. Just
> give them time to get to it. It shouldn't be long now.

Not blocking - it was never approved as a blocker (it's still "?").

Won't get check-in, as it hasn't been reviewed. RegegadeX never marked it for review.
(In reply to comment #43)
> Won't get check-in, as it hasn't been reviewed. RegegadeX never marked it for
> review.

Comment #22 said: "You can't request yourself to review your own patch. ;)"

And for the record, re Comment #34 - Scott MacGregor never answered my question here, on IRC (I PM'd him at the time at least 3 times one week when he was online and never once got a reply) & I even PM'd him on MozillaZine forums with the question - and the message remained unread - until I finally deleted it earlier this week (by coincidence) - 8 months after it was sent.

As I'm typing.. and as I'm long-done with TB, I should mention:

re: Comment #34, I referred filing another Bug in regards to problems with the wording in the Advanced Options dialog - there are too many options for the available Accessibility letters. For the record, it was  Bug 327908, "Advanced Options dialog (advanced.dtd) has too many entries for available unique accesskeys, thus some underlined letters conflict and are broken"

IIRC, it was already 'broken' before I added even more entries with my 'Mark All' patch!
RenegadeX Thanks for clarifying. My comment was not a criticism of your actions - you have done all the right things AFAICT.

Perhaps mcow can offer some perspective on comment 34, 39 and 33?
My perspective is: this feature isn't worth the effort.

The purpose of the delay was to prevent marking something as read while rapidly scrolling thru the thread pane with the message pane open.  Contrary to the assertion in comment 39, there clearly was never an intent to completely prevent marking a message read automatically in the message pane.  And I doubt a patch that leaves a message marked Unread when it gets loaded into a standalone window, even if controlled by a preference, will ever be approved.

(Incidentally: bug 226551 is about the problem of large values not being interpreted correctly.)



(In reply to comment #44)
> Comment #22 said: "You can't request yourself to review your own patch. ;)"

And that means:  you request a review of somebody else.


> And for the record, re Comment #34 - Scott MacGregor never answered my
> question

Yeah, that happens.  Scott has lots of things to do, and obviously neither he nor any of the other mail developers think this issue has any priority.  The approach to take is to put together a patch that acts the way you think best, post it, and request a review.  It may never get reviewed, that happens too.  But if it does, then, if there's some problem (e.g. you removed a test that really should have stayed) someone (we hope) catches it during the review.
(In reply to comment #46)
> My perspective is: this feature isn't worth the effort.
> 
> The purpose of the delay was to prevent marking something as read while rapidly
> scrolling thru the thread pane with the message pane open.  Contrary to the
> assertion in comment 39, there clearly was never an intent to completely
> prevent marking a message read automatically in the message pane.  And I doubt
> a patch that leaves a message marked Unread when it gets loaded into a
> standalone window, even if controlled by a preference, will ever be approved.

This is a joke and irresponsibility on the part of the developers, IMHO.  There was a patch submitted for this, and it's being ignored.  

To me, this bug is nothing about wording or sording or anything.  It's about making thunderbird work like gmail and other 21st century web apps.  See my comment #5 for an explanation like this.  If you don't understand what I mean, I'm glad to take the time to explain further.  I'm still watching this bug.

Like RenegadeX, who submitted the patch, I have stopped using Thunderbird.  Granted, it was for Gmail, and I still don't know of any other non-Thunderbird POP client that comes close to the gmail experience.  The point is, this bug is about trying to do something about that by enabling a more gmail-like experience in Thunderbird.  Dismissive developer attitudes in which a bug with a patch is blown off without fulling understanding the problem annoy me, and don't make me anxious to continue using or supporting Thunderbird.
Also use the read/unread message to manage email.  It's very simple.  If I don't open it, I don't want it marked "read".  Please fix / patch.  This is getting to be a microsoftian issue, where some lofty ideal conflicts with everyday use.

> Since I manage my inbox like gmail, and use read-unread toggling in conjunction
> with "show threads with unread" to manage which messages appear in the view,
> this is a really annoying bug with no apparent workaround.
> 
[WITHOUT the unnecessary rant against developers, which I am not nor perhaps is Mike]

My interest is different than Chad's and similar to Tom's (who beat me to the punch) - I have a folder of emails that happen to be tasks (I didn't write them).  If I read a task/email but don't complete it I do NOT want to change to unread.  

Having it go unread risks it not getting future attention and not getting completed. Granted perhaps it's a non-standard use of email, BUT I think it's not an uncommon use. 

What would actually be more useful (to me) is a folder-level option to disable marking unread, rather than a global option such as timed unread.  I think this is a reasonable idea for local folders, which is of course needs to be another bug.


>I doubt a patch that leaves a message marked Unread when it gets loaded into a
>standalone window, even if controlled by a preference, will ever be approved.

I hope that's not the case, as ways of thinking about and using and organizing mail obviously change (sometimes drastically) over time.  Case in point - gmail.
Comment on attachment 212465 [details] [diff] [review]
(improved)Patch to allow Mark As Read to be disabled + add delay to messageWindow view

(In reply to comment #46)
> My perspective is: this feature isn't worth the effort.

And my perspective is that this Bug/feature is one of *many* that apparently "aren't worth the effort" and therefore - Thunderbird just wasn't worth the effort.

Regardless, I'll flag my patch from Feb for 'review'. Smeone else will have to pick it up and go from there as I don't even have TB installed any more.
Attachment #212465 - Flags: review+
STM attention to bug 226551 would be productive - an easier patch, could be approved today, no UI change and have the desired effect.  (Though alas, it wouldn't help my usage need comment 49)

I'm not suggesting abandon this bug, but you COULD have part of what you want today via the aforementioned bug.
Summary: Want to entirely disable marking-as-read → Want to entirely disable wait X seconds before marking a message as read
Comment on attachment 212465 [details] [diff] [review]
(improved)Patch to allow Mark As Read to be disabled + add delay to messageWindow view

I don't make the decisions on what gets fixed; I was asked for my perspective.

You don't request review by setting the '+' sign, and when you request review you *have* to ask someone qualified to do the reviewing, or it won't get done.

Your contempt for the process is far more despicable than the alleged contempt for your idea that you're railing against.
Attachment #212465 - Flags: review+
(In reply to comment #49)
> [WITHOUT the unnecessary rant against developers, which I am not nor perhaps is
> Mike]

Ok, sorry.  Please consider it amended to be a expression of my disappointment against that specific post by that specific developer.  Look at how many people are monitoring this bug, that should be an indicator that it requires some sort of resolution.  All of the issues and motivations for fixing it (or not) need to be discussed before it is dismissed.
(In reply to comment #52)
> You don't request review by setting the '+' sign, and when you request review
> you *have* to ask someone qualified to do the reviewing, or it won't get done.
> 
> Your contempt for the process is far more despicable than the alleged contempt
> for your idea that you're railing against.

Let's review:

1) I'm a first time bug patcher (already mentioned); I had to learn how to edit & write code, how to use CVS, how to create a patch. I learnt a lot on my own with very little (understandable)documentation at my disposal and I obviously didn't learn everything. Boo-hoo.
2) I looked around and didn't see anyone 'qualified'. Someone 'qualified', I would have expect, would have had the courtesy to tell me/remind me EIGHT MONTHS AGO when I posted the 2nd patch that I needed to specifically ask for review or set the flag myself. Did everyone think i just made it and posted it for kicks?
3) I hadn't ever set a review flag before; I do not see a Help link on the Edit page, and when I searched from the front page, I did not come across anything that explained the procedure. 'Contempt' doesn't even enter into it.
4) It was EIGHT months since I made the patch and even if I knew how to set a flag then (I didn't) - I'm sure I would likely have forgotten by now.
5) Ok, so I goofed. No need to throw a tantrum and make out like I did it intentionally or maliciously.
6) You still haven't explained what I should have done. I suspect I chose the wrong flag - but you never explained which was the right one.

I'll rub the magic lamp and say the magic words:
"COULD I *PLEASE* HAVE SOMEONE WHO FEELS (AND KNOWS THAT THEY ARE) QUALIFIED REVIEW MY PATCH? (and set any/all flags as necessary)"

.. and then someone take over and do whatever is necessary. I'm done with this Bug thread (with cheers from many, no doubt). I just feel bad for the few people still using Thunderbird.
Let's look at this differently.

I don't understand why a simple request (bug report) of:
"Please add a new option to allow user to disable automatic mark-as-read"
Should not be enough.
No patch provided, just user request.

For the developer who maintain the mark-as-read module, it takes about 30 minutes of developing and 1 hour of testing.

For any external contributer it takes about a year...

Just making users happy at the price of one and a half hour!

I, personally, never understood how people that use automatic-mark-ask-read without can keep track of their mails.
But! I don't understand why developers force their users to have feature they cannot disable.

In the meantime, except of this issue, I had RTL (BIDI) incompatibility, stability issues (thunderbird just gone!), MAPI offline cache periodic deletion, desktop integration issues, and much more!

So I've switched t KMail...
I fully agree with RenegadeX and I understand the point of Alon, but it's hard to demand something where development goes on as free contribution, if I'm right. I just know, I don't pay for using tb, except for sometimes loosing nerves.

I have several programming skills but unfortunately I'm unfamiliar with the workflow of bugzilla/tb development oder bugfixing.
I suggested some codechanges early this year. No one made any qualified comment or took the solution. OK. I tried, didn't understand the workflow and spent no time on it for the next months, hoping, someone familiar with the workflow would come and see. 

If I review this thread now, I ask myself if there was only one person among all this posters, with knowledge about how this thread could have been pushed forward to a possible solution or the ability to make a decision.

All the energy spent in discussing and rediscussing the same comparatively simple problem and making suggestions and bugfixes was wasted until now, because nobody seems to have the ability to decide how it should be made. 

And I don't think it is worth discussing, whether there is a problem or not. It's there, it's a small but annoying one and it could have been solved with less then a few percents of the effort, this discussioning had cost.

So please, if there is anybody who knows. What have to be done to get this thing fixed. And if there are not enough reviewers or something like that, how do we manage to get more? Is anybody interested in developing tb any further? Maybe I would, if I have enough time and know how.
> 2) I looked around and didn't see anyone 'qualified'. Someone 'qualified', I
> would have expect, would have had the courtesy to tell me/remind me EIGHT
> MONTHS AGO when I posted the 2nd patch that I needed to specifically ask for
> review or set the flag myself. Did everyone think i just made it and posted it
> for kicks?

'Qualified' mail devs are rare. 'Qualified' mail devs have work enough, so they may just take closer looks at bugs they care about and/or someone has requested review.

> 6) You still haven't explained what I should have done. I suspect I chose the
> wrong flag - but you never explained which was the right one.

Read <http://www.mozilla.org/hacking/life-cycle.html>:
"Ask [...] for a review by setting the review flag for the patch to ?"

> I'll rub the magic lamp and say the magic words:
> "COULD I *PLEASE* HAVE SOMEONE WHO FEELS (AND KNOWS THAT THEY ARE) QUALIFIED
> REVIEW MY PATCH? (and set any/all flags as necessary)"

I doubt anyone will do this (I, for one, won't), because this bug's priority is very low. Common misuse of the read state doesn't justify fixing what isn't broken, even less since we have tags now...
(Wayne, you should use tags for your usecase!)
(In reply to comment #57)
> 'Qualified' mail devs are rare. 'Qualified' mail devs have work enough, so they
> may just take closer looks at bugs they care about and/or someone has requested
> review.

I wonder if there might be more 'Qualified' mail devs if new contributors were not met with frustration and insults.

> I doubt anyone will do this (I, for one, won't), because this bug's priority is
> very low. Common misuse of the read state doesn't justify fixing what isn't
> broken, even less since we have tags now...
> (Wayne, you should use tags for your usecase!)

How is this necessarily misuse of the read state?  It seems to me that TB is broken, in that it assumes that anything that shows up in the Message Pane has been read.  This is a bad assumption.  There are all sorts of reasons why a message can get selected there, other than for the purpose of reading it.  
(In reply to comment #57)
> I doubt anyone will do this (I, for one, won't), because this bug's priority is
> very low. Common misuse of the read state doesn't justify fixing what isn't
> broken, even less since we have tags now...
> (Wayne, you should use tags for your usecase!)

ISN'T BROKEN?!?!?!

Let's say that your car automatically closes the window when you turn off the engine. Why? Because the manufacturer thought that an opened window when engine is off is bad idea.

Now... You sell this car to people... Every people that buy the car needs open the window again, after he turns the engine off.

Nothing is broken, right? This is _BY DESIGN_, people can always open the window... But why forcing them? The close-window feature _WAS ADDED_ to the car, it is not default window behavior. Why not add a simple switch to disable/enable this behavior? Giving people a choice.

I call this car a *BROKEN* car.

I understand comment#56:
> but it's hard to demand something where development goes on as free
> contribution

I support my share of projects... And I think user requests that have minor cost, should be implemented. I don't expect people with simple requests such as this one to invest time to write a patch... Since I can do this much quicker.

(In reply to comment #57)
> I doubt anyone will do this (I, for one, won't), because this bug's priority is
> very low.

I'd just like to point out that this bug is the second most voted-for Thunderbird bug in bugzilla.

> Common misuse of the read state doesn't justify fixing what isn't
> broken, even less since we have tags now...
> (Wayne, you should use tags for your usecase!)

I know about flags. The problem with these is that they aren't set automatically on a new message, whereas the "unread" flag is. This means that if I use a flag to mean "not dealt with yet", I have to manually set that on every incomming message. It's very easy to miss some. Finally, the tree view on the LHS is very useful when one uses "unread" to mean "not yet dealt with" because it becomes a quick task list. One can scan down and see the number of tasks outstanding under a whole hierarchy of folders at once.

I just want you to know that I do find this feature very useful. (Useful enough that I have patched and recompiled my own copy of TB which I run on all my PC's.)
(In reply to comment #60)
> (In reply to comment #57)
> > I doubt anyone will do this (I, for one, won't), because this bug's priority is
> > very low.
> 
> I'd just like to point out that this bug is the second most voted-for
> Thunderbird bug in bugzilla.
> 
> > Common misuse of the read state doesn't justify fixing what isn't
> > broken, even less since we have tags now...
> > (Wayne, you should use tags for your usecase!)
> 
> I know about flags. The problem with these is that they aren't set
> automatically on a new message, whereas the "unread" flag is. This means that
> if I use a flag to mean "not dealt with yet", I have to manually set that on
> every incomming message. It's very easy to miss some. Finally, the tree view on
> the LHS is very useful when one uses "unread" to mean "not yet dealt with"
> because it becomes a quick task list. One can scan down and see the number of
> tasks outstanding under a whole hierarchy of folders at once.
> 
> I just want you to know that I do find this feature very useful. (Useful enough
> that I have patched and recompiled my own copy of TB which I run on all my
> PC's.)
> 

This may not be the right place to ask, but I would be grateful to know how I apply a patch (specifically the 20/2/06 patch here) to my copy of T'bird. I agree with others that it is very useful to treat the 'as read' marker as meaning 'done with this', and I think it is strange that this is not supported by T'bird.

I can use 7-Zip to open the source archive file and thus reach the .js files, but I suspect there is some cleverer way of applying the patch than manually altering each file?
(In reply to comment #56)
> I fully agree with RenegadeX and I understand the point of Alon, but it's hard
> to demand something where development goes on as free contribution, 

And the one who freely contributed the patch (among many others) would merely like to get it applied.
(In reply to comment #57)
> I doubt anyone will do this (I, for one, won't), because this bug's priority is
> very low. Common misuse of the read state doesn't justify fixing what isn't
> broken, even less since we have tags now...
> (Wayne, you should use tags for your usecase!)

Yes, this bug is a low priority because it is marked as ENHANCEMENT. Personally I'd ditch all tags support (or other enhancements) and just have this one fixed. What's so difficult about it? Or are you the kind of guys that dream of ruling the world (MS style), imposing your opinion on everybody else? And to all other possible reviewers - there are enough people who want this option that justify a moment (or even two) of your precious time. 

Or should somebody just build Thunderbird clone with this/other patch implemented?
Comment on attachment 212465 [details] [diff] [review]
(improved)Patch to allow Mark As Read to be disabled + add delay to messageWindow view

I guess I'll have to ask myself for a review!
Attachment #212465 - Flags: review?(bienvenu)
Sorry for the delay - I tried this patch. Functionally, it seems to work fine. The issue I have is that it changes the default for new and existing users from marking messages read immediately to marking messages read after 5 seconds. I understand this isn't a big deal for you since that's the behavior you prefer, but I don't want to change the behavior for new or existing users. 

If we can figure out a way to make the time value 0 seconds for new users and users who haven't turned on delayed marking, I think that would be OK, though the UI would be a bit weird (we're basically trading a 0 second delay for a very large delay for users who don't want messages marked read). I don't have Outlook in front of me - does it default to a non-zero delay by default? What does the UI look like?

If we can solve that problem, I'd be happy to drive a patch in. 
Outlook Express has a very similar UI like thunderbird 1.5:

Nachricht lesen:
"[ ] Nachricht nach x Sekunden als gelesen markieren"

Translated (I don't know how the exact english version looks like):

Read message:
"[ ] Mark message as read after x seconds"

But there is a different handling:
- If you don't check the [ ] checkbox, messages are never marked automatically as read.
- If you check the [ ] checkbox and set the seconds to 0, messages are marked immediately.
OK, here are some other reasons. It's been suggested elsewhere that what you should do is leave all mail to be marked as read automatically, and then press m to mark a mail as unread if it really matters. But if you delete the message immediately above, then TB selects the next one down and removes the unread flag again!

Also, if I leave a mail, which is marked as unread, accidentally selected and then leave my PC for a while, can I trust TB not to go marking it as read? For years, I have used unread status as to-do, as it's extremely convenient.

Outlook Express (and the Mac version is nice, even if the Windows version sucks) has another very cool approach: mark as read when you REPLY. Automatic mark as read can be switched off, but as soon as you reply, the mail is marked as read as a signal that it is truly dealt with. I miss this in Thunderbird.

There is nothing that I know of that can be set when received, that is cleared on reply, and the context menus are tedious to keep navigating. The Mark toolbar button itself is useless because most of the menu items are read-only and indicate a message's state but cannot modify it!

I don't know the best approach for a rapid and smooth way to flag mail and have the flag auto-clear on Send, but the old Outlook Express way is very sweet -- mark as read after replying, and only then. I would press cmd-T to toggle read status otherwise (in OE:mac) if I don't plan to reply, and m does a very good job of this in TB, if only read status would simply never be set at all in the first place!
Would it be terrible to just (in attachment 212465 [details] [diff] [review]) change the default of mailnews.mark_message_read.delay.interval to 0?

We would display a zero in the UI by default, but the behaviour would be the same for old and new users. (Didn't test it though...)
if we change the default to 0, people who had previously accepted the default delay of 5 seconds would have it set to 0, because we don't write out prefs with default values to prefs.js
Setting mailnews.mark_message_read.delay.interval = 0, would simply cause messages to be marked as read the instant they're opened. It is nothing more than another way of writing mailnews.mark_message_read.delay = false.

A separate setting -- mailnews.mark_message_read.enable = true/false -- is needed for this option, which is equivalent to mailnews.mark_message_read.delay.interval = infinity.
Comment on attachment 212465 [details] [diff] [review]
(improved)Patch to allow Mark As Read to be disabled + add delay to messageWindow view

minusing, as it changes the behavior for existing users. We need a patch that upgrades users' prefs, if we're going to introduce a new pref.
Attachment #212465 - Flags: review?(bienvenu) → review-
Given the two existing prefs:

   mailnews.mark_message_read.delay
   mailnews.mark_message_read.delay.interval (changing default from 5 to 0)

In mailWindowOverlay.js, is this an acceptable solution for existing users who upgrade and for new users:

if the pref "mailnews.mark_message_read.delay" exists in prefs.js
{
     remove it
     
     if "mailnews.mark_message_read.delay.interval" exists in prefs.js
          (keep existing value)
     else
          "mailnews.mark_message_read.delay.interval" = 5 (old default)
}

With the addition of that code, it seems that the only case that wouldn't be handled is the unusual situation where someone previously enabled the delay, specified a non-default value, and later disabled the delay.  In this specific case, the new logic would use the old, unused delay value instead of zero, and I don't see a way to avoid this programmatically.

However, upon upgrading to the new version, this user would immediately know that messages are no longer being marked as read immediately, and could go into the options and set the delay to zero.  This would be a user who has already played with the delay option and who would most likely be comfortable making this adjustment after upgrading.

For all other existing and new users (the vast majority?), it seems to me that there would be no change in behavior.

If those assumptions are valid, then I'd like to summarize the work that people have done so far and to also add logic for distinguishing between the preview pane and the message window (which seems straightforward).

In the GUI options:
   change [ ] Wait N seconds before marking a message as read
   to     [ ] Mark messages as read after displaying for N second(s)

The following pref would become obsolete and would no longer exist in prefs.js or in the defaults:
   mailnews.mark_message_read.delay

Continue using this pref, but change default from 5 to 0:
   mailnews.mark_message_read.delay.interval

Add these two new prefs:

   mailnews.mark_message_read
      * mapped to checkbox in GUI options
      * boolean
      * default = TRUE

   mailnews.mark_message_read.where
      * integer
      * default = 3
      * Possible values:
         * 1 = mark only in preview pane
         * 2 = mark only in message window
         * 3 = mark in both preview pane & message window  (default)
      * the user could change this pref manually by editing prefs.js

Also in mailWindowOverlay.js:

If (message is currently marked as unread && mailnews.mark_message_read is true)
{
   If (mailnews.mark_message_read.where == 3 ||
       (mailnews.mark_message_read.where == 1 && wintype == "mail:3pane") ||
       (mailnews.mark_message_read.where == 2 && wintype == "mail:messageWindow"))
   {
      If (mailnews.mark_message_read.delay.interval > 0)
         set timer
      Else
         mark as read now
   }
}
(In reply to comment #72)

I like the above proposal very much. 

For the conversion issue i would like to suggest the following solution:

if "mailnews.mark_message_read.delay" exists
then do 
{
  if "mailnews.mark_message_read.delay" == true
  then do
  {
    if "mailnews.mark_message_read.delay.interval" >= 50000
    then do 
    {
      ### This person clearly tried to get close to infinity ###
      set "mailnews.mark_message_read" to false
      set "mailnews.mark_message_read.delay.interval" to the default value
    }
    else do
    {
      set "mailnews.mark_message_read" to true
      keep the current value for "mailnews.mark_message_read.delay.interval" 
    }
  else do
  {
    set "mailnews.mark_message_read" to true
    set "mailnews.mark_message_read.delay.interval" to 0    ### zero ### 
  }

  ### now that we are done using the old setting, we can remove it ###
  remove "mailnews.mark_message_read.delay"

}

I beleave this routine covers all situations. 

P.S. I feel the names below more cleary state the purpose of the settings mentioned in commend #72:
- "mailnews.delay_mark_message_read" 
- "mailnews.delay_mark_message_read.interval"
- "mailnews.delay_mark_message_read.where"

Sander, those are some interesting ideas, however I believe that your code has the same limitation as mine:

When users install the new version of TB, "mailnews.mark_message_read.delay" would not exist in the new default prefs.js.  The only place where it might be defined is in the users' prefs.js from their old installation.  If it does exist in their old installation, its value will always be true, never false.  This is because, as David said and as you might know, TB only saves prefs to prefs.js if they are different than the defaults.  Thus, the last ELSE clause in your code will never execute and the delay interval will never be set to zero.

------

One thing that I forgot to say in my original post is that maybe mailWindowOverlay.js is not the best place to convert the old prefs.js.  That is, it seems that ideally this conversion test would only execute when TB loads a profile rather than every time that a user selects a message.
You guys know that only non-default prefs are written to prefs.js, right? Every time prefs.js is written out, the prefs code checks if the current value is the default; if not, the pref is not written out. So the idea of checking if a pref is in prefs.js is exactly the same as checking if the pref has the default value or not.

And I don't think we can write code to read the text of the js file - we can just query the current value of the pref - and check if it matches the current default or not...but if the default changes, when we check the value, it will have changed.
(In reply to comment #75)
"You guys know that only non-default prefs are written to prefs.js, right?"
Thanks David and Pete, for pointing this out to me. I'm gonna have a closer look at this challenge.
(In reply to comment #75)
> You guys know that only non-default prefs are written to prefs.js, right?
>...if the current value is the default; if not, the pref is not written out...

This seems contradictory:  the first line says "non-default prefs are written to prefs.js" but the second says if the value is not the default, "the pref is not written out."  So non-default prefs are written to prefs.js, but are not written out.  Okay, ...?

My big problem with this pref is understanding what it meant in the first place.  I never touched it, because I thought it meant that if I enabled it (say, for the default 5 seconds), it meant that any message I retrieved would be marked 'read' after 5 seconds, irrespective of whether I opened or previewed it. It is only through reading this bug that I understand what it really means.


sorry, obviously, if the pref is not the default, it is written out.
QA Contact: preferences
Flags: blocking-thunderbird2? → blocking-thunderbird3?
This patch does the following :
- default settings :
-- mark as read on preview
-- wait for 5 seconds before to do so
#This new default behavior can be changed, but that's what Outlook Express's users are used to by default.

- prefs migration :
-- if the user kept the default settings, the behavior is kept.
-- if the user seems to have tried to disable the mark as read on preview, disable it
-- if the user has set a custom time, keep it.
-- if the user enabled the delay without modifying it or if it's a new user, mark as read after 5 seconds.

- Behavior :
-- If mark_message_read_on_preview is true, mark the message as read after mark_message_read_on_preview.delay seconds.
-- Else, do nothing.
Attachment #282684 - Flags: review?
Attachment #282684 - Flags: review? → review?(bienvenu)
Nit: It's not only about the preview pane; some people read the messages in the standalone window to, so I think in stead of mark_message_read_on_preview something like mark_message_read_manual would be a better name.

In the patch |var markReadOnADelayMigrated| is declared inside the try-catch so it looks like we will migrate each time. Similar issue for the other var declarations inside try-catches.

For the record, would also prefer you skip the new "wait for 5 seconds before to do so" as default behaviour.
(In reply to comment #81)
> Nit: It's not only about the preview pane; some people read the messages in the
> standalone window to, so I think in stead of mark_message_read_on_preview
> something like mark_message_read_manual would be a better name.

Well, this bug is about automatically marking message as read when opened on the preview pane. I think that the wording was confusing so i tried to make it more clear.
But I noticed that I forgot to change the wording of markAsReadEnd.label (I kept the one from RenegadeX), so I suggest to use "Mark messages as read after displaying for xxx second(s) _in the preview pane_".

> In the patch |var markReadOnADelayMigrated| is declared inside the try-catch so
> it looks like we will migrate each time. Similar issue for the other var
> declarations inside try-catches.

Well, I didn't know about but it doesn't seem to be the case here (only one migration).

> For the record, would also prefer you skip the new "wait for 5 seconds before
> to do so" as default behaviour.

As David said "I don't have
Outlook in front of me - does it default to a non-zero delay by default? What
does the UI look like?", I believe he prefers to make the migration easier for Outlook Express's users. Remember that current users won't be affected.
I have attached a screenshot of the read mail preferences from Microsoft Outlook 6 Express in Windows 2000. The dialog box is identical in Windows XP SP 2. On both this machine and my XP laptop, Outlook Express is still at its default settings -- on XP it had not even been run yet. I would assume that Windows Vista Mail -- basically a rebadged Outlook Express -- will be identical but it's worth someone checking (when I saw it in Home Premium, it looked like nothing much had been done to it since XP).

The default in Outlook Express 6 (and as I recall, 5 also) is to mark messages as read after five seconds.
(In reply to comment #82)
> But I noticed that I forgot to change the wording of markAsReadEnd.label (I
> kept the one from RenegadeX), so I suggest to use "Mark messages as read after
> displaying for xxx second(s) _in the preview pane_".

Don't see why the one would restrict it to just preview pane. If you do, the next day someone is gonna file a RFE for it not to be. My understanding is people generally want have it mark automatically, or do all marking them selves.

BTW, you need to update the markAsReadEnd.label name and other keys so localizers will pick up on the change.
(In reply to comment #84)
> Don't see why the one would restrict it to just preview pane. If you do, the
> next day someone is gonna file a RFE for it not to be. My understanding is
> people generally want have it mark automatically, or do all marking them
> selves.

Well, it's just that it's already like that.
When we open a message in a new window, it's always marked as read. Do you mean that it should be possible to disable that behavior or to add a delay ?

> BTW, you need to update the markAsReadEnd.label name and other keys so
> localizers will pick up on the change.

Well, I'm not sure about that. I recently asked to a member of the French translation team how they get notified in changes in the locales and he answered me "we check regularly that kind of search result : http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=%28properties%7Cdtd%29%24&filetype=regexp&who=&whotype=match&sortby=Date&hours=2&date=month&mindate=&maxdate=&cvsroot=%2Fcvsroot"
So I don't see what good it would do to change the names.
(In reply to comment #84)
> Don't see why the one would restrict it to just preview pane. If you do, the
> next day someone is gonna file a RFE for it not to be. My understanding is
> people generally want have it mark automatically, or do all marking them
> selves.

You have to consider how it all works. When you double-click an e-mail to open it in a new window, it's instantly marked as read in both Outlook Express 6 and Thunderbird 2. Likewise, in both applications, the Previous and Next toolbar buttons in the message viewer window also mark any messages read the instant you switch to them, regardless of the setting.

The setting that this bug is about only applies to the preview window in both applications despite neither program making this clear in the UI wording.
I know people want this feature e.g. for shared boxes, where they want marked as read only the things they explicitly mark read. Seems odd it would depend on their current layout. But sure, may be room for a follow-up bug...

Re the name change, trust me;) 
It's nothing anyone enjoys, but we do that for *all* string changes.
Please make the setting apply to both the message pane and the independent message window.  I always want to manually mark messages as read, never automatically.  This bug's creator seems to agree -- please see comment 18.

If the behavior should be different for the message pane and independent window, then please either file a new bug for that or add a pref to this bug so that we can control this.
Comment on attachment 282684 [details] [diff] [review]
Allow to disable mark as read on preview + prefs migration

why not mark the message read immediately if the interval is 0 seconds, instead of still using a timeout?
(In reply to comment #89)
> why not mark the message read immediately if the interval is 0 seconds, instead
> of still using a timeout?

Sure.
But what about the real purpose of this bug, disabling entirely the automatic mark-as-read (the bug's name changed since its creation) ?
Should we add a checkbox to completely disable the mark-as-read on view/open (even in a new window) behavior ?
I think there's two use cases here - one where the user uses a low value for the mark as read interval because they don't want landing on a message to mark it read right away, and then there's people who only ever want to mark messages read manually. I think for the latter group, respecting the "disable entirely automatic mark-as-read" setting for a stand-alone window makes sense. So yeah, I think so. Respecting the time interval for stand-alone message window doesn't make as much sense, but it might be OK. I don't think I'd add prefs UI for the 3-pane vs the stand-alone message window.


Changing the effect of the option (making it affect the opening in a new window) will change the behavior for the current users.
I know users who don't want the previewed messages to be marked as read but still want them to be marked as read when opened in a new window. Don't you think they'll  be confused ?
(In reply to comment #91)
> I think there's two use cases here - one where the user uses a low value for
> the mark as read interval because they don't want landing on a message to mark
> it read right away, and then there's people who only ever want to mark messages
> read manually. 
Exactly. And this is how the user interface should look:

There should be a checkbox to either wait or not wait, with the words "Wait [ ] seconds before marking as read. Ticking the checkbox would grey out the text and the field for the number of seconds.
(In reply to comment #93)
> Exactly. And this is how the user interface should look:
> 
> There should be a checkbox to either wait or not wait, with the words "Wait [ ]
> seconds before marking as read. Ticking the checkbox would grey out the text
> and the field for the number of seconds.

In other words, exactly like Outlook Express. The concern at the moment is how opening mails in a separate window comes into play. However, what you are suggesting would certainly bring the program in line with Outlook Express (that is, it would be familiar to many if they realise they have to look in Advanced for the setting as it's not where OE puts it) and resolve what I see as the real problem in that the auto-mark-as-read feature can't actually be turned off (86400 seconds is nice though).

The real snag is that the setting doesn't quite make sense. It doesn't specifically state the preview pane, so double-clicking a message appears not to obey the setting, although I am well accustomed to the behaviour from previously using Outlook Express (Mac and Windows). If the setting is made to apply to message windows too, it won't behave the same as Outlook Express, be that a good or a bad thing. Or, you can reword the checkbox to specifically refer to the preview pane, to simply resolve the direct matter at hand.

Should we settle for this, and let people argue later about how it should apply to viewing messages in new windows? I would imagine that if it mattered, people would already be complaining about that problem. Perhaps they are -- I never checked. How long do we wait to figure out what such people do or do not want?
Please apply the same semantics as for MS Outlook. Consistency will be for the benefit of Thunderbird users here.

Outlook works like this:
If "Mark items as read when viewed in the reading pane" option is checked,
then you have the ability to specify the number of seconds after which the message will be marked as read. Otherwise the number is grayed out.

When the message is opened in a full/new window it is always marked as read.
It seems that the only way to make everyone happy is if the Thunderbird team considers the idea of offering us a hidden pref to control whether the behavior affects only the message pane, only the independent window, or both.  I wouldn't care what the default value of such a pref would be for new users or for existing Thunderbird users.  And I think that it would be trivial for everyone participating in this discussion to set such a pref to what they want.  A note could be added to the Release Notes to explain the change to the GUI option and about the hidden pref.  We could finally close this bug and there would be no need for anyone to open a new bug.
(In reply to comment #96)
> It seems that the only way to make everyone happy is if the Thunderbird team
> considers the idea of offering us a hidden pref to control whether the behavior
> affects only the message pane, only the independent window, or both.

I was thinking about it too.
I'd set the default value to what the current users are used to : only affect the preview pane.
If nobody has arguments against this solution, I can update the patch to add this.

(In reply to comment #87)
>Re the name change, trust me;) 
>It's nothing anyone enjoys, but we do that for *all* string changes.

Alright, but is there a reason or is it just a habit ?
If there's no reason, why not change the habit ?
I don't know exactly what it's used for, just that we have to...
You could ask in the mozilla.dev.l10n newsgroup... 
About the hidden pref, I was wondering if it couldn't just completely disable the automatic mark_as_read behavior, instead of switching the GUI option scope from preview pane to all (so the checkbox could be grayed out).
Clearly said : does anybody need a message opened in new window to be only marked as read after xx seconds or can we divide the needed behavior (for messages opened in a new window) in two : users that want messages to be marked as read on open and users that prefer to do it manually ?
Don't answer if you recognize yourself in one of these two types.

(In reply to comment #98)
> I don't know exactly what it's used for, just that we have to...
> You could ask in the mozilla.dev.l10n newsgroup... 

I've been told that the name change make it possible to see the locale change in their tinderbox.
I just wanted to say that I'd love to see this bug finally closed. The "hidden pref" suggested in comment #96 sounds like the best solution. That way, even if the GUI doesn't quite cover everyone's tastes, by simply editing the prefs file everyone will be able to get the behaviour that they really want.
Here's what changed from the other patch :
- new hidden pref to completely disable auto mark_as_read
- locale entities names (I also added "in the preview pane" for the GUI option)
- var declarations outside of try catch to avoid any scope problems
- no setTimeout when the delay == 0

I didn't grayed out the GUI option when the auto mark_as_read is disabled since the interface isn't updated when the configuration editor's window is closed.
Attachment #282684 - Attachment is obsolete: true
Attachment #282914 - Flags: review?(bienvenu)
Attachment #282684 - Flags: review?(bienvenu)
Hi,

I tried Thomas Bertels' patch, which he kindly sent to me by e-mail.

Unfortunately, this patch does not work properly for me with my IMAP e-mail account. To be specific, if I move through the messages in my inbox with the "n" key on the keyboard, then many messages are marked as read when they appear in the preview pane. This is especially a problem for large messages which take some seconds to download.

Can someone who understands these things check whether one must patch Thunderbird's C++ source code as in my Feb 2006 patch in order to ensure that IMAP "PEEK" commands are used to fetch the message body as well as adjusting the javascript and the UI?

Chris.

This patch improves on the one from Thomas Bertels by treating IMAP mail properly.
Attachment #211970 - Attachment is obsolete: true
Attachment #284762 - Flags: review?
Hi,

Please could someone with CVS access look over my most recent patch and tell me whether it is good enough to be included, or if not, what changes I must make?

Also, please could someone who knows the Thunderbird code base help me solve these remaining niggles:

1. There are two copies of mailWindowOverlay.js in the Thunderbird source tree: one is in mozilla/mail/base/content/mailWindowOverlay.js and the other is in mozilla/mailnews/base/resources/content/mailWindowOverlay.js

What is the difference between these?

2. mozilla/mailnews/base/prefs/resources/content/pref-viewing_messages.xul refers to the mark_message_read preference. However, I cannot see where this XUL file appears in the Thunderbird UI?

Does this file need to be updated with the revised preference names, etc.?

3. mozilla/mail/base/content/commandglue.js and mozilla/mailnews/base/resources/content/commandglue.js refer to a set of preferences  "mailnews.mark_message_read." + aFolder.server.type

I've not seen these defined / used elsewhere.

Do we need to modify these for this patch?

I hope that this patch will allow this long-standing bug with many user votes to be closed.

Chris.

4.
Attachment #284762 - Flags: review? → review?(bienvenu)
the mailnews version of mailWindowOverlay.js is for SeaMonkey; the mail one is for Thunderbird. Both need to be changed, since you're also changing common code. That means that you need to get a reviewer from SeaMonkey for the SM part of the change. Karsten, who I think is cc'ed, is a good candidate.

Similarly, I think pref-viewing_messages.xul is used for SeaMonkey. Thunderbird and SeaMonkey have different prefs ui.

The mailnews.mark_message_read+server type pref is off by default, so you don't have to worry about it. It's for people who want every message in a folder to be marked read when they leave the folder. I believe it's mostly used for newsgroups.

I'll try to look at the patch as soon as I can. I think you do have to worry about the SeaMonkey code as well since, iirc, you're changing the prefs the shared code uses.
Attachment #282914 - Attachment is obsolete: true
Attachment #282914 - Flags: review?(bienvenu)
changing summary to describe what's being requested afaict rather than something that's already available
Summary: Want to entirely disable wait X seconds before marking a message as read → Want to entirely disable marking a message as read when viewed
Comment on attachment 284762 [details] [diff] [review]
Allow to disable mark as read on preview or always + prefs migration + IMAP support

>+<!-- LOCALIZATION NOTE (markAsReadPreview.label): This will concatenate to
>+     "Mark messages as read after displaying for xxx second(s) in the preview pane",
>+     using (markAsReadPreview.label) and a number (markAsReadPreviewEnd.label). -->
>+<!ENTITY markAsReadPreview.label       "Mark messages as read after displaying for">
>+<!ENTITY markAsReadPreview.accesskey   "M">
>+<!ENTITY markAsReadPreviewEnd.label    "second(s) in the preview pane">

Not a term used in tbird ui; View -> Layout menu suggests "Message Pane".

>-      PRBool forcePeek = PR_FALSE; // should the message fetch force a peak or a traditional fetch? 
> 
>-      if (NS_SUCCEEDED(rv) && prefBranch) 
>-         prefBranch->GetBoolPref("mailnews.mark_message_read.delay", &forcePeek);
>-      
>+	  // should the message fetch force a peak or a traditional fetch?
>+	  PRBool forcePeek = PR_TRUE;

fix the typo while moving the comment?

>+	  PRBool markMsgReadAuto = PR_TRUE;
>+      PRBool markMsgReadOnPreview = PR_TRUE; 
>+	  PRInt32 markMsgReadOnPreviewDelay = 5;

tabs

>-// set to true if viewing a message should mark it as read only if the msg is viewed for a specified time interval in seconds
>-pref("mailnews.mark_message_read.delay", false); 
>-pref("mailnews.mark_message_read.delay.interval", 5); // measured in seconds
>+// set to true if viewing a message should mark it as read after the msg is viewed in the preview pane for a specified time interval in seconds
>+pref("mailnews.mark_message_read_on_preview", true); 
>+pref("mailnews.mark_message_read_on_preview.delay", 5); // measured in seconds
>+
>+// set to false if opening a message or viewing it in the preview pane should never mark it as read
>+pref("mailnews.mark_message_read_auto", true); 

looks like you're changing the default behavior to include a weird artificial delay for the user to stress about racing against, here.
Attachment #284762 - Flags: review?(bienvenu) → review-
(In reply to comment #107)
> looks like you're changing the default behavior to include a weird artificial
> delay for the user to stress about racing against, here.

As said in comment 82, this is to make the migration easier for
Outlook Express's users.
I don't see how it adds stress.
(In reply to comment #105)

> The mailnews.mark_message_read+server type pref is off by default, so you don't
> have to worry about it. It's for people who want every message in a folder to
> be marked read when they leave the folder. I believe it's mostly used for
> newsgroups.

The little orange thingy on my folders disappears when I go to another email (not news) folder. I would prefer it keep the remaining messages as new. If this is currently possible, could someone say how?

Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.10pre) Gecko/20071105 Thunderbird/2.0.0.7pre ID:2007110504



(In reply to comment #107)

> looks like you're changing the default behavior to include a weird artificial
> delay for the user to stress about racing against, here.

I think that was the original intent of this bug. I usually bump it up to 55 seconds or something like that. Now that you mention it, it DOES feel like a race in fact, without this bug fixed.


The bug in marking message as read encompasses several problems.

Firstly, it does not work with "some" messages.  They seem to be some of the ones that have HTML content - despite my settings, some messages with remote content get marked as read immediately upon being previewed or opened.  Others do not.  I have not been able to find a common denomenator, but would be happy to forward sample Emails for perusal.

Secondly, it only works in preview.  If I open a message in its own window (by double clicking it), the message is immediately marked as read (and if this happens just before my system syncs with the (AOL) server, the message gets moved into the "read" folder, and is no longer available for reply.  Since it is no longer listed, it cannot be dragged or copied into a local folder.  I must open the "read mail" folder and retrieve it again.  (note - AOL has separate "new mail" and "read mail" folders on their server)

The first two issues are bugs in execution - the program does not do what the programmer intended.  The next is one of concept - the program does not do what the programmer =should= have intended.  (IMEO, of course.  :)

Continuing... thirdly the marking of messages as read should happen based on when the user reads them, not when it is displayed on the screen to the (possibly distracted) user.  It may take a while for a user to actually read a message he or she has displayed on the screen.  As far as the machine is concerned, this means it should be tied to when the message is =closed= by the user, not when it is opened.  The option to delay before marking as read seems to be an attempt to work around this issue while sticking with the opening of a message as the starting point.  This is not the best way, and is not "expected behavior".  (at least not by me, and I've used these machines for many years).

Since the code to time from the opening is already there, and some users may be accustomed to it, it can be retained, but timing from the closing of a message should also be implemented.  That will address the issue at hand, which is...

I open a message, start reading it, and get distracted (say, typing a reply, doing research, or stirring the soup).  When I come back, I expect the message (which I'm not done with) to still be there, and my options about what to do with the message to be unchanged.

So, to address the third issue, I propose that the settings be changed to be something like the below:  

upon previewing a message (in the preview pane)
  o  immediately mark message as read
  o  wait [  ]  seconds (max 4294967295) and then mark message as read
  *  do nothing

upon opening a message (in a separate window)
  o  immediately mark message as read
  o  wait [  ]  seconds (max 4294967295) and then mark message as read
  *  do nothing

upon leaving a message  (this includes closing 
      a message window and/or viewing another message)
  o  immediately mark message as read
  *  wait [ 30 ] seconds (max 4294967295) and then mark message as read
  o  do nothing

Note to developers - should I have filed three separate bugs or kept them together as related here?

Jose

Absolutely!  This is quite inconvenient:  Every time an e-mail is simply selected (whether by the user, or just happenstance  ...such as if a new e-mail is downloaded), the e-mails are marked  --but I haven't read them!!

Please make this behavior optional;  or, least expose the function to those clever extension programmers...

Thanks, 

--Rich
This bug stand for about 3 years for now, we should bring more attention on it before releasing TB3, and probably block TB3. So much discussions and not patch in trunk yet.
Chris: can you provide an updated version of the patch, addressing comment #107?
Please keep the default to no delay, oe users "needing" a default delay is not a primary concern here.

In the last patch you delete prefs from mailnews.js without fixing seamonkey also. You either need to fix them at the same time (=similar fixes in the mailnews and suite dirs) or work around it some other way.

Not a blocker but would be nice to get in for tb3, it's a popular request.
Assignee: mscott → nobody
Flags: wanted-thunderbird3+
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3-
Chris wrote me he doesn't have time to update the patch. Taking it myself...

Having looked at it a bit more I understand the new 5 sec proposed default delay. On one hand it's not what I would like, but on the other hand a default of 0 sec in the text box do look a bit unusual. (Still think we should go with no delay though.)
Assignee: nobody → mkmelin+mozilla
>>
Having looked at it a bit more I understand the new 5 sec proposed default
delay. On one hand it's not what I would like, but on the other hand a default
of 0 sec in the text box do look a bit unusual. (Still think we should go with
no delay though.)
<<

The problem (which a five second delay won't fix) is that messages are marked =read= when they have only been =presented=.  That's a significant difference to the user.  (see comment 112).  Is it =possible= to mark a message as read when the user =leaves= the message (closing a window, going to the next message, etc) rather than when the user arrives there?

Jose

I _do_not_ want messages to be marked as read when I leave them! I want messages to be marked as read ONLY when I've read them. Since the program can't know this unless I tell it, it follows that a message should be marked as read only when I mark it as read.
>>
I _do_not_ want messages to be marked as read when I leave them! I want
messages to be marked as read ONLY when I've read them. Since the program can't
know this unless I tell it, it follows that a message should be marked as read
only when I mark it as read.
<<

... which is why I proposed (comment 112) that it be a user-selectable option.  Marking (as read) when leaving is useful behavior, and some might prefer it.  Marking when arriving makes no sense (to me, but may to others).  Marking on command is most precise, but requires more user action.  Users should be choosers.

Jose


Jose

(In reply to comment #121)
> ... which is why I proposed (comment 112) that it be a user-selectable option. 
> Marking (as read) when leaving is useful behavior, and some might prefer it. 

That behavior is likely more involved as code changes go than the various combinations of don't-mark suggestions here that only tweak the conditions of existing marking sites, and it sounds rather hairy to use -- a few issues that come to mind are: close and deselect don't commonly come with that sort of side effects; the indication of the change is more likely on an item that is out of view; leaving a viewed message while leaving it not-read requires more steps. Hence, that suggestion should probably be discussed elsewhere.
Attached patch proposed fix (obsolete) — — Splinter Review 
This is an unbitrotted, slightly tweaked version of the previous patch attached to this bug, now for the suite too.
Attachment #212465 - Attachment is obsolete: true
Attachment #284762 - Attachment is obsolete: true
Attachment #322669 - Flags: superreview?(bienvenu)
Attachment #322669 - Flags: review?(mnyromyr)
Target Milestone: --- → Thunderbird 3
I agree that a default of 0 seconds is preferable, but also looks weird. I'm afraid I don't understand the default of 5 seconds. Is that from some other app like Outlook or OE? It seems like if the default is 5 seconds, and the user doesn't want a message to get marked read, they're going to have to very quickly go to a different message. I understand always wanting to control when a message is marked read by never letting the mail client do it automatically, but racing the clock seems odd to me.
The 5 sec delay is from OE. Outlook uses a default 1 sec delay I think. The Outlook UI is:

 [x] Mark items as read when viewed in the Reading Pane
       Wait [_1__] seconds before marking items as read
 [ ] Mark items as read when selection changes

Maybe we could skip the delay option altogether...? 
Comment on attachment 322669 [details] [diff] [review]
proposed fix

Basically, the current alternatives are:
- mark message as read immediately
- mark message as read after n seconds

This bug is about:
- mark message as read immediately
- mark message as read after n seconds
- never mark message as read automatically

Any attempt to squeeze the latter into the old pref UI is doomed.

On pref level, the solution would be rather simple:
migrate the boolean mailnews.mark_message_read.delay to an int mailnews.mark_message_read.mode with values:
0 = automatically mark message as read immediately
1 = automatically mark message as read after n seconds
2 = never mark message as read automatically

To avoid migration problems for users of the old default values, the default value for .mode would be 0, which is equivalent to .delay=false.

Thus, the pref UI should reflect the (now) three alternatives:

+----------------------------------------+
| Automatically mark messages as read:   |
| (*) Immediately on display             |
| ( ) After displaying for [ n ] seconds |
| ( ) Never                              |
+----------------------------------------+

I don't think it pays off to distinguish between mail:3pane and mail:messageWindow - using a delay>0 for the standalone message window doesn't seem to be particularly useful, but it doesn't hurt.
(It'd be cleaner to assume n=0 in the mail:messageWindow case, though.)


Since the changes for /mail and /mailnews are the same, I won't comment on both.

>Index: mail/base/content/mailWindowOverlay.js
>===================================================================
>+    var markReadMsgPane = gPrefBranch.getBoolPref("mailnews.mark_message_read_msg_pane");
>+    var markReadMsgPaneDelay = gPrefBranch.getIntPref("mailnews.mark_message_read_msg_pane.delay")
>+    var markReadManuallyOnly = gPrefBranch.getBoolPref("mailnews.mark_message_read_manually");

Trunk has "let", there's no need to define lots of probably unused variables beforehand anymore.
And, as said above, I don't think the three new prefs are needed or useful.
(If using the int values, it'd probably be best to predefine the three values as consts to enhance readability.)

Oh, and the pref names itself are rather ugly and unintuitive, imo.
They should at least have a dot behind read. (But see above.)

>Index: mail/base/content/msgMail3PaneWindow.js
>===================================================================
>+/** Migrate mark as read preferences to the Thunderbird3 format. */
>+function MigrateMarkReadMsgPanePrefs()
>+{
>+  var markReadOnADelayMigrated;
>+  try {

Prevalent style is braces-on-their-own-lines; please don't mix inside a file.

>+    markReadOnADelayMigrated = gPrefBranch.getBoolPref("mailnews.mark_message_read.delay.migrated");

You only need this when you change the default behaviour (which I don't think we should do anyway).
Even then, using a boolean isn't quite future-proof; we usually use something like mail.ui.threadpane.version etc.

>+    // The user had tried to disable the mark as read when viewing
>+    // in the message pane.
>+    else if (markReadOnADelayInterval > 120)
>+      gPrefBranch.setBoolPref("mailnews.mark_message_read_msg_pane", false);

This is a very presumptuous claim... ;-)
I don't think it's useful, especially with regard to older machines and large threads.

>Index: mail/components/preferences/advanced.xul
>===================================================================
>+            <checkbox id="markAsRead"
>+                      label="&markAsReadMsgPane.label;"
>+                      accesskey="&markAsReadMsgPane.accesskey;"
>+                      preference="mailnews.mark_message_read_msg_pane"
>                       oncommand="gAdvancedPane.updateMarkAsReadTextbox(true);"/>
>-            <textbox  id="markAsReadDelay" size="2" preference="mailnews.mark_message_read.delay.interval"/>
>-            <label value="&markAsReadEnd.label;"/>
>+            <textbox id="markAsReadDelay" size="2"
>+                     preference="mailnews.mark_message_read_msg_pane.delay"/>
>+            <label value="&markAsReadMsgPaneEnd.label;"/>

You're lacking accessibility attributes here, see the respective SeaMonkey file.

>Index: mail/locales/en-US/chrome/messenger/preferences/advanced.dtd
>===================================================================
>+<!-- LOCALIZATION NOTE (markAsReadMsgPane.label): This will concatenate to
>+     "Mark messages as read after displaying for xxx second(s)",
>+     using (markAsReadMsgPane.label) and a number (markAsReadMsgPaneEnd.label). -->
>+<!ENTITY markAsReadMsgPane.label       "Mark messages as read after displaying for">
>+<!ENTITY markAsReadMsgPane.accesskey   "M">
>+<!ENTITY markAsReadMsgPaneEnd.label    "second(s)">

I don't think the () are needed just vor one value which isn't even the default.

>Index: mailnews/mailnews.js
>===================================================================
>+// Set to true if opening a message in the standalone message window or viewing
>+// it in the message pane should never mark it as read.
>+pref("mailnews.mark_message_read_manually", false);

Even when using it at all, I'd say that something like mailnews.mark_message_read.auto is clearer (and it saves you some ! ;-) ).

>Index: mailnews/imap/src/nsImapService.cpp
>===================================================================
>-  
>+

Quite some whitespace cleanup, yeah! :-)

>+      // Should the message fetch force a peek or a traditional fetch?
>+      PRBool forcePeek = PR_FALSE;
>+      PRBool markMsgReadManuallyOnly = PR_FALSE;
>+      PRBool markMsgReadMsgPane = PR_TRUE;
>+      PRInt32 markMsgReadMsgPaneDelay = 5;

There's no need to define most of these on this level and no need to set forcePeek outside of the if branch. In fact, there's no need for forcePeek at all; if you have to do such extensive computations, you could use a variable for nsIImapUrl::nsImapMsgFetchPeek etc.directly.


In toto, I think the patch is far too complex for the relatively small issue it should fix...
Attachment #322669 - Flags: review?(mnyromyr) → review-
Attachment #322669 - Flags: superreview?(bienvenu)
The other half of this bug is that the marking of messages as read sometimes happens immediately even when the user (at least in my case) has selected some other (in my case large) value for a delay.  I have not been able to figure out which messages trigger this behavior, but they are often those with HTML content.

Messages are also marked read (despite any chosen delay) when one double-clicks on a message to read it in a new pane (so that, for example, I can make the type bigger in one window without altering the settings in my main (preview) window).  This needs to be fixed before (or along with) the new options, which I hope will be available to the 1.x crowd (Win 98 compatible).

I would also recommend that a new keystroke be defined which would mark a message as read AND go to the next message, if the fix doesn't include the option of automatically marking as read when one leaves a message.

Jose



(In reply to comment #127)
> The other half of this bug is that the marking of messages as read sometimes
> happens immediately even when the user (at least in my case) has selected some
> other (in my case large) value for a delay.  I have not been able to figure out
> which messages trigger this behavior, but they are often those with HTML
> content.
> 
> Messages are also marked read (despite any chosen delay) when one double-clicks
> on a message to read it in a new pane (so that, for example, I can make the
> type bigger in one window without altering the settings in my main (preview)
> window).  This needs to be fixed before (or along with) the new options, which
> I hope will be available to the 1.x crowd (Win 98 compatible).

YES!  This bug is very prevalent, and absolutely infuriating.  I've actually opened bug #410148 regarding it quite awhile ago, but there's been no progress in diagnosing the issue.  The random instantaneous marking read of messages is more distracting and problematic for me than probably any other Thunderbird bug that I've come across.
Attached patch proposed fix, v2 — — Splinter Review 
Good points, hope I got most of them included in this new patch. 
I realized there is no need to migrate prefs. See the (upcoming) screenshot.

One oddness I noticed testing this patch, is that on IMAP (but not POP), msgHdr.isRead is wrong - though if I set the status manually to unread, then things work as expected. (Possibly that's bug 410148, or one of the other mentioned problems in this bug, or then some trunk issue.)
Attachment #322669 - Attachment is obsolete: true
Attachment #323277 - Flags: superreview?(bienvenu)
Attachment #323277 - Flags: review?(mnyromyr)
Attached image screenshot, v2 — 

    
    

    
  
Is there any reason why we should have "immediately" and "after [__] seconds" separately? Isn't entering 0 in the latter the same as the former? Or otherwise, what would be the difference? It looks only confusing to me.

[x] Mark as read automatically after [__] seconds

Something simple like this is better, IMHO.

    
    

    
  
(In reply to comment #131)

> [x] Mark as read automatically after [__] seconds

I tend to agree I guess, but see comment 118 and comment 124

    
    

    
  
Comment on attachment 323277 [details] [diff] [review]
proposed fix, v2

Looks good!

(In reply to comment #131)
> [x] Mark as read automatically after [__] seconds
> 
> Something simple like this is better, IMHO.

That's not simple, that's simply ambiguous, see various comments in this very bug.

        Attachment #323277 -
        Flags: review?(mnyromyr) → review+

    
    

    
  
(In reply to comment #133)
> (From update of attachment 323277 [details] [diff] [review])
> Looks good!
> 
> (In reply to comment #131)
> > [x] Mark as read automatically after [__] seconds
> > 
> > Something simple like this is better, IMHO.
> 
> That's not simple, that's simply ambiguous, see various comments in this very
> bug.

How is it ambiguous?

- ([ ], [__] disabled): "DO NOT mark as read automatically"
- ([x], [0 ]): "DO mark as read automatically immediately (=after 0 seconds)"
- ([x], [n ](>0)): "DO mark as read automatically after n seconds"

Is there any difficulty in understanding that "immediately" is the same as "after 0 seconds"? I don't think so.

The ambiguity with the current version, IMHO, comes from the fact that the verb is "Wait", so unchecking the box would mean "DO NOT wait before marking", which is the same thing as "DO wait 0 seconds before marking", though some people might (want to) interpret it as "DO NOT mark". In my phrasing, there's only one verb, "Mark", so it's not ambiguous -- either DO mark or DO NOT mark, and only in the former case does the time matter.

I wrote comment #131 after reading the whole discussion, but might have missed something due to the large volume. If you could point me to the relevant specific comments, that would be great.

    
    

    
  
I think the discussion about "mark message read after [__] seconds" (a good phrasing, imho) misses the point.  I don't like things happening without my explicit authorization either, but I find it convenient to have messages marked read automatically (without my explicit authorization every time) when I have actually read them.  It's a useful option.

However, merely fixing this half of the "mark as read" bug does not provide that option, and if we (or you... I'm not really qualified!) are digging into the code to make changes, let's do it right and actually provide the functionality that the "mark message read" seems to be designed to do.

The key is... how does the computer suss out that I have actually read the message?  The best answer I can come up with is that when I =arrive= at a message, I haven't done anything yet, but when I =leave= a message, I'm usually done with it, and would =then= like it marked as read.   Now, sometimes I'm not done with it, and might want to prevent that action, so should be given a chance.

So, I would rate:

"Mark as read [ ] seconds after arrival" as being nearly useless.  If that were the only option, I would not elect to use it, preferring to do things by hand (bother that it is).

However...

"Mark as read [ ] seconds after departure" is very useful.  It would be even more useful (worth a lot of work to implement) if in the interim, the message were marked as "in process" or something.... the impact of that being that one could then (in the listing) choose to see messages that are "new or in process", so that one could mark an in-process message UNREAD during its pending time, if this is a message one wants to be marked unread.

One of the annoying things about having a message inappropriately marked as read is that, in a busy newsgroup (for example), that message essentially disappears.  One can select "show all messages" but then good luck trying to find that one important message that you didn't finish with.  There's no "show the next-to-last message I was reading" feature.

But if we had a pending flag, and marking based on "leaving" a message, all this would be solved.

Jose


    
    

    
  
(In reply to comment #135)
> "Mark as read [ ] seconds after arrival" as being nearly useless.  If that were
> the only option, I would not elect to use it, preferring to do things by hand
> (bother that it is).

Even that's better than the current situation, in which users cannot prevent the automatic marking at all. And there are probably other users who are familiar with the similar option in Outlook Express.

> "Mark as read [ ] seconds after departure" is very useful.

Can you elaborate on this? I don't see what is the point in waiting after leaving a message; it will eventually be marked as read, no matter what you do with the next message you move on to. Then what's the difference between marking it as read immediately as you move on, or after 5 seconds?

Another question is, what do you do to keep a message as unread even after you read it? Under the mark-as-you-arrive scheme, you can manually mark it as unread and move on to another. Under the mark-as-you-leave scheme, you cannot manually mark it as unread -- it is still unread -- and then leaving it will mark it as read.

Maybe the following can be the answer to this problem, but I fail to understand it very well, unfortunately. Moreover, it would require a new message status (we should also think how other mail clients would handle the new status flag), and it would be a new feature, not a bugfix. I suggest that the bug in the erroneous wording be fixed first, and the new feature be developed later.

> It would be even
> more useful (worth a lot of work to implement) if in the interim, the message
> were marked as "in process" or something.... the impact of that being that one
> could then (in the listing) choose to see messages that are "new or in
> process", so that one could mark an in-process message UNREAD during its
> pending time, if this is a message one wants to be marked unread.

    
    

    
  
> Even ["Mark as read [ ] seconds after arrival"]
> is better than the current situation

Marginally.  You see, this isn't just one bug, it's a basket of bugs (which includes the marking of messages as read when opened in their own window, regardless, and the =sometimes= marking of =some= messages as read (with no pattern I can discern, except that they seem to be a subset of HTML messages).  It takes almost as much effort to half-fix as to completely-fix.

>>
> "Mark as read [ ] seconds after departure" is very useful.

Can you elaborate on this? I don't see what is the point in waiting after
leaving a message; it will eventually be marked as read, no matter what you do
with the next message you move on to.
<<

The idea is that arrival is poorly correlated with having read a message, but leaving is much better correlated.  Most of the time, when you leave a message, you have read it.  But when you arrive at a message, you don't know what's in it, and don't know how long you will be reading it, or what will distract you while you have it open.  So an option to mark as read when leaving is a useful option.

>>
Under the mark-as-you-leave scheme, you cannot
manually mark it as unread -- it is still unread -- and then leaving it will
mark it as read.
<<

One way is to go back to the list.  I read in preview so the list is always available - those who read message to message probably have the list (accessible) in the background.  It is an option that would be seldom used (if it were often used, then the user would opt not to have the message auto-marked at all)

How's about something like this:

Press {space} to leave a message AND mark it as read.
Press R ("retain") to leave a message and NOT change the status flag.

I don't know all the ways there are of leaving a message, but at least we can have two "paths" for the common actions - one that marks, and one that doesn't.

>>
I suggest that the bug in the
erroneous wording be fixed first, and the new feature be developed later.
<<

If a bug is small, I agree.  But this isn't a small bug, so I expect some re-thinking of the code is needed.

The key question is:
When you arrive at a message, are you probably done with it?
When you leave a message, are you probably done with it?

(oops, that was two questions... The two key questions are... aaaaiiieeeeee!)

Jose


    
    

    
  
(In reply to comment #137)
> > Even ["Mark as read [ ] seconds after arrival"]
> > is better than the current situation
> 
> Marginally.  You see, this isn't just one bug, it's a basket of bugs (which
> includes the marking of messages as read when opened in their own window,
> regardless, and the =sometimes= marking of =some= messages as read (with no
> pattern I can discern, except that they seem to be a subset of HTML messages). 
> It takes almost as much effort to half-fix as to completely-fix.

I was just saying about the proposal to let the users disable the automatic marking, which probably requires change of the wording. This is a design problem; i.e. the developers designed it that way, no matter how good or bad the decision is. If *some* messages are *sometimes* marked as read, then it's an implementation problem; i.e. the program is not behaving as the developers intended.

> >>
> > "Mark as read [ ] seconds after departure" is very useful.
> 
> Can you elaborate on this? I don't see what is the point in waiting after
> leaving a message; it will eventually be marked as read, no matter what you do
> with the next message you move on to.
> <<
> 
> The idea is that arrival is poorly correlated with having read a message, but
> leaving is much better correlated.  Most of the time, when you leave a message,
> you have read it.  But when you arrive at a message, you don't know what's in
> it, and don't know how long you will be reading it, or what will distract you
> while you have it open.  So an option to mark as read when leaving is a useful
> option.

You have entirely missed my point. I asked, "what is the point in waiting after
leaving a message?" and "what's the difference between marking it as read immediately as you move on, or after 5 seconds?"

And frankly, I don't see much difference in mark-as-you-arrive and mark-as-you-leave. In either case, the message is unread before you arrive, and it is marked read after you leave. The only difference is while you're on the message, but does it matter much whether it's marked read or unread while you're reading it? It's only a transient state, and after a while, it will be the same! The only non-transient difference I can think of happens when the program crashes while you're on it, but it's not very likely anyway.

The real difference comes from specifying "DO NOT mark automatically", not from whether it's "Mark upon arriving" or "Mark upon leaving".

> >>
> Under the mark-as-you-leave scheme, you cannot
> manually mark it as unread -- it is still unread -- and then leaving it will
> mark it as read.
> <<
> 
> One way is to go back to the list.  I read in preview so the list is always
> available - those who read message to message probably have the list
> (accessible) in the background.  It is an option that would be seldom used (if
> it were often used, then the user would opt not to have the message auto-marked
> at all)

You mean clicking the green icon? Fine, but unfortunately it's possible only with the mouse. Ideally, I wouldn't want to look up the message in the list, either. (It might even have scrolled off the view.)

> How's about something like this:
> 
> Press {space} to leave a message AND mark it as read.
> Press R ("retain") to leave a message and NOT change the status flag.
> 
> I don't know all the ways there are of leaving a message, but at least we can
> have two "paths" for the common actions - one that marks, and one that doesn't.

There are so many ways to leave a message: n, p, f, b, [, ], and so on. Maybe you need a modifier indicating that you don't want it marked as read as you leave it.

On the other hand, having to visit another message just to leave a message has been a pain in the neck for me (especially with Gmail IMAP); I keep locating an already-read message and choosing it just to avoid marking another message as read. Maybe we need a command that lets us leave a message without opening another by closing the preview pane temporarily, and reopens the pane automatically as we choose another message.

> The key question is:
> When you arrive at a message, are you probably done with it?
> When you leave a message, are you probably done with it?

They depend on each user's preference and usage pattern. (They're not simple no and yes.)

Some may prefer marking as read only those messages they're done with, but some may prefer unread messages to mean "I've never seen it" (which is IMHO closer to the original meaning of read/unread). (Not that the others are wrong.) And in the former case, leaving the message does not always mean you're done with it; you may have to leave it unread and come back later to deal with it.

For those who want the "read" flag as "done", the program cannot guess correctly when you're done with a message; neither when you arrive nor when you leave can it say for sure you're done. So you need a way to manually tell the program anyway, and that's why some people here are proposing to let the users disable the automatic marking. When you allow the automatic marking, as I said above, there's no much difference between mark-as-you-arrive and mark-as-you-leave anyway.

    
    

    
  
(In reply to comment #137)
The question isn't "are you done with it", read is about "did you look at it yet". If you aren't done with it, star mark it or tag it appropriately.

I too fail to see the point of having an option to mark as read on leaving the message. The end result is the same - after moving on it would still be read. (And it wouldn't be this bug anyway.)

    
    

    
  
(In reply to comment #139)
> (In reply to comment #137)
> The question isn't "are you done with it", read is about "did you look at it
> yet".

For me, it's the other way round. "Read" is an extremely useful way to mean "I am done with this message".

Why is this so useful... well, it's automatic... fresh messages start out unread. I use server-side filtering to drop messages into many folders according to task. The folder view then very nicely highlights folders with outstanding items - and even gives a helpful count of the number!

This is MUCH easier than trying to be sure to "star" every message that needs follow-up.

Chris.

    
    

    
  
So, I would say, leave the meaning of 'read' to individual users.
With the ability to disable the automatic marking, each user can choose.

And my initial point was that this one line

    [x] Mark as read automatically after [__] seconds

was enough for that. As simple as this.

<side>
If it's not clear yet, would an extra pair of parentheses help?

    [x] Mark as read automatically (after [__] seconds)

</side>

    
    

    
  
(In reply to comment #131)
> [x] Mark as read automatically after [__] seconds

+1.  It's simple, easy to understand, and it's the same as Outlook Express (which has "[ ] Mark message read after displaying for ___ second(s)").  I don't think you need the extra parentheses.


Jose wrote:
> I would also recommend that a new keystroke be defined
> which would mark a message as read AND go to the next message,
>
> How's about something like this:
>
> Press {space} to leave a message AND mark it as read.
> Press R ("retain") to leave a message and NOT change the status flag.

These keystrokes already exist:  t and n
Even today you can press t to mark it as read and go to the next message, or n to keep it unread and go to the next message.  The problem, and the specific purpose of this bug, is to completely disable the automatic marking of messages as read so that we can use t and n to manually control this.

    
    

    
  
reply to 142 and 138
>>
I was just saying about the proposal to let the users disable the automatic
marking, which probably requires change of the wording. 
<<

I agree that users should be able to disable automatic marking.  To do that, it is sufficient to correctly implement:

  [x] Mark as read automatically [__] seconds after viewing

AND

to fix the "messages are =sometimes= being marked as read anyway" bug.  Then...

If the box is unchecked, messages should not be marked read, and the bug (mis-implemented feature) will be fixed.

However, what brought this up is that the =reason= (I speculate) that many people (well, me anyway!) want to disable automarking is that the automarking =as= =designed= doesn't make sense.  So, it would be a shame to just fix the bug and move on (though I suppose it would at least let me use my workaround).

>>
Even today you can press t to mark it as read and go to the next message, or n
to keep it unread and go to the next message.
<<

"t" (at least on my system) marks the entire thread as read, and jumps to the next thread, not the next message.

>>
You have entirely missed my point. I asked, "what is the point in waiting after
leaving a message?"
<<

By waiting, the user has a chance to say "oops" and actually find the message he or she just left to go click click on the green dot.  If the message is marked read immediately after leaving, it gets tossed in the (perhaps huge) pile of already-read newsgroup messages.

>>
does it matter much whether it's marked read or unread while you're reading it?
<<

Yes.  One can get distracted while reading a message, especially when doing several things at once, or if one is married.  :)

However, there is a better (perhaps) way to accomplish this task which will not complicate matters with a delayed marking or a "pending" flag.

If there was a history kept of the last (n) messages viewed, and one could go back in that history and see those messages, that would be an even better solution.  Then messages can be marked read when leaving (the better way IMHO) or when arriving, without losing oopsability.

So, I propose as the solution the two pronged:

1:  Incorporate (new feature) a message history:
    [x] retain history of last [  ] (0-256) messages viewed.
    [ ] Use separate history for each [account | account type]
        (account means each email address or newsgroup server)
        (account type means "POP email, IMAP email, NNTP newsgroup)

2:  Fix the "mark as read" bug we're discussing, thus:
    [ ] Mark as read automatically [__] seconds after viewing.
    [x] Mark as read automatically after leaving
        (leaving means closing the message window, 
         closing the preview pane, 
         or moving to the next message in the preview pane)

3:  Fix the "messages are =sometimes= marked as read anyway" bug.

(uhhh.. wait... that's three sir!)

Jose


    
    

    
  
Navigating back to the previous message can be easily done with the Back button - no need to have a pref to mark as read on a delay after just to be able to find the previous msg. The latest proposed fix allows everything the other (one line options), and I do think it's clearer. Plus we don't have to do the pref migration.

David: have you had a chance to look at the patch yet?

    
    

    
  
re: 144
> Navigating back to the previous message
> can be easily done with the Back button

Not in SeaMonkey.

Jose


    
    

    
  
> > Navigating back to the previous [...] with the Back button
> 
> Not in SeaMonkey.

It does work on trunk.


    
    

    
  
Comment on attachment 323277 [details] [diff] [review]
proposed fix, v2

thx, Magnus.

        Attachment #323277 -
        Flags: superreview?(bienvenu) → superreview+

    
    

    
  
Checking in mail/base/content/mailWindowOverlay.js;
/cvsroot/mozilla/mail/base/content/mailWindowOverlay.js,v  <--  mailWindowOverlay.js
new revision: 1.209; previous revision: 1.208
done
Checking in mail/components/preferences/advanced.js;
/cvsroot/mozilla/mail/components/preferences/advanced.js,v  <--  advanced.js
new revision: 1.19; previous revision: 1.18
done
Checking in mail/components/preferences/advanced.xul;
/cvsroot/mozilla/mail/components/preferences/advanced.xul,v  <--  advanced.xul
new revision: 1.27; previous revision: 1.26
done
Checking in mail/locales/en-US/chrome/messenger/preferences/advanced.dtd;
/cvsroot/mozilla/mail/locales/en-US/chrome/messenger/preferences/advanced.dtd,v  <--  advanced.dtd
new revision: 1.19; previous revision: 1.18
done
Checking in mailnews/mailnews.js;
/cvsroot/mozilla/mailnews/mailnews.js,v  <--  mailnews.js
new revision: 3.319; previous revision: 3.318
done
Checking in mailnews/base/prefs/resources/content/pref-viewing_messages.js;
/cvsroot/mozilla/mailnews/base/prefs/resources/content/pref-viewing_messages.js,v  <--  pref-viewing_messages.js
new revision: 1.2; previous revision: 1.1
done
Checking in mailnews/base/prefs/resources/content/pref-viewing_messages.xul;
/cvsroot/mozilla/mailnews/base/prefs/resources/content/pref-viewing_messages.xul,v  <--  pref-viewing_messages.xul
new revision: 1.55; previous revision: 1.54
done
Checking in mailnews/base/resources/content/mailWindowOverlay.js;
/cvsroot/mozilla/mailnews/base/resources/content/mailWindowOverlay.js,v  <--  mailWindowOverlay.js
new revision: 1.272; previous revision: 1.271
done
Checking in mailnews/imap/src/nsImapService.cpp;
/cvsroot/mozilla/mailnews/imap/src/nsImapService.cpp,v  <--  nsImapService.cpp
new revision: 1.340; previous revision: 1.339
done
Checking in suite/locales/en-US/chrome/mailnews/pref/pref-viewing_messages.dtd;
/cvsroot/mozilla/suite/locales/en-US/chrome/mailnews/pref/pref-viewing_messages.dtd,v  <--  pref-viewing_messages.dtd
new revision: 1.29; previous revision: 1.28
done

The problem with imap and isRead (from my comment 129 seems to have gone away too, yay!).

->FIXED

Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED

    
    

    
  
Dear All

I started using Thunderbird about 3 month ago, because that time I started to change to free programs. For the first sight it was OK for me, but there were some unusual and annoying things for me in it. When I started using free programs, I also decided to help them developing by submitting bug, feature requests. Till now I did not had a lot of time for submitting, but today I sent my first request, which was the problem described in this bug.

It is amazing for me that such a simple modification took 3 years to be built into the program. I think in case of free programs beside the stability, the user frendly behaviour would be the most important, otherwise people will not use them.

I hope this very slow fixation of a feature request or bug is not normal case in Thunderbird development, otherwise I am going to start looking for a better and faster developed program.

    
    

    
  
Comment on attachment 323277 [details] [diff] [review]
proposed fix, v2

Nits:

>+      <vbox>
>+        <hbox align="center" pack="start">
You don't need align="center" for only one item.
You don't need pack="start" as it's the default.

>+        <hbox class="indent">
>+          <radiogroup id="markAsReadAutoPreferences" orient="vertical"
>+                      preference="mailnews.mark_message_read.delay">
<radiogroup ... class="indent"> works just as well.

>+            <hbox align="center" pack="start">
You don't need the pack again, but you do at least need the align this time!

    
    

    
  
In what way is this bug "fixed"?  I am using Seamonkey 1.1.11 in Ubuntu 8.04 linux (I haven't upgraded the Win98 machine yet) and the bug is still there.  Messages are marked as read, at random, when they are opened in preview, and they are marked as read, consistently, when they are opened in their own window.

There is a checkbox in preferences that says:

[ ] wait [__] seconds before marking as read

which is as confusing as before (in fact, I think it's the same message as before).

So, where's the fix?  And if the fix is in "trunk", what is "trunk"?

Jose



    
    

    
  
(In reply to comment #151)
> In what way is this bug "fixed"?  I am using Seamonkey 1.1.11 in Ubuntu 8.04
> linux (I haven't upgraded the Win98 machine yet) and the bug is still there. 
> Messages are marked as read, at random, when they are opened in preview, and
> they are marked as read, consistently, when they are opened in their own
> window.
> 
> There is a checkbox in preferences that says:
> 
> [ ] wait [__] seconds before marking as read
> 
> which is as confusing as before (in fact, I think it's the same message as
> before).
> 
> So, where's the fix?  And if the fix is in "trunk", what is "trunk"?
> 
> Jose
> 

In this case "trunk" is TB 3.x and SM2.x

    
    

    
  
There isn't a patch or release for TB 2.0.x that solves this?
Specifically: the imap account marked as read issue. This is a very annoying bug, and, afaik, is related of the size of the message being displayed. See
https://bugzilla.mozilla.org/show_bug.cgi?id=410148

    
    

    
  

      
      
      
      

        Attached image
          
        Screenshot of settings on my PC (obsolete)
        — 
      

    


  
I have just installed Shredder A2 onto my Vista x64 machine. Creating a new profile, and connecting to my IMAP server via SSL with the "Automatically mark messages as read" setting unticked results in...

the messages being immediately marked as read on selection!!

Something about this bug still isn't right I think...

    
    

    
  
Problem exist on A2 just tested on WindowsXP SP3 as well. But if you mark you message manually back as unread it never mark it as read automatically.
Trunk seems unaffected by this regression
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/20080813031200 Shredder/3.0b1pre

    
    

    
  
Might be what I saw in comment 129, but I couldn't reproduce by the time I tested pre checkin. 

Chris: does http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/ work for you? If not, file a new bug, and cc me on it.

    
    

    
  
Added bug https://bugzilla.mozilla.org/show_bug.cgi?id=450740 because this feature still doesn't work for me in the latest nightly build.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        nits from comment 150 (obsolete)
        — 
          — Splinter Review
      

    


  
Fix nits from comment 150.

        Attachment #282704 -
        Attachment is obsolete: true

        Attachment #333726 -
        Attachment is obsolete: true

        Attachment #334023 -
        Flags: superreview?(neil)

    
    

    
  

      
      
      
      

        Attached patch
          
          
        nits from comment 150 (obsolete)
        — 
          — Splinter Review
      

    


  
Bah

        Attachment #334023 -
        Attachment is obsolete: true

        Attachment #334024 -
        Flags: superreview?(neil)

        Attachment #334023 -
        Flags: superreview?(neil)

    
    

    
  
Comment on attachment 334024 [details] [diff] [review]
nits from comment 150

>+            <radiogroup id="markAsReadAutoPreferences" orient="vertical" class="indent"
>+                        preference="mailnews.mark_message_read.delay">
>+              <radio id="mark_read_immediately" value="false"
>+                     label="&markAsReadNoDelay.label;"
>+                     accesskey="&markAsReadNoDelay.accesskey;"/>
>+              <hbox>
You forgot the align="center" here...

>+        <radiogroup id="markAsReadAutoPreferences" orient="vertical" class="indent"
>+                    preference="mailnews.mark_message_read.delay">
>+          <radio id="mark_read_immediately" value="false"
>+                  label="&markAsReadNoDelay.label;"
>+                  accesskey="&markAsReadNoDelay.accesskey;"/>
>+          <hbox align="center">
...although you managed to remember it here!

        Attachment #334024 -
        Flags: superreview?(neil) → superreview+

    
    

    
  
Have look into bug 450413, there are trivial issue with UI after disabling auto marking and go back to this option it looks like you can still enter digits into seconds box.

    
    

    
  


  
changeset:   166:360c6d9b7341
http://hg.mozilla.org/comm-central/index.cgi/rev/360c6d9b7341

        Attachment #334024 -
        Attachment is obsolete: true

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: