Ticket #1484689 (closed Bugs: fixed)

Opened 12 months ago

Last modified 10 months ago

Pdf attachments in rc2

Reported by: ASeques Owned by:
Priority: 5 Milestone: 0.1-stable
Component: Interface Version: 0.1-rc2
Severity: normal Keywords:
Cc:

Description

There is an issue when downloading pdf attached to documents, and strange behaviour if they're send from roundcube and read in internet explorer. These are the cases

1.- Mail sent from thunderbird with the same pdf attached:

Content-Type: multipart/mixed;
 boundary="------------040208040304060905010104"

This is a multi-part message in MIME format.
--------------040208040304060905010104
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

2.- Mail sent from within roundcube with a pdf attached.

Content-Type: multipart/mixed;
	boundary="=_80f2fbaf051bcbf77a7b60d97714871d"

--=_80f2fbaf051bcbf77a7b60d97714871d
Content-Transfer-Encoding: base64
Content-Type: application/pdf; name="781.pdf"; charset="UTF-8"
Content-Disposition: attachment; filename="781.pdf"

In the first case clicking on the name opens a download menu to get the file named "781.pdf" In the second case opens a new windows that loads the acrobat reader (if available) and:

1.- In ie6, ie7 there is a very small frame to preview the pdf

2.- In firefox if you have the acrobat plugin it opens in a window with the proper size and you can save within the acrobat.

The problem in both cases where the attachment is sent with roundcube is that if you want just to download the attachent doing "save link as ..." downloads the file "781.pdf.htm" and the system does not associate with acrobat.

Hope I made myself clear this time :P, sorry to keep reopening the ticket

Change History

follow-up: ↓ 2   Changed 12 months ago by thomasb

1) Thunderbird seems to send the PDF with Content-Type: text/plain; which is definitely wrong (or maybe you copied the wrong part of the message)

2) application/pdf is a known type and RoundCube assumes that browsers can display the inline. It therefore opens the preview window. If the preview box is too small, it's a CSS issue.

I have no explanation why IE adds .htm to the file name that is correctly sent with the HTTP headers. This requires some investigation how IE acts with different content-disposition headers.

in reply to: ↑ 1   Changed 12 months ago by ASeques

Can you view correctly the pdf both in ie7 and firefox in both cases? Because many of the combinations have problems, that's the main reason I'd have liked to have a simple "download as..." button

Another change quite useful was changing skins/default/mail.css that at least solves the previsualizaion problem on inetrnet explorer, donno if replacing the auto to a 100% is a dirty hack but I can confirm it works =================================================================== --- skins/default/mail.css +++ skins/default/mail.css @@ -158,6 +158,6 @@

right: 0px; bottom: 0px;

- width: auto; - height: auto; + width: 100%; + height: 100%;

border: 1px solid #999999; background-color: #F9F9F9;

  Changed 11 months ago by Scythe

This is a massive issue which I'm having with current users of the system -- which send tons of PDF's.

PDF's in IE don't work like they should, or do work in Firefox. Regardless, if they try to view the attachment, it shows in a super small box.

I recommend this one be escalated, because this is a basic feature which should be fixed.

  Changed 10 months ago by thomasb

  • status changed from new to closed
  • resolution set to fixed

Cannot fix the filename problem. However the preview box size has been fixed i r1027

Note: See TracTickets for help on using tickets.