SM 2.7.2 download not possible (yet another plugin!=download problem?)

[A.D. Fundum]

Original website with direct links to PDF files:

http://www.wgs.nl/genieten-water/fiets-genieten/

Such a direct link is:

http://www.wgs.nl/publish/pages/4466/wgs8083_kaart1_a4.pdf

About all ways (LMB, RMB, direct URL) to download such a PDF file
result in a Save As/Open With-dialog, but none of the ways results in
an actual download. It's possible to download the file with WGET, and
v4.0 of the Acrobat Reader is perfectly capable of displaying the PDF
file downloaded with WGET.


--

[Peter Brown]

Hi

Post by A.D. Fundum
http://www.wgs.nl/genieten-water/fiets-genieten/
http://www.wgs.nl/publish/pages/4466/wgs8083_kaart1_a4.pdf
About all ways (LMB, RMB, direct URL) to download such a PDF file
result in a Save As/Open With-dialog, but none of the ways results in
an actual download. It's possible to download the file with WGET, and
v4.0 of the Acrobat Reader is perfectly capable of displaying the PDF
file downloaded with WGET.
--

Just downloaded the above pdf file using Seamonkey - Build identifier:
Mozilla/5.0 (OS/2; Warp 4.5; rv:10.0.5) Gecko/20120603 Firefox/10.0.5
SeaMonkey/2.7.2

I did notice that clicking OK on the Seamonkey Open/Save dialog resulted
in a long pause beofre the save file to dialog appeared but the download
was successful and the file can be read with both AR5 and Lucide.


Regards

Pete

[A.D. Fundum]

Post by Peter Brown

Post by A.D. Fundum
http://www.wgs.nl/publish/pages/4466/wgs8083_kaart1_a4.pdf

Just downloaded the above pdf file using Seamonkey
I did notice that clicking OK on the Seamonkey Open/Save dialog
resulted in a long pause beofre the save file to dialog appeared

Thanks. Just retried it: about 6 seconds delay before the
Open/Save-dialog, less than one second delay before the Save appears.
With a PIII 500 MHz, that is.

The default directory is the messy C:\HOME\DEFAULT\DOWNLOADS. If I
save the file there, the file is downloaded. If I change the directory
to C:\ or some new subdirectory, the saving fails (i.e. never starts).
So the problem no longer is that the file cannot be downloaded, but
that changing the directory fails to save the file.


--

[Peter Brown]

Hi

Post by A.D. Fundum

Post by Peter Brown

Post by A.D. Fundum
http://www.wgs.nl/publish/pages/4466/wgs8083_kaart1_a4.pdf

Just downloaded the above pdf file using Seamonkey
I did notice that clicking OK on the Seamonkey Open/Save dialog
resulted in a long pause beofre the save file to dialog appeared

Thanks. Just retried it: about 6 seconds delay before the
Open/Save-dialog, less than one second delay before the Save appears.
With a PIII 500 MHz, that is.
The default directory is the messy C:\HOME\DEFAULT\DOWNLOADS. If I
save the file there, the file is downloaded. If I change the directory
to C:\ or some new subdirectory, the saving fails (i.e. never starts).
So the problem no longer is that the file cannot be downloaded, but
that changing the directory fails to save the file.
--

I do not see that behaviour - probably because I do *not* have a default
download directory set. I use the "Always ask me where to save files"
setting in Preferences and do not have problems saving files anywhere.

I do seem to recall some discussion about Firefox/Seamonkey download
problems in the mozilla ng a while back but, if I remember correctly,
the problem was only when saving to the root of a drive eg C:\ -
downloads to subdirectories worked OK.

I suspect that got fixed as I have no problem downloading the pdf file
to g:\ - OTOH maybe the problem only affects those using a Default
download directory...


Regards

Pete

[Andreas Schnellbacher]

Post by Peter Brown
I do seem to recall some discussion about Firefox/Seamonkey download
problems in the mozilla ng a while back but, if I remember
correctly, the problem was only when saving to the root of a drive
eg C:\ - downloads to subdirectories worked OK.

Maybe you've read my posting where I wrote about a LMB click download
problem, while others have RMB click problems. I finally found it and
am glad that I don't have to recreate my entire profile: The culprit
was mimetypes.rdf.

[A.D. Fundum]

I finally found it and am glad that I don't have to recreate
my entire profile: The culprit was mimetypes.rdf.

Why was it the culprit? AFAIK the MIMETYPES.RDF in my rather new
profile contains no intentional changes, possibly with the exception
of the additionally installed plugins flash7a63RW.zip (Flash 7) and
npgbm146_os2.xpi (GBM).


--

[Steve Wendt]

Post by Andreas Schnellbacher
Maybe you've read my posting where I wrote about a LMB click download
problem, while others have RMB click problems. I finally found it and
am glad that I don't have to recreate my entire profile: The culprit
was mimetypes.rdf.

Was it affecting all file types, or just specific ones listed in the
mimetypes.rdf file?

[Andreas Schnellbacher]

Post by Steve Wendt

Post by Andreas Schnellbacher
Maybe you've read my posting where I wrote about a LMB click
download problem, while others have RMB click problems. I finally
found it and am glad that I don't have to recreate my entire
profile: The culprit was mimetypes.rdf.

Was it affecting all file types, or just specific ones listed in the
mimetypes.rdf file?

Hard to check:

That original file is large, so probably most of the links I've ever
clicked on to download are included. At least I haven't found anything
interesting that's not.

[A.D. Fundum]

Post by Andreas Schnellbacher
That original file is large

Mine isn't that large (2683 bytes, 111 lines, quite new, no
intentional MIME-related changes):


--

<?xml version="1.0"?>
<RDF:RDF xmlns:NC="http://home.netscape.com/NC-rdf#"
xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<RDF:Description
RDF:about="urn:mimetype:externalApplication:text/txt"
NC:path="E:\TCPIP\SeaMonkey\seamonkey.exe"
NC:prettyName="seamonkey.exe" />
<RDF:Description RDF:about="urn:mimetype:text/txt"
NC:value="text/txt"
NC:editable="true"
NC:description="Text File">
<NC:fileExtensions>txt</NC:fileExtensions>
<NC:fileExtensions>text</NC:fileExtensions>
<NC:handlerProp RDF:resource="urn:mimetype:handler:text/txt"/>
</RDF:Description>
<RDF:Description RDF:about="urn:mimetypes">
<NC:MIME-types RDF:resource="urn:mimetypes:root"/>
</RDF:Description>
<RDF:Description RDF:about="urn:mimetype:handler:text/csv"
NC:alwaysAsk="true"
NC:saveToDisk="true"
NC:useSystemDefault="false">
<NC:externalApplication
RDF:resource="urn:mimetype:externalApplication:text/csv"/>
</RDF:Description>
<RDF:Description RDF:about="urn:mimetype:application/x-jpg"
NC:value="application/x-jpg"
NC:editable="true"
NC:fileExtensions="jpg"
NC:description="JPG-bestand">
<NC:handlerProp
RDF:resource="urn:mimetype:handler:application/x-jpg"/>
</RDF:Description>
<RDF:Seq RDF:about="urn:mimetypes:root">
<RDF:li RDF:resource="urn:mimetype:application/zip"/>
<RDF:li RDF:resource="urn:mimetype:application/x-trp"/>
<RDF:li RDF:resource="urn:mimetype:text/txt"/>
<RDF:li RDF:resource="urn:mimetype:application/x-pdf"/>
<RDF:li RDF:resource="urn:mimetype:application/pdf"/>
<RDF:li RDF:resource="urn:mimetype:application/x-jpg"/>
<RDF:li RDF:resource="urn:mimetype:text/csv"/>
</RDF:Seq>
<RDF:Description RDF:about="urn:root"
NC:nl_defaultHandlersVersion="-1" />
<RDF:Description RDF:about="urn:mimetype:application/x-trp"
NC:value="application/x-trp"
NC:editable="true"
NC:fileExtensions="trp"
NC:description="TRP-bestand">
<NC:handlerProp
RDF:resource="urn:mimetype:handler:application/x-trp"/>
</RDF:Description>
<RDF:Description RDF:about="urn:mimetype:application/pdf"
NC:fileExtensions="pdf"
NC:description="PDF-bestand"
NC:value="application/pdf"
NC:editable="true">
<NC:handlerProp
RDF:resource="urn:mimetype:handler:application/pdf"/>
</RDF:Description>
<RDF:Description RDF:about="urn:mimetype:handler:text/txt"
NC:alwaysAsk="true"
NC:saveToDisk="false"
NC:useSystemDefault="false"
NC:handleInternal="false">
<NC:externalApplication
RDF:resource="urn:mimetype:externalApplication:text/txt"/>
</RDF:Description>
<RDF:Description RDF:about="urn:mimetype:text/csv"
NC:fileExtensions="csv"
NC:description="csv File"
NC:value="text/csv"
NC:editable="true">
<NC:handlerProp RDF:resource="urn:mimetype:handler:text/csv"/>
</RDF:Description>
<RDF:Description RDF:about="urn:mimetype:application/zip"
NC:fileExtensions="zip"
NC:description="zip File"
NC:value="application/zip"
NC:editable="true">
<NC:handlerProp
RDF:resource="urn:mimetype:handler:application/zip"/>
</RDF:Description>
<RDF:Description RDF:about="urn:mimetype:handler:application/x-trp"
NC:alwaysAsk="true"
NC:useSystemDefault="true">
<NC:externalApplication
RDF:resource="urn:mimetype:externalApplication:application/x-trp"/>
</RDF:Description>
<RDF:Description RDF:about="urn:mimetype:handler:application/pdf"
NC:alwaysAsk="true"
NC:saveToDisk="true"
NC:useSystemDefault="false">
<NC:externalApplication
RDF:resource="urn:mimetype:externalApplication:application/pdf"/>
</RDF:Description>
<RDF:Description RDF:about="urn:mimetype:handler:application/zip"
NC:alwaysAsk="true"
NC:saveToDisk="true"
NC:useSystemDefault="false">
<NC:externalApplication
RDF:resource="urn:mimetype:externalApplication:application/zip"/>
</RDF:Description>
<RDF:Description RDF:about="urn:mimetype:handler:application/x-jpg"
NC:alwaysAsk="true"
NC:useSystemDefault="true">
<NC:externalApplication
RDF:resource="urn:mimetype:externalApplication:application/x-jpg"/>
</RDF:Description>
<RDF:Description RDF:about="urn:mimetype:application/x-pdf"
NC:value="application/x-pdf"
NC:editable="true"
NC:fileExtensions="pdf"
NC:description="PDF-bestand">
<NC:handlerProp
RDF:resource="urn:mimetype:handler:application/x-pdf"/>
</RDF:Description>
<RDF:Description RDF:about="urn:mimetype:handler:application/x-pdf"
NC:alwaysAsk="true"
NC:useSystemDefault="true">
<NC:externalApplication
RDF:resource="urn:mimetype:externalApplication:application/x-pdf"/>
</RDF:Description>
</RDF:RDF>

[Steve Wendt]

Post by A.D. Fundum

Post by Andreas Schnellbacher
That original file is large

Mine isn't that large (2683 bytes, 111 lines, quite new, no

My mimetypes.rdf is 24816 bytes, but I haven't had the problem described
by Andreas. I definitely have some entries in there for pdf; I haven't
verified, but I believe the list should match what is shown in the
Browser->Helper Applications preferences section. I believe RWS gets
involved here, so it's possible the bug is in there; Andreas, have you
tried disabling that?

[A.D. Fundum]

the list should match what is shown in the Browser->
Helper Applications preferences section.

I've got 2 PDF-related entries there, for pdf and x-pdf. "Always ask",
twice.The links in the OP end up in the expected dialog. But the list
of PDF files at http://www.aex.nl/opc is always opened by the plugin,
e.g.:

http://www.aex.nl/sites/euconsumer.nyx.com/files/pricelists/opc_201206
26_def.pdf


--

[Andreas Schnellbacher]

Post by Steve Wendt
My mimetypes.rdf is 24816 bytes, but I haven't had the problem
described by Andreas. I definitely have some entries in there for
pdf; I haven't verified, but I believe the list should match what is
shown in the Browser->Helper Applications preferences section. I
believe RWS gets involved here, so it's possible the bug is in
there; Andreas, have you tried disabling that?

Not yet. I'll test that later.

Even more interesting: I have now a reproducible scenario. It happens
when I update [1] from SM 2.3 to the actual SM 2.7.2 (10.5 ESR) and
then go back to SM 2.3.

[1] First I remove all files of the seamonkey dir, except
seamonkey!.exe to keep the associations. Then I unpack into the same
dir. I always use the same profile.

BTW: I'm back on 2.3 because since some SM versions there's a problem
with reading newsgroup messages: For multiple newsgroups the message
pane/window is always empty. Should be better change to
mozilla.dev.ports.os2?

[Steve Wendt]

Post by Andreas Schnellbacher
Even more interesting: I have now a reproducible scenario. It happens
when I update [1] from SM 2.3 to the actual SM 2.7.2 (10.5 ESR) and
then go back to SM 2.3.

The profile data is usually kept forward-compatible, but not always
backward-compatible. I don't know of any specific reason for this, but
it's likely such a bug report would get WONTFIXed.

Post by Andreas Schnellbacher
BTW: I'm back on 2.3 because since some SM versions there's a problem
with reading newsgroup messages: For multiple newsgroups the message
pane/window is always empty.

Can't say I've seen this. Sometimes I've seen network traffic delays
cause the highlighted message to not have the content shown, but usually
selecting another message and going back to it solves that. As I
recall, the read status usually stays at unread when this happens. And
this is a cross-platform thing that goes back farther than 2.3, if my
memory serves.

Post by Andreas Schnellbacher
Should be better change to mozilla.dev.ports.os2?

Probably.

[Dave Yeo]

Post by Steve Wendt

Post by Andreas Schnellbacher
Even more interesting: I have now a reproducible scenario. It happens
when I update [1] from SM 2.3 to the actual SM 2.7.2 (10.5 ESR) and
then go back to SM 2.3.

The profile data is usually kept forward-compatible, but not always
backward-compatible. I don't know of any specific reason for this, but
it's likely such a bug report would get WONTFIXed.

Somebody reported a similar issue, as Steve said, they don't worry about
backward-compatibility with versions only having a 6 week life now.

Post by Steve Wendt

Post by Andreas Schnellbacher
BTW: I'm back on 2.3 because since some SM versions there's a problem
with reading newsgroup messages: For multiple newsgroups the message
pane/window is always empty.

Can't say I've seen this. Sometimes I've seen network traffic delays
cause the highlighted message to not have the content shown, but usually
selecting another message and going back to it solves that. As I recall,
the read status usually stays at unread when this happens. And this is a
cross-platform thing that goes back farther than 2.3, if my memory serves.

I get this a lot due to small pipe. Things have improved as previous
versions would show a blank and change the read status and cache it as
well. Now I can usually go to a different message, return and the
message loads.

Post by Steve Wendt

Post by Andreas Schnellbacher
Should be better change to mozilla.dev.ports.os2?

Probably.

Dave

[Andreas Schnellbacher]

Post by Dave Yeo

Post by Steve Wendt

Post by Andreas Schnellbacher
BTW: I'm back on 2.3 because since some SM versions there's a
problem with reading newsgroup messages: For multiple newsgroups
the message pane/window is always empty.

Can't say I've seen this. Sometimes I've seen network traffic
delays cause the highlighted message to not have the content shown,
but usually selecting another message and going back to it solves
that. As I recall, the read status usually stays at unread when
this happens. And this is a cross-platform thing that goes back
farther than 2.3, if my memory serves.

I get this a lot due to small pipe. Things have improved as previous
versions would show a blank and change the read status and cache it
as well. Now I can usually go to a different message, return and the
message loads.

Yes I know that workaround, but that changed with 2.3 already.
Unfortunately there are too many other problems with 2.3, that are
fixed in newer versions.

[Andreas Schnellbacher]

Post by Steve Wendt

Post by Andreas Schnellbacher
BTW: I'm back on 2.3 because since some SM versions there's a
problem with reading newsgroup messages: For multiple newsgroups
the message pane/window is always empty.

Can't say I've seen this. Sometimes I've seen network traffic delays
cause the highlighted message to not have the content shown, but
usually selecting another message and going back to it solves that.
As I recall, the read status usually stays at unread when this
happens. And this is a cross-platform thing that goes back farther
than 2.3, if my memory serves.

Sure (I've read about that bug in de.comm.software.mozilla.mailnews) -
and that was the reason I didn't report it on the os2 group. I'm too
lazy to search for the bug.

[A.D. Fundum]

I do *not* have a default download directory set

Nor do I, as such. But my standard download directory was removed, so
SM "downgraded" to this default bootdrive-directory, and I like to
save PDF files to a root directory when I'm going to use the WPS to
object the open. That's why I didn't recreate my standard download
directory, and I assumed it was a PDF-related problem.

the problem was only when saving to the root of a drive eg C:\

Confirmed.

downloads to subdirectories worked OK.

Confirmed. I recreated my temporary standard download directory
(C:\Something) and it saved the file.

I suspect that got fixed as I have no problem downloading the
pdf file to g:\ -

Apparently not. The existing directory I've successfully used the last
time, C:\Something, is remembered bij SM (same latest build as yours)
Selecting I:\ for the next try, the root directory of a HPFS USB
flash drive in the Save-file dialog ,shows the same problem.

OTOH maybe the problem only affects those
using a Default download directory...

It should be possible to save files to a root directory with default
setting (perhaps it always adds a "\" to a selected directory, but
that's not important right now). I do like the default behaviour of
being able to select a directory, as opposed to some fixed
Bootdrive:\This Computer\My Documents\Downloads folder. What's
required to use your setting, so we are talking about the same
setting? No problem if the changed setting only applies to PDF files
(MIME), no problem if it applies to all downloads. BTW, I don't think
my situation is special, so I don't expect different results.


--

[Dave Yeo]

Post by A.D. Fundum

I do *not* have a default download directory set

Nor do I, as such. But my standard download directory was removed, so
SM "downgraded" to this default bootdrive-directory, and I like to
save PDF files to a root directory when I'm going to use the WPS to
object the open. That's why I didn't recreate my standard download
directory, and I assumed it was a PDF-related problem.

the problem was only when saving to the root of a drive eg C:\

Confirmed.

downloads to subdirectories worked OK.

Confirmed. I recreated my temporary standard download directory
(C:\Something) and it saved the file.

I suspect that got fixed as I have no problem downloading the
pdf file to g:\ -

Apparently not. The existing directory I've successfully used the last
time, C:\Something, is remembered bij SM (same latest build as yours)
Selecting I:\ for the next try, the root directory of a HPFS USB
flash drive in the Save-file dialog ,shows the same problem.

OTOH maybe the problem only affects those
using a Default download directory...

It should be possible to save files to a root directory with default
setting (perhaps it always adds a "\" to a selected directory, but
that's not important right now). I do like the default behaviour of
being able to select a directory, as opposed to some fixed
Bootdrive:\This Computer\My Documents\Downloads folder. What's
required to use your setting, so we are talking about the same
setting? No problem if the changed setting only applies to PDF files
(MIME), no problem if it applies to all downloads. BTW, I don't think
my situation is special, so I don't expect different results.
--

It's https://bugzilla.mozilla.org/show_bug.cgi?id=573220. It seems to
only affect some installs and the workaround is to save to a directory.
Dave

[A.D. Fundum]

Post by Dave Yeo
https://bugzilla.mozilla.org/show_bug.cgi?id=573220

My experience exactly matches Steve Wendt's comment #12.


--

[Peter Brown]

Hi

Post by A.D. Fundum

I do *not* have a default download directory set

Nor do I, as such. But my standard download directory was removed, so
SM "downgraded" to this default bootdrive-directory, and I like to
save PDF files to a root directory when I'm going to use the WPS to
object the open. That's why I didn't recreate my standard download
directory, and I assumed it was a PDF-related problem.

the problem was only when saving to the root of a drive eg C:\

Confirmed.

downloads to subdirectories worked OK.

Confirmed. I recreated my temporary standard download directory
(C:\Something) and it saved the file.

I suspect that got fixed as I have no problem downloading the
pdf file to g:\ -

Apparently not. The existing directory I've successfully used the last
time, C:\Something, is remembered bij SM (same latest build as yours)
Selecting I:\ for the next try, the root directory of a HPFS USB
flash drive in the Save-file dialog ,shows the same problem.

OTOH maybe the problem only affects those
using a Default download directory...

It should be possible to save files to a root directory with default
setting (perhaps it always adds a "\" to a selected directory, but
that's not important right now). I do like the default behaviour of
being able to select a directory, as opposed to some fixed
Bootdrive:\This Computer\My Documents\Downloads folder. What's
required to use your setting, so we are talking about the same
setting? No problem if the changed setting only applies to PDF files
(MIME), no problem if it applies to all downloads. BTW, I don't think
my situation is special, so I don't expect different results.
--

Preferences -> Browser -> Downloads -> When saving a file -> Always ask
me where to save files


Regards

Pete

[A.D. Fundum]

Post by Peter Brown
Preferences -> Browser -> Downloads -> When saving a file ->
Always ask me where to save files

Thanks, I already had that setting in use. Apparently it's the
default, because it's not a part of my full re-install procedures.

Nevertheless this PDF-file is always (AFAICR) opened with the plugin,
without the dialog:

http://www.aex.nl/sites/euconsumer.nyx.com/files/pricelists/opc_201206
26_def.pdf

So the PDF maps&routes in the OP always do result in the expected
dialog, while these PDF-newspapers (@http://www.aex.nl/opc) don't.

BTW, this also explains why I saved the file in the first place. The
v4.0 Acrobat Reader-plugin didn't open it, so there "could have been"
some problem which required the use of other PDF-tools.

<off-topic>
The other day I was late visiting a busy fair for an awful lot of
young ICT professionals (I'm not). According to the girls at the door,
I (i.e. the eCS user) was the first and only visitor without the
demanded, printed PDF eTicket. Instead I extracted the barcode image
from the PDF file, mailed it to my cell phone and did show that. It
worked. I wasn't trying to be special, I just didn't want to bring a
piece of paper because of having to travel for several hours outdoors.
Perhaps our future is that young ICT professionals write PDF tools
while we, the only real user of it, cannot use it because of serious
issues with fonts... :-/
</off-topic>


--

[Peter Brown]

Hi

Post by A.D. Fundum

Preferences -> Browser -> Downloads -> When saving a file ->
Always ask me where to save files

Thanks, I already had that setting in use. Apparently it's the
default, because it's not a part of my full re-install procedures.
Nevertheless this PDF-file is always (AFAICR) opened with the plugin,
http://www.aex.nl/sites/euconsumer.nyx.com/files/pricelists/opc_201206
26_def.pdf

I cannot confirm that as I cannot find the file on
http://www.aex.nl/sites/euconsumer.nyx.com/files/pricelists/

In fact the only pdf file I see on that page is
http://www.aex.nl/sites/sites/euconsumer.nyx.com/files/amx-index_brochure_2012-04.pdf
but clicking the link results in a "Page not found" message.

However, pressing the Shift key while clicking on a link leading to a
pdf file should cause the Save As dialog to appear.

Post by A.D. Fundum
So the PDF maps&routes in the OP always do result in the expected

The Shift-Click routine works fine to save the pdf files on
http://www.aex.nl/opc

Simply clicking the link here results in the javascript pdf extension I
have installed - https://github.com/mozilla/pdf.js - opening the file in
the browser.

If I did not have the pdf extension installed I would expect the Acrobat
plugin to open the file when I clicked on it.

Post by A.D. Fundum
BTW, this also explains why I saved the file in the first place. The
v4.0 Acrobat Reader-plugin didn't open it, so there "could have been"
some problem which required the use of other PDF-tools.
<off-topic>
The other day I was late visiting a busy fair for an awful lot of
young ICT professionals (I'm not). According to the girls at the door,
I (i.e. the eCS user) was the first and only visitor without the
demanded, printed PDF eTicket. Instead I extracted the barcode image
from the PDF file, mailed it to my cell phone and did show that. It
worked. I wasn't trying to be special, I just didn't want to bring a
piece of paper because of having to travel for several hours outdoors.
Perhaps our future is that young ICT professionals write PDF tools
while we, the only real user of it, cannot use it because of serious
issues with fonts... :-/
</off-topic>
--

Regards

Pete

[A.D. Fundum]

http://www.aex.nl/sites/euconsumer.nyx.com/files/pricelists/opc_201206

Post by Peter Brown

Post by A.D. Fundum
26_def.pdf

I cannot confirm that as I cannot find the file

That may be a legal issue, sorry.
The main page is http://www.aex.nl/opc, with a list of PDF files per
business day. Never mind, the message is that a direct link to a
certain PDF file always fails (expected file dialog, not possible to
use a root directory). While direct links to other PDF files always
work (but for the wrong reason, it's opened by the plugin, without the
expected save-as/open-with dialog). And Acrobat Reader v4.0 is capable
of opening both files.

With a direct link I mean an URL which ends with ".pdf", i.e. the name
of the file.

Post by Peter Brown
clicking the link here results in the javascript pdf extension I
have installed - https://github.com/mozilla/pdf.js

Apparently the problem isn't related to the Acrobat Reader plugin. I
had the same problem while downloading a Hobbes file. OTOH I never
have the problem with the Video DownloadHelper plugin. This plugin
uses some default directory as its file dialog-starting point, to save
e.g. YouTube videos, but so far I never had any problem saving the MP4
files to any root directory using the file dialog. FWIW...


--

[Steve Wendt]

Post by Peter Brown
I do seem to recall some discussion about Firefox/Seamonkey download
problems in the mozilla ng a while back but, if I remember correctly,
the problem was only when saving to the root of a drive eg C:\ -
downloads to subdirectories worked OK.

I believe the problem is intermittent, which makes it hard to tell if it
is fixed (unless you are downloading to the root directory a lot).

[Dave Yeo]

Post by A.D. Fundum
http://www.wgs.nl/genieten-water/fiets-genieten/
http://www.wgs.nl/publish/pages/4466/wgs8083_kaart1_a4.pdf
About all ways (LMB, RMB, direct URL) to download such a PDF file
result in a Save As/Open With-dialog, but none of the ways results in
an actual download. It's possible to download the file with WGET, and
v4.0 of the Acrobat Reader is perfectly capable of displaying the PDF
file downloaded with WGET.

There's also https://github.com/mozilla/pdf.js to display PDF files in
the browser. Last time I tried only the development version worked in
SeaMonkey.
Dave

[Steve Wendt]

Post by Dave Yeo
There's also https://github.com/mozilla/pdf.js to display PDF files in
the browser. Last time I tried only the development version worked in
SeaMonkey.

Unfortunately, it has some major font issues on OS/2.