Closed Bug 270560 Opened 20 years ago Closed 17 years ago

problems with attachements from type pdf (IFRAME and download)

Categories

(Bugzilla :: Attachments & Requests, defect)

2.18
x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: Leufkes, Unassigned)

Details

Attachments

(1 file)

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Build Identifier: 

On our Bugzilla Installation (2.18rc2 under Reh Hat Linux ES 3) we have 
problems viewing pdf-attachments. 

With all other types I testet (txt,gif,msword,xml,html,jpg and so on) the 
viewing (IFRAME ín view all or Download if the preview is not possible) is ok.

But when viewing a pdf the link to the download resultes in an empty brower 
window (IE and firefox under Win XP). The first time you click download the 
Adobe splashscreen comes up and then nothing happens.

When right clicking the Download link and take a "Save as..." the pdf is 
stored an the client and I can load it. But this is just a workaround as we 
use intensive pdf-files as attachements...

Reproducible: Always
Steps to Reproduce:
1. upload a pdf as attachment
2 [details] [diff] [review]. view/download the attachment
3 [details] [diff] [review].

Actual Results:  
white browser window

Expected Results:  
the pdf should be displayed in the pdf-plugin of the IE
(or in an new instance of the pdf-viewer)

this is of cource testet with other websites !
this upload was auto-detect !
This sounds a lot like a browser problem.  Have you tried it with Firefox?
Works for me with Firefox/Mac OS X.  Your PDF attachment opened with the plugin
in the browser window.
the behaviour from this link
https://bugzilla.mozilla.org/attachment.cgi?id=166311&action=view
is the same as from our bugzilla installation and results in an empty IE 
window under Window XP 
(this might be a client configuration problem, but I don´t see the difference 
to others types of attachments)

we move from Bugzilla 2.13 running under Windows 2000 Server yesterday, and 
the problem with displaying the PDFs is definitly since the migration to 
2.18rc2 under RH
clicking the link in Firefox 1.0 starts the download manager and then the pdf 
is displayed in a new instance of the Adobe Reader
can someone test it with the IE please ...
http://www.adobe.com/support/techdocs/325875.html

The Acrobat Reader plugin for MSIE on Windows requires ActiveX.  You more than
likely have ActiveX disabled for the security zone that includes Bugzilla.
Hello Dave,

ActiveX is enabled for the security zone that includes Bugzilla.

We habe included a pdf on the index page of our bugzilla installation for 
example, that describes the workflow in our company in a graphical way. This 
pdf is displayed in the brower window (-> with the adobe plugin). And as this 
is the same webserver (-> same security zone) and the same client, the problem 
seems to be when getting the pdf´s with the attachment.cgi.

Other attachment-types (like msword) are displayed correctly in the IFRAME 
(Yes, I have changed isViewable in attachment.cgi in that way:
> # We assume we can view all application/ms types  
>    if ($contenttype =~ /^(application)\/(msword|ms-excel|vnd.ms-excel)/) {
>      return 1;
>  }) 
They need ActiceX as well.

It is problaby the way bugzilla starts the pdf-viewer ?? 
Or it is a bug in the adobe viewer itself !
On my tests I could see a AcroRD32.exe in the taskmanager of my XP-Client 
after a download with the white browser content (see above). 
It is running in the background. When starting the Adobe Reader manually 
(Start|Programs|...) he recognized the running instance and then the content 
of all downloaded pdf-attachments is displayed !
still sounds like a browser and/or plugin problem.  The code that generates the
headers for the view attachment URL has been scrutinized and crafted by the
browser bigwigs themselves over the last couple years, and I'll guarantee you
that the headers it's sending now are 100% RFC-compliant.  Bugzilla doesn't do
anything special with PDFs, it's just another document type.

Only thing I can think of is if it's using the filename from the URL instead of
the alternate name included in the headers when passing the file to the plugin,
and the plugin is balking because it ends in .cgi instead of .pdf.  It *is*
passing the filename that's assigned on the edit attachment page in the headers
however, and that's the filename the plugin should be using to look at the
extension if it cares about it that much.
I think it should be testet to get the attachment of this bugs with the pdf 
viewer under XP ) from outside our company to figure out if this is a bug 
(bugzilla or adobe plug in) or a configuration problem of our client 
installations.

We have installed the lastet version 6.0.2 of the adobe reader and Win XP SP1.
I will try this from my laptop@home.
(In reply to comment #9)
> Only thing I can think of is if it's using the filename from the URL instead 
of
> the alternate name included in the headers when passing the file to the 
plugin,
> and the plugin is balking because it ends in .cgi instead of .pdf.  It *is*
> passing the filename that's assigned on the edit attachment page in the 
headers
> however, and that's the filename the plugin should be using to look at the
> extension if it cares about it that much.

hhm, that could explain the difference to the pdf-file on our index page that 
maps the pdf direct ( http://bugzilla.ihk-gfi.de/IssueTrackingProcess.pdf )
I have testet to get the pdf attached with this bug from home with my laptop 
now (-> from outside my company). The behavior is the same. The Adobe Reader 
seems to be startet but this ends with a white brower window (IE under XP SP2 
and Adobe Reader 6.0.2). Also I can find a task called AcroRD32.exe with my 
taskmanager (but no window in the taskbar). When I start the Adobe Reader 
manually, the running instance of the reader is displayed with the content of 
the pdf.
With firefox 1.0 everything is fine (the pdf is played in the brower plugin).
Unfortunalty IE is the standard browser in our company ;-(
Any hints welcome...

 
You could try changing attachment.cgi to send 'inline' instead of 'attachment'
for the Content-Disposition header.  If that fixes it, then this is definitely a
bug in IE.
I have changed the attachment.cgi in that way (line 503 ++):

if ($contenttype eq 'application/pdf') {
    print Bugzilla->cgi->header(-type=>"$contenttype; name=\"$filename\"",
                                -content_disposition=> "attachment; 
filename=\"$filename\"",
                                -content_length => $filesize);
                                } 
    else {
      print Bugzilla->cgi->header(-type=>"$contenttype; name=\"$filename\"",
                                  -content_disposition=> "inline; 
filename=\"$filename\"",
                                  -content_length => $filesize);
         }

"inline" seems to be standard and I have changed to "attachment" for pdf. Now 
a open?-question pops up and after that the pdf is load and displayed in the 
browser plugin (in IE and firefox).

Thx.
QA Contact: mattyt-bugzilla → default-qa
Assignee: myk → attach-and-request
Severity: major → normal
Keywords: qawanted
Version: unspecified → 2.18
Years after, I still cannot reproduce the bug, neither on Windows nor on Linux, neither with Firefox nor with IE. Marking as WFM.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Keywords: qawanted
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: