The default bug view has changed. See this FAQ.

Cannot load a pdf file linked from this page

VERIFIED WORKSFORME

Status

Core Graveyard
File Handling
VERIFIED WORKSFORME
15 years ago
9 months ago

People

(Reporter: adrian godwin, Assigned: dougt)

Tracking

Trunk
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

15 years ago
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

15 years ago
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
(Reporter)

Comment 2

15 years ago
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.
 
(Reporter)

Comment 3

15 years ago
Retested with 2002040903.
Problem still exists.
Sorry, I can't test without using a proxy.

Comment 4

15 years ago
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

15 years ago
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

15 years ago
ben is going to take a look at this
QA Contact: tever → benc

Comment 7

15 years ago
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.
(Reporter)

Comment 8

15 years ago
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.
(Reporter)

Comment 9

15 years ago
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 ?


(Reporter)

Comment 10

15 years ago
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

15 years ago
The testpage is gone. Does the bug still show up in 1.1 or later? If so, please
provide new testcase.

pi

Comment 12

15 years ago
->file handling
Assignee: darin → dougt
Component: Networking: HTTP → Networking: File

Comment 13

15 years ago
again...
Component: Networking: File → File Handling

Comment 14

15 years ago
No response, no testcase, marking WFM.

pi
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME

Updated

15 years ago
QA Contact: benc → sairuh
v
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.