Mantis - ISSUES

0000260: Spelling checker does not work on 2.69.0.3760 beyong the first line of the message

Just that.

Confirmed by another member of the Gemini mailing list.

I am on Mac 10.7.3 and it was like this on 10.7.2.

0000258: Group view horizontal scroll unexpectedly reset

MP V2.68.3.3620 4.7.3 XPPro

I opened a viewer for a group containing what were probably all spam emails. The display was a "no grouping" not-threaded one. I'd selected but not opened the first message in the viewer and was about to click the delete button when I thought I'd check the value of one of the fields shown in a column currently off-screen to the right.

I scrolled the view sideways to make the column visible then clicked the "X" delete toolbar button. The view scrolled itself back to the left to show the
original set of columns. I'd not seen this before!

Twice more I scrolled right, deleted a row and had the sideways scroll reset itself.

I then started the Windows Media Encoder app I sometimes use for making window activity videos. I closed and re-opened the group that had showed this behaviour, started the screen capture and repeated what I'd done. Damnit!
This time the screen behaved properly.

Obviously I'll try to repeat the behaviour, (needlessly) scrolling views sideways prior to deleting something and see if I can provoke another series of resets. If I can, I see what happens NOT closing & reopening the group before starting the screen capture tool.

0000248: Filtering is broken

MP V2.68.3.3620 4.7.3 XPPro

As I described on the mail list, I'm finding messages in the wrong places, suggesting filtering is not working properly. Having turned logging on for some filters, I have to say I cannot see what's going on.

The attached zip file contains:

- filter failures.txt
- notes following the progress of one incoming message
with comments on sections of logs

- Filters my filter definitions

- filters - a misfiled message.jpg
- shows some headers in the sample message

- filters - display of definition of ebay filters.jpg
- shows definition of relevant filters

0000256: Inconsistent sub-thread display ordering

MP V2.68.3.3620 4.7.3 XPPro

(I noticed this while trying to document the precise behaviour I then described only in words in bug 247, when I copied a 'standard' set of threads to an empty group & then tried to show what happened to them with various actions performed in theory against all, or a repeatable subset, of them. I got so confused that I stopped trying to do that.)

Just now I was about to try to document another issue, when the inconsistent ordering described below occurred, getting in the way of the next problem I want to report.

Here I took a test set of 10 related news posts and copied them to a test folder. I expanded them into a threaded view and then edited each in turn working down through the list of items, altering their "from" header to include sequence numbers 01, 02, 03 .. 10. I took a screenshot of the expanded view: p01.jpg

I then copied this set of 10 edited messages to another empty folder, expanded them, and noticed that (a) all the (displayed) subject lines had lost the original "Re:" parts, and (b) the display order was not the same. See p02.jpg

I then reopened the original folder (ie the one in which I'd edited the posts), expanded the display and now saw a third layout: p03.jpg

Both folders are defined with:

Group: into threads
Sort: Subject 1,ascending

I accept that the structures shown in the three screenshots are equivalent, but don't completely understand why the 3 variants are displayed.

I think this is possibly at least in part a side effect of something that's annoyed me for ages. I have to say that my expectations are set because of the way that such displays worked in Pluto, but also that was how I expected them to be having used other (eg IBM mainframe support mail lists) threaded
displays in the past.

In a group where messages are threaded, I'd always expect the expanded thread display of a particular thread to be the same, no matter what other sort
parameters were defined for a particular view. That's because the thread structure is (I thought) unambiguously described by the references (etc)
headers inside the displayed items.

That being so I'd expect the "Sort by" part of the group definition only to affect the order in which multiple threads are displayed. (Certainly in Pluto
this was the case; if eg a view was sorted on Date Ascending then the earliest date value occurring in any of the posts in a specific thread dictated where
that thread would appear in the list of threads; if by Date Descending then the latest date in the thread was what mattered, and so on. Thus an ancient thread
to which someone suddenly posted a new reply could pop up to the top of the list of threads if they were sorted in Date Descending order.)

Since I have these experimental groups sorted on their "Subject" values, and as these (apart from elision of "Re:") are constant, I'd expect Sort to be irrelevant.

I have the impression though, in day-to-day use of MP, that threads are usually displayed so that sub-threads containing unread items are shown higher up in the
tree display. I can't stand that!

Nevertheless I wonder if the extra logic required to do this "most recent unread items are higher" is also causing changes in the layouts when no items are unread? Perhaps once a thread is all unread, next time the parent group & that thread is opened, another sort occurs, but because nothing has changed that
affects the sort order, behaviour of the sort is 'undefined'? - ie the sort of thing that actually requires one to have a final subsort by some hidden but invariant key value (eg msg number in the group)?

I suppose this bug is notifying you of what seems to be unreasonable behaviour of the test data, (which may or may not be a bug, depending on what's meant to be happening), plus a request that you consider adding a new type of thread display behaviour. (Inevitably, some people would hate the 'Pluto-like' way, so I guess it would have to be an option.)

0000250: Accounts shown in send/receive dropdown list in odd orders

MP V2.68.3.3620 4.7.3 XPPro

Although most of my account fetches/sends happen on a timed basis, I've long only sent emails when I choose. I've become used to clicking the dropdown arrow to the right of the send/receive toolbar icon, then clicking the line
for my mail-send account. It always used to be in the same place in the list. But now the accounts never seem to be listed in the same order. For example the enclosed three screenshots (I have a feeling you might not believe me without seeing them) show:

20120116 0027
wingsandbeaks - all pop3 fetch A3
virgin.net - all pop3 fetch A4
blueyonder - all pop3 fetch A7
C:\Documents and... text file A17
VRPC file text file A8
Freie Universitat (NIN) nntp A1
Private News - OpenWatcom nntp A14
AAISP mail send SSL smtp send A16

20120116 1816
blueyonder - all pop3 fetch A7
wingsandbeaks - all pop3 fetch A3
virgin.net - all pop3 fetch A4
AAISP mail send SSL smtp send A16
C:\Documents and... text file A17
VRPC file text file A8
Freie Universitat (NIN) nntp A1
Private News - OpenWatcom nntp A14

20120118 1925
wingsandbeaks - all pop3 fetch A3
virgin.net - all pop3 fetch A4
blueyonder - all pop3 fetch A7
AAISP mail send SSL smtp send A16
C:\Documents and... text file A17
VRPC file text file A8
Freie Universitat (NIN) nntp A1
Private News - OpenWatcom nntp A14

0000251: Sortable list in filter manager is unhelpful

MP V2.68.3.3620 4.7.3 XPPro

The list of filters as displayed in the filter manager now seems to be sortable. I think this is likely to confuse people. The screenshot in the manual shows no up/down arrow for sorting the display and the manual text specifically says:

"Filters are applied to messages in a specified order which the filter
manager reflects; filters displayed at the top are applied before
filters which appear lower down."

It seems to me that if the ability to reverse the display order is retained, then the help text needs to be altered to clarify which filters take priority. You could also achieve that by placing a dummy line at the start and end of the display saying something like

"highest priority filters"
... ...
... ...
... ...
"lowest priority filters"

or

"filters at this end of the list are considered first"
... ...
... ...
... ...
"filters at this end of the list are considered last"

or introduce another column containing a sequence number, and say explicitly that those with highest/lowest sequence number are considered first. Personally I think it would be simpler to remove the sort option.

If you were going to add more columns, then indicators for the state of various filter options would be much more useful, namely those for:

- allow other filters to process matched messages
- whether logging is on
- allow this filter to process locked messages

0000259: Extra columns in filter manager

If you were going to add more columns, then indicators for the state of various filter options would be much more useful, namely those for:

- allow other filters to process matched messages
- whether logging is on
- allow this filter to process locked messages

0000257: Auto-selection of next item rarely works when deleting items one by one in a threaded display

MP V2.68.3.3620 4.7.3 XPPro

In the scenario I try to describe below, it used to be possible just to select the top item in set of n messages, then click the "X" (delete) icon n times and have the whole set vanish one by one. It now takes lots of manual re-selects.

Possibly related to bug 247?

Attached file has notes on what I did and a series of screenshots.

0000255: Group viewer's background is not drawn when frame is plotted

MP V2.68.3.3620 4.7.3 XPPro

I use 'separate windows' mode.

In the all-groups viewer when I double click a group the frame (only) of the new window gets drawn & there's a definite delay before anything is put in it (ie a blank background). Of course if the group is big there's then a second delay while (I presume) MP reads the index file and decides what to plot. I'm perfectly used to the second of these, but the first is new behaviour.

Even for a small group - eg one with only a few hundred messages in it, the first delay is 2-3 seconds - long enough for me to set up a timed screen capture and catch it first time!

The screen shot was taken about 2 seconds after I double-clicked on the

"COMP SF SourceForge - ooREXX (bugs,patches etc)"

group's description. You can clearly see the new window's title bar, and its frame outlined in white, and the as-yet unplotted background.

Even on a tiny group, eg with only 17 messages, this effect is noticeable.

0000184: MP 2.63.2 usability problems with black backgrounds

MP 2.63.2.3192 Qt 4.6.2 Win XP Pro

Having finally upgraded from Gemini, where I used black backgrounds in all windows, I've found that when black is set as the background colour in MP various things don't work very well.

In the all-groups and specific group viewers none of the 'tree-structure' lines showing the nested structure of the folders or threading of messages are visible. The "+" and "-" signs denoting expandable or collapsable portions of the tree are not visible. All I see is a white-sided empty box where the icon should be.

I've temporarily set dark blue and dark green backround colours in these
displays, but they clash horribly with the colours I've long used (red and
yellow) to display read (yup, a pun on 'red') and unread messages, or in
the groups view, groups without/with new messages.

I've a similar problem in the new message write window now - I cannot see
the caret on the black background. In Gemini I think I had either a white
caret or one the same colour as the text foreground colour.

Same issue when editing an incoming message after Ctrl-T.

As far as I can tell carets are displayed in alternating black and
background colours, which when both are black, is not great.

Also when (with revised colours) the caret is marginally visible, it's still a very fine line. Is there any way to get a thicker line and/or a block caret?

0000254: News posts show equal date received & date sent values

MP V2.68.3.3620 4.7.3 XPPro

In newsgroup group viewers the 'Date received' value is always the same as the 'Date sent' one. Both seem to have the value specified in a post's "Date:" header.

Posts which have an "NNTP-Posting-Date:" header seem to have that value ignored.

(I have no idea if this behaviour has changed.)

It seems to me that the value in "Date:" is the one set by the author's news client (probably the time they started writing their post). I presume that,
if present, "NNTP-Posting-Date" gives us the time when the post left the author's computer & reached an NNTP server.

If so it's somewhat analagous to the 'Date received' for an email which I presume is extracted from the most recent 'Received:' header inserted into a mail by an SMTP server (usually a user's ISP, unless the user runs their own SMTP server).

I'd like to suggest that the "NNTP-Posting-Date:" value should show up in "Date received", at least if it is known. If it's not known, then arguably MP
shouldn't be displaying a 'Date Received' value.

(For both emails and news posts I'm often more interested in when an item arrived on my machine, hence the request - in bug 249 - for an AddStamp feature.)

0000252: Folders, mail-list groups & news groups are not restricted to their own group sub hierarchies

MP V2.68.3.3620 4.7.3 XPPro

I found accidentally that I could now drag the group that represents (say) a newsgroup so it appears as a child of a mail-list.

It seems to me that if this facility remains it doesn't make sense to have the "Local folders", "Mailing lists" and "Newsgroups" nodes in the all-groups display.

Some time ago I asked (bug 125) for a way to lock the tree hierarchy as I found I tended to drag groups by accident, and then lose them.

Possibly it would be useful to have an option that either enforces classification of group subtypes (so eg all mail lists must be under
the "Mailing lists" node etc) or allows users to have a totally freeform layout. Either way I do still think a lock would help.

0000253: Message window title doesn't support peculiar characters

MP V2.68.3.3620 4.7.3 XPPro

I noticed in passing that some (crazy) messages which had odd odd characters in their subjects:

Subject: =?UTF-8?B?UmU6IFdpbGwgVGhlIEVhcnRoIEVuZ CBiZSBpbiAyMDEyP+KdpOKdpOKdpOKdpOKdpOKdpA==?=
=?UTF-8?B?4p2k4p2k?=

(I broke one of those lines up)

displayed these ok in the group viewer eg:

"Will The Earth End be in 2012xxxxxxxxxxx"

where the characters I've marked there as 'x's were shown as hearts. In the message view window they also showed as hearts. But in the view window's
window title the heart characters were displayed as hollow squares. This doesn't matter to me but might indicate a problem for users who need to see text in foreign alphabets.

Attached file contains two screenshots:

20120108 hearts-1.jpg group viewer
20120108 hearts-2.jpg message viewer

0000234: Loss of edited data when attachment detached from a message's contents-edit view

MP V2.66.6.3353 4.6.3 XPPro

This has happened to me a couple of times in the last few weeks. I've not tried to reproduce it.

This time I was looking at an email which had a Word attachment and a plain text part. I'd opened the Word doc and - as often happens - seen the salient info was very short. I'd pressed Ctrl-T in MP to edit the plain text directly, and had inserted a few lines summarising what the word doc contained.

I then closed the Word doc (in Word, I mean), selected the icon for its attachment to the mail in MP and chose to 'Remove' it. MP then redrew the display in ordinary non-edit mode, with the attachment removed. However the plain text part of the mail reverted to its original contents.

I guess either one shouldn't be able to detach attachments while in edit mode, or perhaps at least while there's an unsaved change pending? Or maybe detaching something shouldn't take one out of edit mode....

In this case I found the detached Word doc in %TEMP% and opened it again, re-summarised it and edited & saved the change I wanted in the plain text part.

It's ironic that I needed the Word doc again, having chosen to dispose of it; it might have been nice if MP had saved the abandoned edit somewhere as well, perhaps in Drafts?

0000070: Ctrl-T allows edit of message text, but changes can be lost

Gemini 2.28m Qt 3.3.7 Win XP Pro

On the occasions when I have done Ctrl-T to get at a whole message, and made
some changes, I've been caught out when closing the window with the "x" icon
(rather than File-Save and then File-Exit), or double-click on the write
window's top-lefthand icon. Surely all these situations should check that
the text has been edited and if so offer to save it?

0000249: Filtering 'AddHeader' action does not work

MP V2.68.3.3620 4.7.3 XPPro

As part of my investigation of filter processing for bug 248 I added 'AddHeader' actions to a bunch of filter definitions. My hope was that I'd then
be able to view the headers of a filtered message and see which filters had processed that message.

This did not work; I've seen no instances of my new header in any message. I've also not seen any error message (ie in a log) suggesting an
actioning problem.

A typical filter definition looks like:

filter 296
name eBay - bids & messages
expiry Never
interval
age 0
lastused 1326915097
created 1282509108
ordering 142
flags 5
schedule
opengroups
criteria And Envelope-To >< jn.eco.bay.89@wingsandbeaks.org.uk
action MoveTo 444
action AddHeader X-JN-FilterTrace: FID=00000296 FNM=eBay - bids & messages
endfilter

0000203: MP 2.63.2 (Windows) installer errors - mailto does not work

MP 2.63.2.3192 Qt 4.6.2 Win XP Pro

Prior to installing MP I was using Gemini 229i. I uninstalled it before installing MP. Gemini's executable code etc had been in:

C:\Program Files\~I-folder\Intellegit\Gemini229i

and MP got installed into:

C:\Program Files\~I-folder\Intellegit\MessengerPro263-2-3192

After the MP install, C:\Program Files\~I-folder\Intellegit only contains one thing, the MessengerPro263-2-3192 subdirectory, that is there's no remnants of Gemini left there (though I can't remember for certain whether an empty Gemini229i directory was left - if so I deleted it manually).

During the MP install I do not recall being asked if I wanted MP to be my default mail/news client, nor do I recall if I was asked that the first time I ran MP. I think not but I'm not certain. Anyway, Control Panel -> Internet Options -> Programs does now show MP as the chosen program for both Email and News.

However, soon afer installing MP, I noticed, apart from the "label" mentions of "Gemini" in the registry, which aren't a problem, that some keys still pointed at the old "Gemini229i" program directory, which no longer exists:

HKEY_CLASSES_ROOT\mailto\DefaultIcon
(default) REG_SZ "C:\Program Files\~I-folder\Intellegit\Gemini229i\gemini.exe"

HKEY_CLASSES_ROOT\mailto\shell\open\command
(default) REG_SZ "C:\Program Files\~I-folder\Intellegit\Gemini229i\gemini.exe" -url "%1"

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\mailto\DefaultIcon
(default) REG_SZ "C:\Program Files\~I-folder\Intellegit\Gemini229i\gemini.exe"

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\mailto\shell\open\command
(default) REG_SZ "C:\Program Files\~I-folder\Intellegit\Gemini229i\gemini.exe" -url "%1"

Today I finally got around to testing the implications of that. As I rather expected, clicking on a mailto link in a browser page (for example the one for webmaster at the foot of these bugtracker pages) has no effect.

The corresponding set of nntp keys, showing just the HKEY_CLASSES_ROOT pair, now contain what might be XP defaults:

HKEY_CLASSES_ROOT\nntp\DefaultIcon
(default) REG_SZ C:\Program Files\Outlook Express\msimn.exe, -3

HKEY_CLASSES_ROOT\nntp\shell\open\command
(default) REG_SZ "C:\Program Files\Outlook Express\msimn.exe" /outnews /newsurl:%1

It seems to me that there's a possibility that the Gemini uninstaller (and perhaps also the MP one) didn't/aren't removing entries that they should have removed.

But more to the point, it looks as if the MP installer is either not installing mailto/nntp stuff at all, or only doing so if there are no existing values.

I think I would have expected to have been asked if the MP I was installing should be the default mailto/nntp handler and if I'd answered yes, that the whole lot of keys would have been updated. As I expect to install successive versions of MP in different locations in C:\Program Files\ it's always going to be necessary for the installer to point the keys at the most recent installed location, so it's no good to only write keys if none already exist.

I can fix my system manually with no trouble at all, but I would imagine not everyone would want to.

0000224: In All Groups list, empty group coloured as non-empty

MP 2.66.0.3327 Qt 4.6.3 Win XP Pro

This is an intermittent problem which I'm usually most aware of when, in a group display, I delete or mark as read all items, then close the group display.
I then see the line in the All Groups display which represents that group still coloured yellow (which is what on my system a group with contents is shown as).

I can easily recreate it, unless I'm running the Win Media Encoder utility for screen capture. Interesting when that utility is running I'm unable to double- click a group icon in the MP All Groups list and have to use right-click on the group and Open Group to open it - and when I do that the problem never shows up when I return to the All Groups display.

So I began to wonder if this had something to do with 'selection' status... because there's a similar issue which I can demo with the screen capture utility running!

If I click on a line which represents a group then click it again, it turns yellow, as if to show that it has been selected, or individual words in the Group's name have been selected. The latter is itself a problem in that I
have long found that double-clicking anywhere on a group's name rarely works as a way to open the group - more usually one ends up with only a word or two in the name being highlighted. So I do try to double-click the group's icon normally. (I wonder if, if you translated spaces in group titles to hard spaces before displaying them, the titles would then act like one long word?)

I think whatever it is that allows individual words in a group's title to be selected, is also what marks the whole line selected, and that state is sometimes set when I exit from a group's display. Perhaps it shouldn't be possible to 'select' a group's name?

0000194: MP 2.63.2 message source display is very slow

MP 2.63.2.3192 Qt 4.6.2 Win XP Pro

When I press Ctrl-T when in a message viewer, to get the display to change to show the entire raw content of the message, there's a significant pause before the display opens.

For example, a 6 second delay for a mail which has a small HTML attachment and a small word document, but the whole mail is only 46K. Or, for a 360 KB mail (with tiny plain text, about 20 lines of HTML, and the rest a base64-encoded PDF)... 68 seconds. Or even for a small entirely plain text mail, initial display is normally less than a second; pressing Ctrl-T it takes about 3 secs to prepare the next display... but there's only 24 lines of header at the start that's extra to what the first display showed.

I've noticed that opening a group is at least 10 times faster than it was in Gemini 2.29 (which is fantastic; I had some folders with several thousand mails in them that I hardly every opened before because it would take 20-30 seconds to do it, and now it's 2-3). (I just tried a folder with 6205 messages - now it opens in 3 seconds; its Index file is 485KB.) And I've also noticed that the delay in opening for simple display even a large single email (eg one that's > 1 MB) is also nearly instant... so it's hard to see why the source display takes so long.

In a normal message viewer, is View -> Message Source (Alt-Shift-H) the same thing as Message -> Edit Message (Ctrl-T)? It seems to be...

0000247: One can no longer select all contents of multiple unexpanded threads

MP V2.68.3.3620 4.7.3 XPPro

So far as I can see if one wants to select the contents of a /single/ thread one has to expand the thread then select from the first to last message in it. This is what 2.66.6 and earlier versions did as well. I'm used to that.

However with 2.66.6 if I wanted to select the contents of multiple threads, all at once, normally I'd select the 'head' message of one thread at some point in the display then shift-click on (say) a solitary message(*) somewhat further down the display. Then all the messages in the threads from the first selection down to the thread immediately above the selected solitary message would be selected.

I could then perform some action (most commonly deletion) on all those messages at once. Now it's a nightmare. Doing what I used to do in 2.66.6 just (as far as I can see) selects the head message in each of the included threads. So performing some operation on all of the contents takes multiple select and operate processes until finally they're all done. The bigger the degree of subthreads in the chosen threads, the more repeats of the process are required.

* - or the head message in a thread with few messages in it, in which case I always knew only the head of that final thread would be selected, but I could tidy up the rest of its contents after the main set had been dealt with.

0000245: MPro doesn't display the URL in the account registration Email from this bugtracker correctly

MPro version 2.68.1

On registering to use this bugtracker, an email is sent containing an URL that must be visited to confirm the registration and enter a password.

MPro does not display the URL correctly, so clicking on it does not go to the required URL.

Where the URL goes:

&confirm_hash=a5

MPro displays &confirm_hash, followed by a symbol of a question mark in a black diamond in place of the =a5, followed by the rest of the URL sequence, but the URL marking stops at the end of 'hash', not including anything further. Clicking on the marked link part then sends the incomplete URL to the browser, resulting in arriving on a Mantis error page rather than the registration completion one.

Switching to View message source in the MPro message does display the full URL correctly, and clicking on it then does complete the registration.

It just seems a bit unfortunate that MPro can't handle the email to sign up to the MPro bugtracker as required.

0000243: Group viewer's 'save column settings' doesn't save Message Grouping setting

MP V2.66.6.3353 4.6.3 XPPro

Whether or not this is a bug is clearly going to depend on one's point of view. I can see that a 'strict' view of what 'save column settings' should do may say that 'Message Grouping' isn't a /column/ setting...

However I often have sets of similar groups which I wish to set up in the same way. In almost all cases I have groups set up so that messages are grouped into threads but recently decided a set of groups would be easier to handle without grouping. So I turned it off in one of them then clicked 'save settings' and selected all the groups into which I wanted the revised settings applied.

A few days later I noticed that while column layout & sorting was now the same in all these groups, whether threading was on was not constant.

Maybe what I really want is a 'save display settings' option.

0000227: Two copies of MP running at once.

MP 2.66.0.3327 Qt 4.6.3 Win XP Pro

I don't know how, though I suppose I must have clicked the MP shortcut twice - those as it's in the Start menu's initial section I find that hard to believe - but I suddenly realised I had two copies of MP running at the same time. I'm quite surprised this is possible. I'd have expected the second one to start to shut itself down.

The XP event logs show them starting 21 seconds apart. They both started fetching, and both started popping-up 'repair initiated on group ' msg boxes. I pulled the LAN cable out of the back of the PC, to try to limit the extent of this. Then clicked on all the repair msgs and shut both apps down.

0000021: Gemini crashes when dragging a message into a folder

Gemini occasionally crashes cleanly when I drag a message from the group viewer panel into a different folder in the group heirarchy. I can see no pattern in this and it only happens occasionally. The only correlation that I am aware of is a possible link to failing to outline the destination folder (the folder under the mouse pointer) - the crash seems often to happen after this failure (but failure to outline the destination doesn't always lead to a crash.

0000246: To add 'Kill Descendants' option

A feature present in the RISC OS version of MPro is 'Kill descendants' to kill threads even if they change the 'Subject' header.

It would be useful to kill Usenet rants without having to kill all the individual contributors or set up new filters every time someone changes the header.