Bug 1329724 – Empty lines in email body disappear

Based on postings in de.comm.software.mozilla.mailnews (“[SM 2.46] Leerzeilen verschwinden beim Antworten”) I reported Bug 1329724 – Empty lines in email body disappear, but until now it seems nobody was able to reproduce the problem with the steps from bug report.

I did tests on mozilla.test with Server-Installations of unofficial (by FRG) en-US SeaMonkey 2.50a1 (NT 6.1; Win64; x64; rv:53.0) Gecko/20100101 Firefox/53.0 Build 20170108183322 (Default Classic Theme) on German WIN7 64bit (Re: Empty lines disappear, Rainer Bielefeld 06:08 +0100, Message-ID: <V8OdnYbIGKeq8enFnZ2dnUU7-cOdnZ2d@mozilla.org>, and the issue was still reproducible.

It would be great if someone else could reproduce the problem with the Steps To Reproduce from my report.

And, of course, it also would be great if you find other reliable ways how to provoke disappearing empty lines in replies; please submit additional separate Bugs if you are not sure that the problem you observe is exactly the same.

Regressions in latest SeaMonkey 2.48 Trunk Build

With today’s WINDOWS build I observed the Problems described in Bug 1300530 – “Edit As New” opens broken HTML Composition Window with missing contents, possibly add-on-related. and others. It would be great if some of you could help to narrow down the  roots of the problem.

Mac is back (new official Trunk builds)

After a while of waiting we now have new SeaMonkey Trunk  builds for MAC

Be careful! These builds are for testing purposes only. Keep backups of your data, some of the code you’re testing might not have been tested at all before and might cause unexpected problems. If you encounter any such problems, please report bugs for them.

Mozilla-Bugzilla temporarily not available

Internal Server Error

Internal Server Error

If you just found a SeaMonkey bug, you will have to be patient: Bugzilla is not (reliably) available from 17:00 UTC until 20:00 UTC (estimated).

My UNCONFIRMED Bug Reports

I still report new bugs I find with status UNCONFIRMED, even if (after careful investigation) I am pretty sure that the report is concerning a real bug and complete enough so that a developer can take on. Reason is that I believe in the two-man rule. Often a review by an other user adds information, may be concerning additionally affected Operating System or an aspect of the problem not yet mentioned or something else. But in the SeaMonkey project, due to very limit “human QA resources” and the lack of interest of most SeaMonkey users to contribute to the project, the bug review process  is horrible slow, even Bug reports what can be reproduced easily do not find a user who is willing to do a test whether he can reproduce the problem.

SeaMonkey needs you

So in future I myself will change bug status to NEW after 2 weeks (or so) of waiting if I think that all requirements for starting bug fixing process are fulfilled and nobody confirmed the bug. But, of course, it would be great if YOUR help would make superfluous this proceeding with my own “confirmation”. Be courageous and grasp the nettle of confirming some [easyconfirm] bugs.

Latest Developer builds

Corrected contents from unmaintained pages from seamonkey-project.org (2016-06-27)

Be careful! These builds are for testing purposes only. Keep backups of your data if you do so, as some of the code you’re testing might not have been tested at all before and might cause unexpected problems. If you encounter any such problems, please report bugs for them.

QA: New Whiteboard-Tag “[easyconfirm]”

Some time ago I introduced the Bugzilla-Whiteboard-Tag “[easyconfirm]” for the SeaMonkey-Project. This tag is for UNCONFIRMED  SeaMonkey-Bugs  which can be reproduced and confirmed easily even by beginners.So these bugs are suitable for first steps in our Bug-Tracking-System.

It would be great if SeaMonkey-users, which have not been working actively in the project until now, would use the opportunity to become familiar with SeaMonkey QA. A very good collection of big-triage – how-tos you can find here. Also the Bug Writing Guidelines contain useful hints. It is not necessary that you learn all that stuff by heart before you start, simply scan through and then start with “learning by doing”.

I hope to meet you soon in Bugzilla, click the [easyconfirm]-link above and try to reproduce and confirm your first bug.

New Style at AMO

So an older version of the style looked during my tests.

As  announced we now have a new Style on AMO. The contrast in the upper blue area now is some better than during my test, and the footer does no longer have blue background with very bad contrast. Real progress or only new to have something new   😉

—  what is your opinion?

QA-Statistics for old SeaMonkey-bugs

In the latest Status Meeting Frank-Rainer Grahl thought about old (UNCONFIRMED?) SeaMonkey bugs in Bugzilla and whether we should do a mass change to Resolution “Expired”. I also would like to get rid of those unclear legacy Bugs, but my concern is that we also might close many reports with real bugs if we do that mass close without individual investigation of every report. Because of this in 2015 I started a systematic review of UNCONFIRMED bugs from a list with 476 of them.

Here a small statistics considering a sample of 156 bugs from that list with changed Status / Resolution:

Status / Resolution	Number of bug reports	Percent of total
NEW	20	12,82%
DUPLICATE	12	7,69%
FIXED	1	0,64%
INCOMPLETE	69	44,23%
INVALID	10	6,41%
WORKSFORME	38	24,36%
WONTFIX	6	3,85%
Total	156	100,00%

So my estimation “25% real bugs” was not very precise.

Volunteers helping with this review appreciated!

AMO-Browsing-Add-On eases conversion and installation of FF and TB Add-Ons

Since 2014 we have had the Firefox & Thunderbird Addon-Converter for SeaMonkey. This great tool (already mentioned in the official project blog) converts add-ons written for Thunderbird and Firefox, so that they can be used with SeaMonkey, either.

Now we have an additional tool of the same author  (Lemon Juice) available for public download from sourceforge.net.