Open Bug 524650 Opened 15 years ago Updated 2 years ago

Messages with Return-Receipt should be hidden in respective 123 snippets/previews.

Categories

(Thunderbird :: Message Reader UI, defect)

defect

Tracking

(Not tracked)

People

(Reporter: ovidiu.grigorescu, Unassigned)

References

(Blocks 1 open bug)

Details

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.5pre) Gecko/20091025 Lightning/1.0pre Shredder/3.0pre You can preview the message, as much as it is shown in the first lines in the *group by sort multimessage view or in the *search all messages gloda result list. Which is not the intended behavior. If directly click it will still hide the content and ask for receipt. May seam minor, but for institutional or corporate some may really wanna configure a more strict policy and this will give them a hard time. str: -group by sort, say date, -collapse all the groups -see the multimessage list in the msg pane *-get a msg with return receipt result: it is listed in the /msg pane with the preview/ or in the /search resuts/ expected: do not show cotent in that list, or even better throw a message like "this requested return blabla" instead of body lines
If I understand this correctly, it is really two bugs - one is Message Summary belongs in folders and message lists - one belongs in Search (It's not Message Reader UI, even though the Summary occupies the message preview space)
Summary: Return receipt eluded by preview in multimessage and search → Return receipt eluded by preview in multimessage Summary and search
Yes it is I think they should be 2-3-? bugs accordingly and block this one as a meta, as the solutions are to eventually eliminate all variants. and I'm also trying to test *vista search to see if that too eludes it (with it's preview pane that actually shows all msg) *I can also assume extensions have access to such msg content witch may be yet another separate bug, or not ? *Are there any other snippet or preview areas?
Yep, vista search eludes it too if you have the preview pane in the window. It shows all the written part of the message (in comparison to snippets) creating 3 blocking bugs on specific: -multimessage sumary -gloda search results snippets -vista search results preview FWIW, gmail web does not care about such receipts at all, in the very accounts that otherwise do prompt in TB. And vista mail app does the same with vista search. This may just be the value in it...
Summary: Return receipt eluded by preview in multimessage Summary and search → Return receipt eluded by preview in multimessage Summary, gloda Search and Vista search
Depends on: 524953
Depends on: 524954
Depends on: 524955
Summary: Return receipt eluded by preview in multimessage Summary, gloda Search and Vista search → Return receipt dialog displayed in multimessage Summary, gloda Search and Vista search
Sorry, summary: "dialog displayed" does not make sense to me. Message is displayed or previewed before dialog pops. * maybe: "Messages with rr should be hidden in respective 123 snippets/previews."
Oh, I see what you mean. I see why corporate policy might indeed desire such a thing, and it would indeed be consistent with current behavior of requiring acknowledgment of receipt before viewing the message body. I could imagine doing this via some sort of pref for corporate policy, but I actually think the current behavior is a bad default: I believe that our job as a user-agent is to empower the user, not the sender of the message, and my suspicion is that we'd do better by allowing the user to decide about a return receipt after viewing the entire message. I'm sure there's more nuance to this question, and it probably deserves its own bug. But I suspect it's hard to make a decision about this behavior until that bug has been sorted out.
Summary: Return receipt dialog displayed in multimessage Summary, gloda Search and Vista search → Messages with Return-Receipt should be hidden in respective 123 snippets/previews.
And not surprisingly, it has had one for quite a while: bug 221615 for Tb, bug 151244 for SM.
I think the very "mozilla" question would be: Is there a standard? http://www.trustedbird.org/tb/Main_Page see the features of this kind .. *the only issue is corporate custom mail apps (like above) that would wanna base this on tb and could require the option/possibility to handle this the way they want. So give them the option. [I know of a corporation that uses a custom app and is always having this kind of rr or confirmation for whatever reasons or policy. Otherwise, web gmail completely ignores rr, vista mail app shows (as tb) the vista search preview etc]
Actually, no, "is there a standard? no? let's have a pref!" would be the old Mozilla way. The new Mozilla way would be "what would a user want? let's do that, and leave what someone suspects some corporation might want to do, that a user wouldn't want to have done to them, to an extension that that corporation can write itself."
Keywords: regression
OS: Windows Vista → All
Hardware: x86 → All
Agreed, but ask someone that really cares for the implications. The case here is: http://www.trustedbird.org/tb/Notification_Viewer (example) the result may be Wontfix (hopefully), fine, I don't use this. [ps. I've also seen spam asking for rr, which can render you as real mail user to them, if not more ...]
WFM along with bug Bug 524653 Bug 524654 Bug 524655 and all related here since return receipt is not hiding the message, but appears as a notification under header (v3 for quite a while) this is not an issue. The problem was inconsistency, hiding the message while not hiding in other places. Before closing this would be interesting if there is any extension development trouble for those that are using such http://www.trustedbird.org/tb/Notification_Viewer and I think there was another one...
Blocks: 134040
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.