It seems the prefs "mailnews.database.summary.dontPreserveOn{Copy,Move}" should be completed by adding "offlineMsgSize".

Otherwise some mess can be happen, as in: logbot.buc.me/seamonkey/20210704#c1815

When you move a mail from a local folder (ie. Archives) to imap Inbox, the size of the mail is increased (by 100 bytes in my case), probably because an additional empty "X-Mozilla-Keys:" header is added (why?). But the "offlineMsgSize" still has the old value. In some cases it confuses SM mailer.

Probably TB affected as well...

buc wonder if it is Bug 1430480

Nope, it is not attachment related.

buc you sure? see duplicate Bug 680004

Nope, there are no any attachments in my tests at all.

buc let my try anyway. Looking at the patch it seems to be a general fix not just for attachments.

The issue is not good reproducible. Fortunately I caught a reproducible case in my current environment and found the reason.

ok does not look related at second glance

Bummer that jorgk is no longer doing TB development.

When the mail is movied/copied to imap malbox, the "offlineMsgSize" header (if any) is copied into the correspond .msf file. Then when you read that folder, SM sees the broken "offlineMsgSize" and then uses it to compute file offsets etc., which leads to corrupted email data shown.

BTW, the "Repair" procedure (from folder properties) drops this parameter.

Well, yes -- searching for "mailnews.database.summary.dontPreserveOnMove", mailnews/imap/src/nsImapMailFolder.cpp reads the pref and than ADDS some more parameters, including "offlineMsgSize". But the similar code in mailnews/local/src/nsLocalMailFolder.cpp does not add anything. So "local-->imap" move is affected.

Seems was bug 486007 for imap, and bug 459680 for Local. But the header was added for imap only...

that doesnt surprise me, i have had the feeling for awhile TB development has gone downhill for awhile now

Probably at that time a mail did not increase during the movement from local to imap. But then "X-Mozilla-Keys" header was added (bug 691770, bug 426651), or something later...

BTW, useful python2 tool to parse .msf files (at least into xml): github.com/KevinGoodsell/mork-converter

Anyway, if we already remove "size" when copy/move (in defaults prefs), nothing seems to be spoiled if we remove "offlineMsgSize" as well.

Probably copying from a local folder to remote imap server it tooooooo rare operation... :)

...so no one has complained so far.

need some slppe. Will take a look tomorrow.

^sleep

yo

frg_Away: and how can I test it, run autoconf or manually change in configure?

frg_Away: (...if SM compiles with cargo 1.46)

Meeting starts in 29 minutes - wiki.mozilla.org/SeaMonkey/StatusMeetings/2021-07-11

Meeting starts here in 20 minutes - wiki.mozilla.org/SeaMonkey/StatusMeetings/2021-07-11

Hi frg, IanN, ewong

good day WaltS48

WaltS48 Hi

fantomas Just change the minimum required level. There is no other way around it.

hello everyone

tonymec hi

hi tonymec

tonymec: hi

Meeting starts here in 10 minutes - wiki.mozilla.org/SeaMonkey/StatusMeetings/2021-07-11

hi .*

hi there njsg

Meeting starts here in 2 minutes - wiki.mozilla.org/SeaMonkey/StatusMeetings/2021-07-11

Meeting time - wiki.mozilla.org/SeaMonkey/StatusMeetings/2021-07-11

hi rsx11m

hi IanN

Hi rsx11m

hi frg

Who's taking minutes?

me and probably late again :)

thanks frg

Nominees for Friends of the Fish Tank?

ewong for fixing up the update process.

+++

agreed

Action Items

Anything still need doing on Bug 1716547?

Nothing from me. Sorry for not fixing the website typo. I always got sidetracked or found something elase to do :(

Typo fix and wanted to add the logbot. Should we do it

and for Bug 1716544?

with the current self signed cert?

IanN should we remove freenode or demote it down?

frg: demote down I would say

Ok will see that I find some time.

IanN: for 1716547 help possibly, or should that go in a separate bug?

njsg if not website should go into separate bug. Can go into 544 as a separate part I think.

If website then 547

agreed

maybe a new bug for help and a meta-bug for the network change?

njsg meta is a bit much I think. Seperate bug is ok with me. We can link them the website bug.

yeah, meta would be overkill

just link the bugs

544 already has 547 in see also

Status of the SeaMonkey Infrastructure

no change from me but updates are working :) ewong is now working in the crash stats.

^on the

frg: not seen anything on the equivalent TB bug recently

mozilla seems to be dead set to do this soon. They will suffer more than us. I can live with it for some time and do private debugging if someone has a reproducable case.

no other changes to build infra as far as I am aware

Status of the SeaMonkey Source Tree

frg: IanN: bug 1720029

(for help irc link)

thanks njsg

All building I think. Prepiously only Mozilla had the habit of removing sources we use but now TB has joined them without giving notice. So far all manageable.

Release Train

2.53.8 unfortunately has a non wirking message archiving. Bug 1718839

Wonder if we should do a 2.53.8.1 IanN with the wip fix any severe new regressions in? Comment 5 6?

I didn't test yet. Did mostly reviews to get l10n changes in c-c.

frg: yeah, I have an idea of what to do to fix the issue I found

IanN show we do a 2.53.1 then?

2.53.8.1

frg: yes, we can do

Bug 515675 needs to go in too.

frg: is something broken in 2.53.8 that it fixeS?

Given that 2.53.9 has some extensive changes under the hood probabyl best to have a stable fallback with 2.53.8.1.

IanN removed the two other EnsureFolderIndex location. I am not sure what is broken now in 2.53.8 drag and drop but something is for sure.

suite\mailnews\content\messengerdnd.js contained them.

frg: ah okay

Extensions Tracking

IanN Alternative to putting the bug in might be to add the new EnsureFolderIndex(treeView, msgFolder) to mailWindowOverlay.js

If they are compatible

2.53.9 is still in flux I think. Noting from me for extensions.

Some outstanding reviews for cZ and also link open. Wonder if we should move them to 2.53.10 to let them bake a bit more.

put them in the beta but back out from 2.53.9 release?

unless they are too comprehensive

polyfill fixed some issues with using gitlab/github

rsx11m well based on 2.53.8 and 2.53.7 I doubt that the beata is really tested...

^beta

:-/

gitlab now needs web sustom elements. From what I see for emoticons. Really important usage to put this bloat in.

I amy trying to get stylo into 2.53 as a prerequsite but because of ever changing rust our older stuff does not compile with current rust.

^custom elements

got to love custom elements...

I am good a backporting but still needs more patches :)

Next wave is 4000 but most of them will probably not be needed so maybe 400 to 1000.

2.Next, Feature List, Planning and Roundtable

Just want to wait a little to see if regression crept into 2.53.9b1 pre

bau

ditto

Maybe we need to look at mdn links next. They want to stop displaying archived content July 14th.

Whatever this means. Might affect debugQA and help.

have to see what breaks

you mean developer.mozilla.org ?

and the site too, possibly

961 hits for developer.mozilla.org, 951 of which under src/releases

so release notes and download pages

probably depends how they define "archived content"

njsg: where are you searching?

IanN: hg grep on the site repository

interesting

> 1. Stop displaying all archived content on July 14, 2021

Whatever this means

Maybe they should just link to google com :)

in theory they only archives Firefox specific content

but again it depends what they mean by Firefox specific

I would wait too they removed it and then see what impact it has.

so, everything developer.mozilla.org/en-US/docs/Archive/Index_of_archived_content I'd assume

yes

We could put still relevant stuff in our website source.

some are not links, 730 and 720 if I grep for href=..., 61 unique addresses

but it is a matter of going through each unique link and working out if it has been archived and working out the best source going forward

If these are years old release notes or news I would not care.

that could be a link to another source or copying into our website

yeah, agreed

so recent news / releases notes, last 2 years? then other areas

yeah. Anything prominent first and then walking "down".

ShouldnÄt be a problem with our active community helping out :D

the alternative is to just clone the archive ;-)

loads of rubbish we don't want, but perhaps things that mention SeaMonkey might be useful to clone

okay, AOB?

bau again

Next meeting is in 2 weeks time

same bat time, same bat channel

I can post the agenda and invitation but have a conflict on the 25th

no problem in general, though - just to let you know

rsx11m I usually repost to alt.comp.software.seamonkey.

Forgot this time so late today.

thanks for your time everyone

have fun!

you too

bye

bye

frg_Away: thanks, but how do I change required cargo level ?

fantomas I am on 2.53.9. Check if python/mozboot/mozboot/util.py contains 1.47 and just set to 1.43

MINIMUM_RUST_VERSION = '1.47.0'

is that used for cargo version too?

...it is. Thanks.

Regarding logbot.buc.me/seamonkey/20210711#c1985 "offlineMsgSize" -- it seems a decade old issue, described in bug 426651 (and other related).

Mails in local folders have additional headers added, from "X-Mozilla-" namespace. When such a mail is copied/moved to a remote imap server, most of such headers are dropped, but "X-Mozilla-Keys" remains (bug 426651). But "offlineMsgSize" parameter does not count this header's bytes, and then imap server can receive wrong size.

Besides the 99 bytes of the header, also one additional newline is added to the end of the mail (ie. total 100).

It is very old (10 years) and seems rare issue. SM <= 2.49.5 affected as well. А bit of a pity that already at that time TB stopped taking proper care of the perfection of his code. :(

buc do you have a sample mail? I see the behaviour but my mails did not trigger the bad display of them.

well, SM 2.53.8 does compile with cargo-1.46.0

frg: I could set a testing account on my imap server right now.

The bug is reliably reproduced if it has already appeared. However, it is not clear at all how to create a certain simple test "from scratch". And it was mentioned in those bug reports. Therefore the easiest way is just to clone the environment in which the bug is reproduced.

frg: Well, I've create imap testing account. Ping me in private...

buc Thanks. Need to sleep. Have to run some errands early. Wil ping you Monday evening. I have an imap account with gmx just unable to find a good test message. Might not be able to fix it. This is a bit over my head.

see you tomorrow.