Comments you submit will be routed for moderation. If you have an account, please log in first.

Opened 6 years ago

Closed 5 years ago

#11 closed bug (fixed)

Attachments don't work in read windows

Reported by: saimobvq@… Owned by: somebody
Priority: normal Milestone: YAM 2.7
Component: user interface Version: 2.6
Severity: major Keywords: SF
Cc: OS Platform:
Blocked By: 120 Blocking:
Release Notes:

Description (last modified by damato)

The attachments shown at the bottom of the read window suffer from two problems:

  1. type is not correctly recognized (see window on the left in the attached screenshot)
  2. double-clicking reveals the right type, but does not cause any action (see window on the right in the attached screenshot).

The only exception is that attached emails do work (i.e. double-clicking on one of them causes another read window to appear and show the email).

This has been happening for a while now, but unfortunately I cannot tell the nightly build it appeared in the first time (probably a few months ago). The system is AmigaOS 4.1 on an AmigaOne XE G4.

Moved from SF:

Attachments (1)

grab.png (27.7 KB) - added by damato 6 years ago.
screenshot showing the problem - Moved from SF. Original author: saimobvq

Download all attachments as: .zip

Change History (13)

Changed 6 years ago by damato

screenshot showing the problem - Moved from SF. Original author: saimobvq

comment:1 Changed 6 years ago by damato

Unfortunately this is a normal and known behaviour. The problem is, that the icon type is identified with DefIcons and for DefIcons to work properly it requires access to the complete file content.

Now, as you can see from your example screenshot, the left window correctly identified the "test.lha" as an "LhA archive". However, the size of it has the "~" sign which says that this is an estimate of the real size. Then after you double-clicking on it, YAM extracts the file from the raw email (e.g. via a base64 decoding) and is then able to identify the real size (535 bytes) and is also able to load the real icon via DefIcons.

So I am sorry, but this is a known and totally normal behaviour as the files of attachments are only extracted/decoded from the raw mails when they are actually used as otherwise we would have to decode ALL attachments right away when you open an email. This would, however, require additional processing power and thus slow down the reading of emails.

Moved from SF. Original poster: damato

comment:2 Changed 6 years ago by damato

Thanks for the quick reply.

OK, I understand (and agree to) the choice of limiting decoding only when requested by the user. However, is it also the intended behaviour that double-clicking on the attachment only causes the full type detection? I mean, in the past, double-clicking would trigger the action associated to the file type (f.ex., on my system, clicking on attached LHA archives would open the attachment with UnArc; similarly, a picture would be opened with a viewer, a text file with a reader, and so on)? While the first problem I mentioned is a cosmetic one of very little importance, the second regards an important functionality.

Moved from SF. Original poster: saimobvq@…

comment:3 Changed 6 years ago by damato

Of course, If double clicking on the attachment icon does not open multiview or your user configured action from the preferences this points out a bug in YAM. If this is the case please state so here and we will investigate further. However, double-clicking should open multiview & friends. :)

Moved from SF. Original poster: damato

comment:4 Changed 6 years ago by damato

Yes, that's precisely what I meant at point 2 of my original report.

Moved from SF. Original poster: saimobvq@…

comment:5 Changed 6 years ago by damato

Is this issue still valid? If yes, then please check if you have any MIME type like application/x-lha or similar configured. Also run Snoopy/SnoopDOS in the background to check what is really happening on your system. Maybe a program is started correctly but fails silently.

Does this issue also occur with other file types, i.e. pictures?

Moved from SF. Original poster: thboeckel

comment:6 Changed 6 years ago by damato

mmm... MIME preferences... I don't have any type set, but I do have a
default viewer... and that's it! The viewer was moved from the location
indicated in the preferences, so it was entirely my fault!
I'm very sorry for bothering you for such a stupid mistake. My humblest

Moved from SF. Original poster: saimobvq@…

comment:7 Changed 6 years ago by damato

Ok, marking this bug as "later".

We should think about some kind of error message when executing commands.
But since the very same function is also used during the mail filtering
process an error message would block the whole process.

The best solution would be to finally fire up our thread implementation
and let the thread to the dirty error handling work.

Moved from SF. Original poster: thboeckel

comment:8 Changed 6 years ago by damato

  • Priority changed from major to undecided
  • Severity set to major

comment:9 Changed 6 years ago by damato

  • Component changed from nightly build to undefined

comment:10 Changed 6 years ago by damato

  • Cc yamos-svn@… removed

comment:11 Changed 6 years ago by damato

  • Blocked By 120 added
  • Component changed from undefined to user interface
  • Description modified (diff)
  • Milestone set to YAM 2.7
  • Priority changed from undecided to normal
  • Status changed from new to accepted

As we want to address that issue in 2.7 I am going to mark the milestone here and make it dependent on the multithreading information.

comment:12 Changed 5 years ago by tboeckel

  • Resolution set to fixed
  • Status changed from accepted to closed

(In [4918]) * misc: a failed command execution will now always be reported using the well

known error message window. This finally closes #11. The main thread is no
longer an embedded structure in the global data but allocated dynamically
like any other subthread. First, this is more consistent, and second, this
causes much less dependencies of the source code files.

Add Comment

Modify Ticket

as closed The owner will remain somebody.
The resolution will be deleted. Next status will be 'reopened'.

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.

This list contains all users that will be notified about changes made to this ticket.

These roles will be notified: Reporter, Owner, Subscriber

  • saimobvq@…(Reporter)