Last Comment Bug 136560 - Cannot load a pdf file linked from this page
: Cannot load a pdf file linked from this page
Status: VERIFIED WORKSFORME
:
Product: Core
Classification: Components
Component: File Handling (show other bugs)
: Trunk
: x86 Windows NT
: -- normal (vote)
: ---
Assigned To: Doug Turner (:dougt)
: sairuh (rarely reading bugmail)
Mentors:
http://www.jpeg.org/public/jbigpt2.htm
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2002-04-10 02:53 PDT by adrian godwin
Modified: 2002-10-07 18:36 PDT (History)
1 user (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description adrian godwin 2002-04-10 02:53:26 PDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.9) Gecko/20020311
BuildID:    2002031104

There's a pdf file linked from this page that Mozilla doesn't want to save (it
times out attempting to load the link target). IE6 can do it OK.


Reproducible: Always
Steps to Reproduce:
1.right clock on link to PDF
2.choose 'save link as..'
3.

Actual Results:  there is a delayof a few sceonds  and eventually a dialog box
indicating that the file can't be loaded and 'might have moved or had its name
changed'. 

Expected Results:  Saved the file. Works OK in IE6.


The build I'm using seems to have become a lot less usable recently - in many
cases I follow a link or type a URL and nothing whatever happens. Reload usually
reloads the already-displayed page and re-doiing the operation quite often
works. Perhaps the reported problem is a special case of the same fault.

Maybe it's my imagination, but I think this behaviour may have started after I
performed a recent MS update (the 'big security patch'). However, I had not
previously updated the machine (NT4) so this could have made quite a lot of
changes. I removed and reinstalled Moz 0.99 in an attempt to fix this (maybe the
MS update broke something ?) but without improvement.
Comment 1 Boris 'pi' Piwinger 2002-04-10 05:43:55 PDT
Works in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020405 and
Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.9+) Gecko/20020409.

pi
Comment 2 adrian godwin 2002-04-10 06:45:53 PDT
Attempted to retest with most recent nightly build (as of 10.4.2002) but that
build  doesn't start on this system. Reverting to 2002031104 still shows
problem. Note that in reverting some proxy info was lost (http proxy socket now
blank, direct connection reselected). My connection is via a netscape proxy :
maybe this is relevant to reprocucing the bug.
 
Comment 3 adrian godwin 2002-04-10 07:42:01 PDT
Retested with 2002040903.
Problem still exists.
Sorry, I can't test without using a proxy.
Comment 4 Sitsofe Wheeler 2002-04-10 09:38:26 PDT
I can't reproduce this with 20020409 Linux i686 and I'm connecting to a proxy
too (I doubt it is a Netscape proxy though).
Comment 5 Darin Fisher 2002-04-10 11:39:49 PDT
tom: can you locate a netscape proxy server that we can use for testing?  and
can you try to reproduce this bug?  thx!
Comment 6 Tom Everingham 2002-04-10 14:05:08 PDT
ben is going to take a look at this
Comment 7 [not reading bugmail] 2002-05-18 13:04:33 PDT
I cant get pdfs to load either in rc2, 5-18-08 nightly on winxp or any other
recent build.. this used to work.  I think it should be nominated for mozilla 1.0.
Comment 8 adrian godwin 2002-05-20 02:32:44 PDT
It's not all pdfs - the particular one (or the particular site) fails
consistently. This occurs also on RC2, but I can still load others.

If our proxy is to blame (it's probably rather overloaded and is often quite
slow), it may also be noteworthy that I very often get a 'page has no content'
error, but  will succeed on retrying. Retrying the pdf load doesn't seem to help.
Comment 9 adrian godwin 2002-06-07 02:41:52 PDT
This problem is largely fixed by changing the HTTP Networking preference to use
HTTP 1.0. Use of persistent connections does not affect it, and pipelining was
turned off anyway so the automatic disabling caused by changing protocol is
irrelevant (tested with release 1.0 on NT4, still behind the NS proxy).

I say 'largely' fixed because there is still a peculiarity : left-clicking on
PDF file link results in the message 'File does begin with %PDF', but if the
file is saved (save link target) it can be seen to start '%PDF-1.1'. ACrobat 5.0
will also load this saved file happily. However, this is a major improvement
over the original behaviour where the file could not be retrieved at all.

I'm ignorant about the differences between HTTP 1.0 and 1.1, and their possible
interactions with proxies. If there is often a problem, would it be helpful to
note this in the proxy setting preference ?


Comment 10 adrian godwin 2002-06-07 02:59:42 PDT
Sorry, I didn't test all combinations of persistent connections and protocol choice.

If HTTP 1.0 is selected, the persistent conneciton choice has no effect -
transfers  are OK either way.

If HTTP 1.1 is selected and persistent connections are disabled, transfers are OK.

If HTTP 1.1 is selected and persistent connections enabled, the transfer fails.


Making this change has improved the performance of many, many other links which
were previously slow or took several attempts before they'd work, but the link
described remains a good pass / fail test.
Comment 11 Boris 'pi' Piwinger 2002-09-06 04:16:56 PDT
The testpage is gone. Does the bug still show up in 1.1 or later? If so, please
provide new testcase.

pi
Comment 12 benc 2002-09-06 08:52:10 PDT
->file handling
Comment 13 benc 2002-09-24 02:08:36 PDT
again...
Comment 14 Boris 'pi' Piwinger 2002-09-29 06:43:13 PDT
No response, no testcase, marking WFM.

pi
Comment 15 sairuh (rarely reading bugmail) 2002-10-07 18:36:12 PDT
v

Note You need to log in before you can comment on or make changes to this bug.