If someone adds comments to a bug but doesn't change any other fields, the bugmail I get has five blank lines between the bug URL and the "additional comments" line. That forces me to scroll down just to see who made the change. IMO, there should just be one blank line.

Mass moving to new product Bugzilla...

We are currently trying to wrap up Bugzilla 2.16. We are now close enough to release time that anything that wasn't already ranked at P1 isn't going to make the cut. Thus this is being retargetted at 2.18. If you strongly disagree with this retargetting, please comment, however, be aware that we only have about 2 weeks left to review and test anything at this point, and we intend to devote this time to the remaining bugs that were designated as release blockers.

Changing default owner of Email Notifications component to JayPee, a.k.a. J. Paul Reed (preed@sigkill.com). Jake will be offline for a few months.

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

Unloved bugs targetted for 2.18 but untouched since 9-15-2003 are being retargeted to 2.20 If you plan to act on one immediately, go ahead and pull it back to 2.18.

Attaching our solution based on 2.18rc2. This also changes slightly the look of the changes for dependency bugs (prepends a |) so that it stands out a little better. I figured I'd submit this for anyone else who wanted a quick fix. This will need to get reviewed, etc. if it's going to get checked in (which I can't do). Todd

Updated based on the CVS tip and cleaned up a couple of minor whitespace issues in the code. Todd

I just noticed that this patch undoes what bug 107580 created. Here and I thought it was an accident. So, I'll need a new patch to not undo bug 107580... Todd

Comment on attachment 161816 [details] [diff] [review] fix based on 2.18rc2 Removing r? from obsolete attachment.

As preed is no longer actively working on Bugzilla (from what I know), I somehow doubt that this bug will make it in for 2.20. :-) If I'm wrong, feel free to take it back and re-target it. :-)

Bitrot has set in. Here's a new patch that should apply cleanly to the tip. It includes the change to remove the extra space in $substs{"neworchanged"} now that bug 31314 has landed. No need to mess up the subject lines if real threading support is there. Todd

Comment on attachment 176362 [details] [diff] [review] v3 - updated due to bitrot Hi Todd, Sorry for the delay. This patch includes 3 unrelated changes. We try to fill separate bugs for each different change. In this case, splitting this patch in 3 parts would make the review process easier. There are too many unrelated changes in order to get to this fast enough. Regarding your first change: -> you're adding a new char; would this be enough to change the 76 limit to 75? Can multiple | chars be appended at the beginning of a line, in such a way that 75 would need to be lower than that? (I guess no but asking to be sure). Regarding the second change: -> this would change the sort-order in mail clients for those that sort by Subject. It would split "new" mails into 2 groups: at the beginning of the inbox, for those created before this modification goes in, and somewhere in the middle, for those created after this modification goes in. Not saying that it's something due to which review- should be granted, just saying this for consideration. Regarding your third change, I only have some questions right now: -> should the regexps be multilined (the /m option at the end of the line, next to the g option?) -> depending on the answer to the first question, is the second regexp enough in order to cover the \s* stuff in the 3rd one? The actual reason for r- is the 3-changes-in-one-patch thing. As you can see there are several issues to address (we want to make sure everything is ok before commiting) and having separate bugs for each issue would help focus discussion better. If you could open bugs and create patches for the first 2 changes and keep this bug for the 3rd change, it would be great. I'd be happy to review the patch for the 3rd change, together with the answers to those questions :-)

Wow, I am amazed that this has never been fixed. In any case, it was really simple, here's the patch. I tested this with the following configurations: * Adding an attachment during bug creation and requesting review, with a comment. * Changing a bug with just a comment * Changing a bug with just field changes * Changing a bug with both field changes and a comment And all of them look fine to me, now.

We could theoretically put this into 3.2, but it touches the email template, which a lot of people customize, and it's also one of the most-commonly-seen things in Bugzilla, and people tend to be touchy about things like that, so for now I'm targeting it to the trunk.

I want this for bmo, too.

Well, with at least that one voice, there are probably others who feel the same, particularly considering how old this bug is. How about we just fix it for 3.2.1, since it's a high gain for a low risk.

(In reply to comment #16) > Well, with at least that one voice, there are probably others who feel the > same YaY! You bet. Thanks for picking this up Max. I thought I had plugged for this a long time ago - a serious annoyance, especially now that thunderbird is losing some vertical space. Now looking for an extension to remove extra blank lines from message display for the bugmail archive. If anyone finds such an extension or function please post in the bug.

Comment on attachment 350938 [details] [diff] [review] v4 Looks nice for all three bug change cases (comment only, diffs and comment and diffs only) but seems to produce funky output for new bugs: ---! quote start !--- https://landfill.bugzilla.org/w32/show_bug.cgi?id=5540 Summary: New bug filed! Classification: Unclassified ... Estimated Hours: 42.0 Testing new bug filing. -- ---! quote end !--- Like you can see, first field indentation is wrong and comment touches the last field. >Index: template/en/default/email/newchangedmail.txt.tmpl >=================================================================== >-[%+ diffs %] >+[%+ FILTER trim %][% diffs %][% END %] Is there a reason for this complex FILTER syntax? Is this trimming even necessary or would chomping of newlines suffice?

:( missed v3.2.1 and 3.2.3. With compact header now gone from native thunderbird, plus extensions like bugmail taking screen height, getting rid of bugmail's blanks lines will be an even greater blessing. so sev=minor>normal

Okay, this should fix it.

Comment on attachment 385273 [details] [diff] [review] v5 This still doesn't fix the problem reported in comment 0. If there is a comment only (and no field change), your patch makes no difference. Note that parts of the bugmail look very close to each other when you change a field and comment. Not sure that's nicer. The bugmail looks very compact.

Can we take the patch as is and leave this open for a follow up patch? The major issue IMO is *not* when there is only a comment.

Okay, here we go! Tested in every configuration, seems to work fine and handle the problem everywhere.

Comment on attachment 395126 [details] [diff] [review] v6 Yes, works fine. r=LpSolit

3.2 is restricted to security bugs.

tip: Checking in Bugzilla/BugMail.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/BugMail.pm,v <-- BugMail.pm new revision: 1.126; previous revision: 1.125 done Checking in template/en/default/email/newchangedmail.txt.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/email/newchangedmail.txt.tmpl,v <-- newchangedmail.txt.tmpl new revision: 1.14; previous revision: 1.13 done 3.4: Checking in Bugzilla/BugMail.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/BugMail.pm,v <-- BugMail.pm new revision: 1.124.2.2; previous revision: 1.124.2.1 done Checking in template/en/default/email/newchangedmail.txt.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/email/newchangedmail.txt.tmpl,v <-- newchangedmail.txt.tmpl new revision: 1.12.2.2; previous revision: 1.12.2.1 done