Return Receipt's prompt before allowing the mail to be read.

Bug #30201 reported by Darryl Clarke on 2006-02-01
20
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mozilla Thunderbird
Fix Released
Wishlist
thunderbird (Ubuntu)
Wishlist
Unassigned

Bug Description

In Dapper Current
$ apt-cache policy mozilla-thunderbird
mozilla-thunderbird:
  Installed: 1.5-0ubuntu3

Thunderbird will prompt a user to acknowledge an email as read when it contains a "Return-Receipt-To" header, before the message is visible in the preview.

Expected: This prompt should be displayed when leaving the message, and likely should not be displayed at all if the message is replied to.

Update: (by A.Pirard, as I think that Ubuntu users must find a practical solution to their problem in the bug description ...)

There's no longer a prompt in 3.1. Now a RR button while reading e-mail and cancel Receipt can be used if replying, that's fine to me. But there is yet another bug I met that prevents this Receipt to work : TB continues to request sending an already sent Receipt)

According to Mozilla, it was fixed in 3.1.1, latest available here: https://sourceforge.net/projects/ubuntuzilla/
I tested that the latter problem is solved in 3.1.4.

Hey Darin,
You do make a good pt. I tried 4.79 and it basically
does the same thing. The only slight difference between
current branch & 4.79
  -branch: you keep the previous mesg in the Mesg pane window
           and when you click on the new mesg, the prompt appears
           but it doesnt load in Mesg pane window
  -4.79: when new mesg arrives and you click on it, the header
         of the new mesg is loaded in mesg pane window (not the body)
         and you get the prompt.

I talked to David and he mentioned:
"- the only thing I can imagine is that putting up the RR dialog prompt is
preventing layout from finishing the laying out/display of the underlying
message, so it would be an event
processing problem (thos modal dialogs tend to prevent other things from
happening)"

how about making the RR dialog non-modal? or how about deferring it until the
msg has completely loaded?

*** Bug 166165 has been marked as a duplicate of this bug. ***

Bug 166165 Message confirmation is too invasive Comment 0:
I'm reading mail, I should be able to read a message and at the end decide
whether I want to confirm receipt of the message.

What actually happens: I get the message and have to decide to confirm before I
read the message.

It's true that in physical certified mail you have to sign on the dotted line
before you can read the message. However this is email, and it makes more sense
to allow the reader to decide to confirm receipt after reading instead of before.

I scan my mail quickly and then go back to things which are important (real
people do the same thing with real mail, although they tend to only look at the
envelope -- unfortunately the envelope for email isn't always helpful in
indicating importance).

My parents and relatives actually send me MDN'd messages, but while they do want
to know that I got the message, they're almost always more interested in knowing
that I actually *read* the message. Usually the message is an invitation or
indication about an event of some sort. If my computer has received the message
and i've marked it as read because i was skimming through my mail, but i didn't
actually read the message, then the notification is useless and misleading.

IMO a better UI would be chrome at the bottom of the message "The sender has
requested a receipt. <send receipt reply>" with a little receipt icon in the
envelop chrome which links to the bottom of the message.

*** Bug 178676 has been marked as a duplicate of this bug. ***

Regards
JG

*** Bug 190071 has been marked as a duplicate of this bug. ***

I'd like to have the possibility to manually send a return receipt after reading
the eMail as well.

It'd be great to have a "send receipt now" option in the context menu of
messages that requested a receipt but did not yet get any.

It'd be even greater to have an "always return receipt to people in my personal
addressbook in groups X, (...)" option or something in the Mail&Newsgroups
preferences - but that'd be another feature request, I suppose.

(i am assuming, as all people who comment this bug, that this bug refers to a situation where return receipt (RR) options are setted to "Ask me")

I think this could be a good way to handle this bug:
When you open/preview a message with return receipt, a msgBox pop ups:

    +-----------------------------------------------------+
    |"The sender of this message request a return receipt.|
    |If you want send it, use the button in headers bar. |
    | [ OK ] |
    +-----------------------------------------------------+

And a bar is added, similar to the junk-mail one.

    ---------------------------------------------------------------------------
    The sender of this message request a return receipt. [ Send ][ Never send ]
    ---------------------------------------------------------------------------
    [+] Subject: .............. From: .......... ##/##/#### ##:##
    ---------------------------------------------------------------------------
    (mail body)

This way you can read the mail entirely before send confirmation, or you can leave it and be warned by msgBox next time you read it, or you can click on "Never send" and skip further annoyance.

PS: A column "RRReq" (values = {Yes, No}) in mail list also helps, and it's easily visible than a special icon.

sergiodf wrote:
> think this could be a good way to handle this bug:
>When you open/preview a message with return receipt, a msgBox pop ups:
>
> +-----------------------------------------------------+
> |"The sender of this message request a return receipt.|
> |If you want send it, use the button in headers bar. |
> | [ OK ] |
> +-----------------------------------------------------+
>
>And a bar is added, similar to the junk-mail one.

I believe this is an overkill, althoug a nice one. :-)

The message header are already displayed, but no text, when the current dialog asks if receipt should be sent. The only thing that is needed, IMHO, is to display the full text message before launching the modal dialog box, so that we might have a clue on whatever is the mail about.

Fernando

Darryl Clarke (dclarke) wrote :

In Dapper Current
$ apt-cache policy mozilla-thunderbird
mozilla-thunderbird:
  Installed: 1.5-0ubuntu3

Thunderbird will prompt a user to acknowledge an email as read when it contains a "Return-Receipt-To" header, before the message is visible in the preview.

Expected: This prompt should be displayed when leaving the message, and likely should not be displayed at all if the message is replied to.

(In reply to comment #9)
> And a bar is added, similar to the junk-mail one.

This is exactly what I was imagining. Some web mail client do that and I find this very user friendly and you can take the decision to send or not a return receipt at any moment! Even a week later :)

I would simply display the feature un the "header/subject" bar; no popup at all (this would be one of the methods to act upon a return receipt: auto-send, ask-me, display in "header/subject" bar for manual processing).

But no more popup please ;)

But if you keep the actual 'ask me' feature, I agree that the message should be displayed first. This was my original intention when I searched for this bug/feature.

Best regards.

KarlGoetz (kgoetz) on 2006-06-03
Changed in mozilla-thunderbird:
status: Unconfirmed → Confirmed
In , Mcow (mcow) wrote :

*** Bug 256285 has been marked as a duplicate of this bug. ***

In , Mcow (mcow) wrote :

*** Bug 342195 has been marked as a duplicate of this bug. ***

I don't know whether my idea was simpler to implement, but here it is:

Besides Yes and No, there should be also and "not now" button, like in password manager in Firefox. So, when you click not now and revisit the message, the same dialog is offered again, until you decide yes or no.

I don't understand why this bug is not taken seriously. It has been around for age yet I'm sure a lot of people won't/don't use thunderbird in a professional context because of it.

I think the idea of Ivan is great, we should have an additional "not now" button. Maybe I'm wrong but I don't feel like it would be too difficult to implement.
Meanwhile the close button could be use in the dialog to work like a "not now" button instead of a "no button". I think it would be more natural since clicking on close doesn't explicitly mean to not return a receipt. (When people use the close button instead of yes or no it is because they don't know yet whether to send a receipt or not)

Meanwhile, I moved to Thunderbird. (In reply to comment #10)

The same bug has been filed on Thunderbird! Vote for it!

https://bugzilla.mozilla.org/show_bug.cgi?id=375556

Assigned to Mozilla Team

Changed in mozilla-thunderbird:
assignee: nobody → mozilla-bugs

TB should ask about sending Return Receipt after you mark message as read thats what is done for. Problem is in TB you can't mark messages read unread by yourself it done automatically after whatever seconds. I'll like to let some messages unread in outlook just because I have not read it property or don't want send read notification now.

André Pirard (a.pirard) wrote :

I wanted to write exactly what was already there, thanks :-)

But I wanted to add how good old Eudora does it.
Not only does it when the mail is closed, but it also offers to postpone acking.
And it's far from uncommon to want to ack mail later than the first time it's read.

One may think that postponing ack allows reading mail and ack it when opened later.
Many a lazy one would not reopen the message and Thunderbird would be accused to defeat the Return Receipt feature.

Please note while we are at it that the R-R-T spec defines other replies, most prominently when the message is trashed, but also, if I recall well, when it's moved.

Presently, the workaround is to make a copy of the message or to read IMAP mail from several locations.

Thanks for your time and for a, even nicer program.

André Pirard (a.pirard) wrote :

Oops, I forgot, about ...

> This prompt [...] likely should not be displayed at all if the message is replied to.

I'm not sure that Thunderbird should prevent doing what the standards request.
This would prevent sending the Receipt vs allowing the user to choose.
And think that it's possible to receive an e-mail requesting to send the Receipt to one address and the Reply to another or to simply exclude the Receipt-To address from a reply.
So, if that is done, make it "... if a reply is sent to the Return-Receipt-To address"

André Pirard (a.pirard) wrote :

I wonder if this report is just for the wishlist.
Bug #233990 describes a case where the Receipt message is never sent.
And, much like this bug, because things are done in the wrong order.

Alexander Sack (asac) wrote :

This isnt a bug imo. Receipts are there to notify when users open mail ... not depending on the content. If you think this is still valid, please open a new bug in bugzilla.mozilla.org and give us your bug id.

Changed in thunderbird:
assignee: mozilla-bugs → nobody
status: Confirmed → Incomplete

On 2008-11-26 13:28, Alexander Sack wrote :
> This isnt a bug imo. Receipts are there to notify when users open mail
> ... not depending on the content. If you think this is still valid,
> please open a new bug in bugzilla.mozilla.org and give us your bug id.
>
> ** Changed in: thunderbird (Ubuntu)
> Assignee: Mozilla Bugs (mozilla-bugs) => (unassigned)
> Status: Confirmed => Incomplete
1) Receipts are not there to notify when users open mail but that they
have (or at least could) read it, which OBVIOUSLY can be done only AFTER
it was displayed.
2) If allowing or disallowing the receipt is not done systematically,
but on user request, what else could it OBVIOUSLY depend on than ON THE
CONTENTS, contrary to what you say?
3) Have you ever compared with other MUAs? Are Eudora and other writers
stupid?
4) How can an OBVIOUS bug be incomplete?
5) Ubuntu requests its users to report bugs to Ubuntu and nothing else.
Please be organized to have that information circulating where it should
to get the problem solved and, most importantly, so that programmers can
ask reporters about more details they need.
6) Improving Ubuntu is not eliminating bugs from the database after 60
days but correcting them.
7) Alexander Sack, you should THINK before repeatedly destroying the
work that volunteers have done after a deep analysis of the problem.

This is too much. If this bug is not returned to the status Hilario J.
Montoliu set it, I will definitely stop cooperating with Ubuntu and I
will report why.
I have respect for volunteering, so I wish reporters' and triagers' work
wasn't destroyed.

On Wed, 26 Nov 2008 12:28:39 -0000
Alexander Sack <email address hidden> wrote:

> This isnt a bug imo. Receipts are there to notify when users open mail
> ... not depending on the content. If you think this is still valid,
> please open a new bug in bugzilla.mozilla.org and give us your bug id.

I do think this is still valid, but I'm no longer using Thunderbird, so
I'll leave it for someone else to forward if they so desire.
kk

>

--
Karl Goetz, (Kamping_Kaiser / VK5FOSS)
Debian user / gNewSense contributor
http://www.kgoetz.id.au
No, I won't join your social networking group

trimmed a bit

> 1) Receipts are not there to notify when users open mail but that
> they have (or at least could) read it
> 2) If allowing or disallowing the receipt is not done systematically,
> but on user request, what else could it OBVIOUSLY depend on than ON
> THE CONTENTS, contrary to what you say?
> 3) Have you ever compared with other MUAs?

I agree with these points.

> 4) How can an OBVIOUS bug be incomplete?
> 5) Ubuntu requests its users to report bugs to Ubuntu and nothing
> else. Please be organized to have that information circulating where
> it should to get the problem solved and, most importantly, so that
> programmers can ask reporters about more details they need.
> 6) Improving Ubuntu is not eliminating bugs from the database after
> 60 days but correcting them.

(while i agree) not relevant to moving this bug forward.

> 7) Alexander Sack, you should THINK before repeatedly destroying the
> work that volunteers have done after a deep analysis of the problem.
>
> This is too much. If this bug is not returned to the status Hilario
> J. Montoliu set it, I will definitely stop cooperating with Ubuntu
> and I will report why.
> I have respect for volunteering, so I wish reporters' and triagers'
> work wasn't destroyed.

This is just a rant, and not helpful in making someone else *want* to
fix a bug.
Please save such rants for your website :) (or your launchpad page, if
you feel so inclined).
kk

>

I, personally, do not follow this bug for personal convenience but for
the benefit of Ubuntu and Thunderbird.
I was a member of the RFC821 and 822 Internet Engineering Task Forces to
discuss e-mail extensions and that's the reason why I know and
understand not only what is in the e-mail RFCs but also why they were
written.
I can tell you that, contrary what is stated above "imo", Thunderbird
does not work "ito", according to their intentions.

Dimitrios Symeonidis (azimout) wrote :

In all this arguing, has anyone checked if this is still an issue in thunderbird 2.x ?
I tried checking, but for some reason it never asks me...

On 2009-10-23 00:04, Dimitrios Symeonidis wrote :
> In all this arguing, has anyone checked if this is still an issue in thunderbird 2.x ?
> I tried checking, but for some reason it never asks me..
Yes (2.0.12).

For those claiming that it's not a bug and/or needing more rationale...
You must know that everyone recommends not to acknowledge receipt for spam.
How can you be sure it's spam without looking at the mail body?

Once again, look at good old Eudora for how to do many things excellently.

Comment #15:
> I don't understand why this bug is not taken seriously. It has been around for
> age yet I'm sure a lot of people won't/don't use thunderbird in a professional
> context because of it.

Hear, hear! Filed in 2002, so I hardly think its status could be considered "NEW"....

The Return Receipt should not, however, be a Dialog Box. A simple button in the message pane/window should be sufficient, with maybe a warning dialog if you attempt to delete a message that requested a Return Receipt and one has not yet been sent.

In , Mvl (mvl) wrote :

Created attachment 420601
patch v1

This initial patch makes the prompt 'async'. It is now handled by the UI code, instead of inside the MDN code. The UI is now a notification bar, just like remote images etc. It will continue to show one mails with a mdn request until the user either agrees or denies to send.
I had to change the idl to make it possible to have some sort of callback. I opted to split the generation of the mdn message in two parts. First, initializing and prefs checking is done. The second part is the actual sending of the the reply. Part 1 may call part 2 directly, depending on the preferences.

In my opinion, this change makes receiving mdn request much less annoying. At least you can actually read the message before sending a note that you have read it...

In , Mvl (mvl) wrote :

Created attachment 420602
screenshot

Screenshot of the proposed UI

Comment on attachment 420601
patch v1

are the nsMsgDBFolder.cpp and OSXIntegration changes supposed to be in the diff?

In , Mvl (mvl) wrote :

(In reply to comment #22)
> (From update of attachment 420601 [details])
> are the nsMsgDBFolder.cpp and OSXIntegration changes supposed to be in the
> diff?

No, they are not. Just ignore them. Sorry about that.

The inline notification bar looks pretty good. I'm adding Andreas to take a look at it as well because I think we'll need an icon and I want to change the layout a bit.

I'd like to reword and re-layout the notification bar a little bit. There are two audiences I'd like to address a little better. One is the audience of users who know what a return receipt is and the others who don't understand what it means.

For the users who don't know what this is about I think it's best if we avoid using the word "receipt" at least in the buttons as I feel like it's not quite clear what is happening. However for the users who understand this process I think we still want to use the wording of "return receipt" in the notification bar itself.

So a message more like this:

*The sender would like confirmation that you've received this message*
/$SENDER has requested a return receipt for this message/

Which emphasizes "confirmation" in the main text but also talks explicitly about return receipts in the secondary text.

And with actions buttons like these: ( Ignore ) ( Send Confirmation )

I like the word "Send" in the positive action because I think we want to confirm the notion that you're 'sending' something back.

Still need a bit of work on the exact text and layout but I think that's a bit closer.

Bryan: I like your re-layout.
Perhaps you should use "The sender would like to confirm that you have received this message".

(In reply to comment #25)
> Bryan: I like your re-layout.
> Perhaps you should use "The sender would like to confirm that you have received
> this message".

That sounds much cleaner, thanks!

Given bug 539066, should this bug be moved to MailNews Core (or even Thunderbird)?

Some quick thoughts about this:
* I think it would be good if we could keep the height of this (and other messages) on one line only, in order to save some height from other more important parts, such as the message itself. This would mean we need to shorten things down though.
* "requested" sounds very authoritive, a bit like a order, even though there is no harm in ignoring to do that (or is it?). I wonder if "asked for" is better.

This doesn't address the target audiences as well as Bryans idea, but it might work, and is a bit shorter:
"John Doe would like a confirmation that you got this e-mail and have asked for a return receipt (Ignore) (Send confirmation)"

Not sure if it's possible to say "to know" instead of confirmation, as it's good to repeat it in both the text and the button, but it would be shorter.

In , Mvl (mvl) wrote :

Created attachment 424433
patch v2

Updated the patch: removed unrelated changes, removed left-over test code.
The wording hasn't changed yet, because no decision has been made.

Comment on attachment 420602
screenshot

in general this is excellent. i'll add myself to the patch for the final wording review

Comment on attachment 424433
patch v2

For now if we assume the label is "The sender would like to confirm that you have received
this message" with buttons ( Ignore ) and ( Send confirmation ) I can ui-r+ this.

Later if we have a better layout for notification bars we can rearrange the ui fairly simply. Thanks!

Comment on attachment 424433
patch v2

Thx very much for the patch - this will be so much nicer than what we have now.

I think this diff is incomplete - when I try it, I get

JavaScript error: chrome://messenger/content/messenger.xul, line 1: SendMDNRespo
nse is not defined

Perhaps you were overzealous in removing diffs that weren't part of the patch?

Reviewing what is there:

+ var askUser = mdnGenerator.process(MDN_DISPOSE_TYPE_DISPLAYED, msgWindow, msgFolder,
+ msgHdr.messageKey, mimeHdr, false);
+ if (askUser) {
+ gMessageNotificationBar.setMDNMsg(mdnGenerator, msgHdr);
+ }

no need for the braces in the if clause. Can you use let instead of var for askUser (or get rid of the var entirely, though I can see that it makes the code a bit more readable).

+ * @param folder The folder the message is is

should be "is in".

+ * @returns true if the user need to be asked for permission
+ * false in other cases (whether the message was send or denied)

I think that should be "user needs to be asked", and "whether the message was sent or denied".

+ * May only be called when |process| returned |true|. Behavious is

Behavior

+ {
+ if (!m_autoSend) {
+ *needToAskUser = PR_TRUE;
+ rv = NS_OK;
+ } else {
+ *needToAskUser = PR_FALSE;
+ rv = CreateMdnMsg();
+ UserAgreed();
+ }
+ }

should use non K&R braces to be consistent. This also looks like it's 4 spaces indented instead of 2.

This comment was copied from somewhere else? It should be fixed. Or the code and comment just removed.

+ // do some complex action, check whether the action's results were what are expected here
+ // this is just an example, so we assert that true == true

set flag for wanted-thunderbird3.1

ping mvl for a new patch...

In , Mvl (mvl) wrote :

Created attachment 433753
patch v3

Patch updated to review comments. I indeed removed a bit too much in the previous version.
One thing I didn't change is the 2 vs 4 spaces in the .cpp file. That file is a mix of both, and I used the style form the function that I changed.

Comment on attachment 433753
patch v3

thx very much, this works. r=me, with some nits:

+ * @param autoAction true if the request action led to sending the mdn
+ * reply was an automatic action, false if it was user initated

"initiated"
+ * Must be called when the user was asked for permission and declined to
+ * sending the mdn reply.

"declined to send"

+ * May only be called when |process| returned |true|. Behavious is
+ * unspecified in other cases.

"Behavior"

Comment on attachment 433753
patch v3

>- rv = GetStringFromName(NS_LITERAL_STRING("MsgMdnWishToSend").get(),
>- getter_Copies(wishToSend));
>- rv = GetStringFromName(NS_LITERAL_STRING("MsgMdnIgnoreRequest").get(), getter_Copies(ignoreRequest));
>- rv = GetStringFromName(NS_LITERAL_STRING("MsgMdnSendReceipt").get(), getter_Copies(sendReceipt));

These strings need removing from the mail version of msgmdn.properties. sr=Standard8 with these removed.

In theory the suite/ ones need removing as well, but I've commented about that on bug 539066.

In , Mvl (mvl) wrote :

Created attachment 437900
patch v4, ready for checkin

Checked in: http://hg.mozilla.org/comm-central/rev/77fe4fa534da

(Note: I forgot to put the ui-review on the check in comment).

papukaija (papukaija) wrote :

To maintain a respectful atmosphere, please follow the code of conduct - http://www.ubuntu.com/community/conduct/ . Bug reports are handled by humans, the majority of whom are volunteers, so please bear this in mind.

papukaija (papukaija) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. We are sorry that we do not always have the capacity to look at all reported bugs in a timely manner. There have been many changes in Ubuntu since that time you reported the bug and your problem may have been fixed with some of the updates. If you could test the current Ubuntu development version, this would help us a lot. If you can test it, and it is still an issue, we would appreciate if you could upload updated logs by running apport-collect 30201, and any other logs that are relevant for this particular issue. Please feel free to report any other bugs you may find.

papukaija (papukaija) wrote :

We'd like to figure out what's causing this bug for you, but we haven't heard back from you in a while. Could you please provide the requested information? Thanks!

tags: added: dapper

On 2010-09-15 10:21, papukaija wrote :
> We'd like to figure out what's causing this bug for you, but we haven't
> heard back from you in a while. Could you please provide the requested
> information? Thanks!
>
Who is "you"?
What do you mean with "what's causing this bug"? Thunderbird, of course.
What do you mean with "for you"? This bug affects everybody in the world.
What other requested information do you need?
This bug is perfectly obvious and anybody can test it extremely easily
with any TB version in no time.
Why is this bug "incomplete"?

Micah Gersten (micahg) wrote :

Thank you for reporting this bug. This has actually been fixed upstream in Thunderbird 3.1 which is in Maverick. I apologize for all the bug confusion. Please report any other issues you may find.

Changed in thunderbird:
milestone: none → 3.1
Changed in thunderbird (Ubuntu):
status: Incomplete → Fix Released
Changed in thunderbird:
importance: Unknown → Wishlist
status: Unknown → Fix Released

Much much better indeed, thanks to the authors of the patch.
Unfortunately, TB 3.1 no longer remembers whether the RR was sent.
It requests sending another one each time the e-mail is opened.

In general, for many good ideas about e-mail design, look at good old Eudora.
Eudora prompts for sending RR when closing the message with Send/Postpone/Ignore.

Much much better indeed, thanks for this news and to the authors of the
patch.
Unfortunately, TB 3.1 no longer remembers whether the RR was sent.
It requests sending another one each time the e-mail is opened.

In general, for many good ideas about e-mail design, look at good old
Eudora.
Eudora prompts for sending RR when closing the message with
Send/Postpone/Ignore.

(In reply to comment #40)
> Unfortunately, TB 3.1 no longer remembers whether the RR was sent.
> It requests sending another one each time the e-mail is opened.
Please fill separate bug on this, cuz I don't see any problem with that.

(In reply to comment #40)
> Much much better indeed, thanks to the authors of the patch.
> Unfortunately, TB 3.1 no longer remembers whether the RR was sent.
> It requests sending another one each time the e-mail is opened.

Make sure you are using version 3.1.1 or later - there was a bug in 3.1 final that caused return receipts to be forgotten.

André Pirard (a.pirard) on 2010-09-19
description: updated
description: updated
André Pirard (a.pirard) on 2010-09-19
description: updated

Please update the milestone to 3.1.1 (possibly adding the second Mozilla
bug)
There is a second Mozilla bug preventing this solution.
See https://bugzilla.mozilla.org/show_bug.cgi?id=151244#c42
See my Description update.

Micah Gersten (micahg) wrote :

Thank you for the update, had the other bug been unsolved, it would need to have been filed separately, but since it's solved we'll leave it at that. Maverick has Thunderbird 3.1.4 anyways, so there's no need for another bug. We can only track one upstream bug per upstream project. Please report any other issues you may find.

André Pirard (a.pirard) wrote :

Thanks for your quick reply.
> Please report any other issues you may find
I did: please update the milestone to 1.1.1 one way or another so that
it be not misleading.

The purpose of Launchpad should be not only that Ubuntu users help
Canonical to make good packaging choices and to praise the benefits of
future releases, but also that Canonical help their users with precise,
practical, search and howto instructions to fix the problems in their
running system. The bug Descriptions should be such. Thanks.
https://bugs.launchpad.net/bugs/30201

Micah Gersten (micahg) wrote :

 The milestone reflects the upstream bug that it's set for. The
current upstream bug was fixed for 3.1. Your description that you
updated can serve as that documentation.

On 09/19/2010 05:58 AM, André Pirard wrote:
> Thanks for your quick reply.
>> Please report any other issues you may find
> I did: please update the milestone to 1.1.1 one way or another so that
> it be not misleading.
>
> The purpose of Launchpad should be not only that Ubuntu users help
> Canonical to make good packaging choices and to praise the benefits of
> future releases, but also that Canonical help their users with precise,
> practical, search and howto instructions to fix the problems in their
> running system. The bug Descriptions should be such. Thanks.
> https://bugs.launchpad.net/bugs/30201
>

André Pirard (a.pirard) wrote :

151244 fix is wrong and unusable (endlessly requests already sent receipts)

André Pirard (a.pirard) wrote :

> The milestone reflects the upstream bug that it's set for. The
> current upstream bug was fixed for 3.1. Your description that you
> updated can serve as that documentation.
>
May I repeat that that "upstream bug fix" is not a fix of Bug 30201
because a fix that doesn't fix a problem is not a fix. I may be the
only one to have tried that "fix" and the only one to have seen that.
The problem is *not* fixed in 3.1 even for those who read only the titles.
The definite solution of Bug 30201 is
https://bugzilla.mozilla.org/show_bug.cgi?id=558543
Please add it to the existing list of 2 bugs and flag it as the
milestone one.
The description is not mine and if I had not worked on this there would
be no update and no warning of an unbearable 3.1. Please make my job
complete.

Micah Gersten (micahg) wrote :

Andre, as I said, that's a separate bug and since it's fixed, there's no point in worrying about it. Your updated description can serve as documentation.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.