Closed Bug 73330 Opened 23 years ago Closed 15 years ago

too much space at top of bugmail

Categories

(Bugzilla :: Email Notifications, defect, P3)

2.13
defect

Tracking

()

RESOLVED FIXED
Bugzilla 3.4

People

(Reporter: jruderman, Assigned: mkanat)

References

Details

Attachments

(1 file, 5 obsolete files)

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.
Target Milestone: --- → Bugzilla 2.16
Priority: -- → P3
Mass moving to new product Bugzilla...
Assignee: tara → jake
Component: Bugzilla → Email
Product: Webtools → Bugzilla
Version: other → 2.13
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.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
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.
Assignee: jake → preed
*** Bug 198919 has been marked as a duplicate of this bug. ***
OS: Linux → All
Hardware: PC → All
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.
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
Attached patch fix based on 2.18rc2 (obsolete) — Splinter Review
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
Attachment #161816 - Flags: review?(kiko)
Attached patch fix based on tip (obsolete) — Splinter Review
Updated based on the CVS tip and cleaned up a couple of minor whitespace issues
in the code.

Todd
Attachment #161816 - Attachment is obsolete: true
Attachment #161827 - Flags: review?(kiko)
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.
Attachment #161816 - Flags: review?(kiko)
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. :-)
Assignee: preed → email-notifications
Target Milestone: Bugzilla 2.20 → ---
Attached patch v3 - updated due to bitrot (obsolete) — Splinter Review
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
Attachment #161827 - Attachment is obsolete: true
Attachment #176362 - Flags: review?
Attachment #161827 - Flags: review?(kiko)
Assignee: email-notifications → tjs
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 :-)
Attachment #176362 - Flags: review? → review-
QA Contact: mattyt-bugzilla → default-qa
Attached patch v4 (obsolete) — Splinter Review
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.
Assignee: tjs → mkanat
Attachment #176362 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #350938 - Flags: review?(bugzilla)
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.
Target Milestone: --- → Bugzilla 3.4
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.
Target Milestone: Bugzilla 3.4 → Bugzilla 3.2
Attachment #350938 - Flags: review?(bugzilla) → review?(wicked)
(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.
Attachment #350938 - Flags: review?(wicked) → review?(bugzilla)
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?
Attachment #350938 - Flags: review?(bugzilla) → review-
:( 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
Severity: minor → normal
Attached patch v5 (obsolete) — Splinter Review
Okay, this should fix it.
Attachment #350938 - Attachment is obsolete: true
Attachment #385273 - Flags: review?
Attachment #385273 - Flags: review? → review?(wicked)
Attachment #385273 - Flags: review?(wicked) → review?(LpSolit)
Attachment #385273 - Flags: review?(LpSolit) → review-
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.
Attached patch v6Splinter Review
Okay, here we go! Tested in every configuration, seems to work fine and handle the problem everywhere.
Attachment #385273 - Attachment is obsolete: true
Attachment #395126 - Flags: review?(LpSolit)
Comment on attachment 395126 [details] [diff] [review]
v6

Yes, works fine. r=LpSolit
Attachment #395126 - Flags: review?(LpSolit) → review+
3.2 is restricted to security bugs.
Flags: approval3.4+
Flags: approval+
Target Milestone: Bugzilla 3.2 → Bugzilla 3.4
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
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.