Open Bug 44135 Opened 24 years ago Updated 11 years ago

Allow preview of attachments in mail compose window

Categories

(SeaMonkey :: MailNews: Message Display, enhancement)

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: endico, Unassigned)

References

Details

(Keywords: helpwanted)

The mail compose window should preview attachments as they are added, the same way they would be displayed in the message pane after they are recieved. The fact that they aren't makes it confusing for newbies who find the attachment mechanism unintuitive. This is especially true for forwarded messages where the message is forwarded as a mime attachment. They press the forward button and see a blank compose window. Its not at all obvious where the original mail message went. See bug 21219
This seems not feasible to me. First of all what if we couldn't display or handle the attachment. Secondly, if we did able to preview the attacement where do we show it. Thirdly, if we have 10 attachments how were we able to preview them all in the compose window. And lastly, if attachments require more than one external applications to preview it. It will be way too complicate to do.
for attachment types that aren't viewable, print the same message that shows up in the message pane when you're viewing a message in your inbox that has attachments. for example: ------------------------------------------------------------------- | Name makeslides.pl | | makeslides.pl Type: Perl Program (application/x-perl) | | Encoding: 7bit | ------------------------------------------------------------------- The idea is to make mail compose be wysiwyg. What shows up in the compose window should look pretty close to what the recipient of the message will see.
I don't think we should confuse with the wysiwyg message editing vs attaching the file attachments. Unless we have the OLE embedding capability implemented on our ender engine. Even if we could do the OLE embedding we will have a hard time creating a multipart related message for it. In general we do allow users generating wysiwyg message, users can drag and drop images or links into a compose window but not for the external file attachments. Showing attachments in a separate section of the compose window will further confuse the user IMHO.
> They press the forward button and see a blank compose window. Its not at all > obvious where the original mail message went. I completely agree. I don't see any real problem other than being some work. The attachments are not really editable (other than add/remove parts), so we could use the same or similar code like in the viewer. It could be in a pane below the msg body and onyl be visible if there actually are attachments. Maybe, we should carry this over to the newsgroup?
Even for advanced users, it would be useful to have an optional way to preview attachments, e.g. double-click on the icon in the attachment pane and get a dialog showing the attachment (if it's a type we can display). I've lost count of the times that I've dragged a mail message over to the attachment pane, then looked at the icon that says "Inbox" and wondered, Am I sending my entire inbox? Or some message other than the one I intended? What format? and wished I had a way to preview it (somnetimes, I just delete the attachment and use copy/paste because I want to see what I'm sending). If it's a type we can't display, then we wouldn't have been able to display it on receipt either. No biggie. As to displaying it in the compose window: best and easiest would be to have a separate pane for it, not editable; but it could conceivably be put into the editor pane without making it part of the normal document flow with a bit of tricky CSS (display the attachment using absolute positioning, or some such).
QA Contact: lchiang → pmock
This is really a "feature" (add/change existing design). Reassign to nobody@mozilla.org and add helpwanted keyword for Mozilla contributors to design (w/help from Mozilla community) and implement. If we want this into Netscape 6 for putterman (or other) to work on, we'd need reasoning for the PDT team and nomination for nsbeta2 since I think nsbeta3 is too late to put such design changes in and to test it.
Assignee: putterman → nobody
Keywords: helpwanted
OK, nominating for nsbeta2. I can fully understand if you drop this, but I think, it would help the product. While the current attachments pane is an improvement over 4.x, attachments still don't have the visibility they should have. It happens quite frequently that I forget to perform the attachment. It's a WYSIWYG issue (as akk pointed out). It helps a lot for Forward as Attachment. I can say nothing about the amount of work required :).
Keywords: nsbeta2
nsbeta2?
putterman: If it helps saving the world from malformed attachments and makes using the product more intuitive, ...
I think this is a great idea, but I think it's way too late to consider for nsbeta2, since it involves a significant chunk of new work.
The thing is, nsbeta2+ bugs are bugs Netscape workers work on in order to ship a second beta. nobody@mozilla.org is able to fix this bug whenever they want. This is a feature in my opinion and not something that we should fix for the entirety of this release (we, meaning Netscape. mozilla developers are more than welcome as always to make contributions). I'm not saying this is a bad idea. It's a good idea for those that would want this feature turned on. Personally, I don't want this on. When I want to see the message I'm forwarding, I'd just used Forward as Inline. And for other documents I attach, the attachment pane is more than sufficient. Note, I agree with whoever marked this bug as an enhancement. I just don't think this is an nsbeta2, nsbeta3, or RTM type bug. The other thing is that perhaps Forward as Inline should be the default which would at least solve the problem for new users where they don't know what message they are forwarding. That I think would be a valid nsbeta3 bug.
> This is a feature in my opinion Yes, it is a feature, and it requires work. I didn't say, you must implement it, I just asked for serious consideration. > The other thing is that perhaps Forward as Inline should be the > default which would at least solve the problem for new users where they don't > know what message they are forwarding. Consensus in the non-Netscape, non-Mircosoft, non-Lotus world seems to be that Forward Inline (and "Quote at bottom" BTW) is evil. This bug developed out of the urge *not* to make that the default.
Putting on [nsbeta2-] radar. Not critical to beta2.
Whiteboard: [nsbeta2-]
Assign it to myself.
QA Contact: pmock → fenella
To Esther..
QA Contact: fenella → esther
QA Contact: esther → trix
*** Bug 120132 has been marked as a duplicate of this bug. ***
*** Bug 158397 has been marked as a duplicate of this bug. ***
*** Bug 139721 has been marked as a duplicate of this bug. ***
*** Bug 177244 has been marked as a duplicate of this bug. ***
*** Bug 179470 has been marked as a duplicate of this bug. ***
It already whould be nice if only we can double-click on atachement to preview it like we do in received email.
Check out bug 182121 for double-clicking on attachments to open them.
Depends on: 182121
*** Bug 197282 has been marked as a duplicate of this bug. ***
*** Bug 225426 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
Assignee: nobody → mail
QA Contact: stephend
Assignee: mail → nobody
Priority: P3 → --
QA Contact: message-display
Whiteboard: [nsbeta2-]
I am not sure if this bug fits with the other one described on this page so please excuse if I should have opened another bug report. Composing an e-mail under Seamonkey 1.1.14, I am not able to open an attached file by double-clicking. Saving it in the drafts folder and re-opening it, is a possibility to open the attachment, but as a workaround a bit annoying. Seeing attachments in incoming e-mails is also possible without problems. Used Platform is Win XP
See Also: → 377377
You need to log in before you can comment on or make changes to this bug.