ぼくのところの Firefox 3.5.1 + Windows XP SP3 の環境では、ご提示の画像はいずれも D & D でデスクトップに保存でき、規定のビューアで正常に閲覧できました。
http://www.dotup.org/ のほうは、アップされてる画像（.jpg / .png / .bmp のみ。.swf など動画は除く）を最新順で 20 ほど試してみましたが、やってみた限りでは、D & D でファイルをデスクトップに落とせない画像はなく、落とせたものはすべて正常に画像ソフト（ビューア）で開けました

http://appulo.us/appdb/ のほうは、ちょっと不可解なことがあります。
ご提示の
http://appulo.us/appdb/appimages/screen ... screen.jpg
や
http://appulo.us/appdb/appimages/screen ... screen.jpg
なんですが、みなさん、同一の画像を見ておられるのでしょうか？
Firefox 3.5.1 でこのフォーラムを見て、そこに貼られた
http://appulo.us/appdb/appimages/screen ... screen.jpg
や
http://appulo.us/appdb/appimages/screen ... screen.jpg
を中クリック -> 新タブで開くと、どちらも黒地に白と青の Appulo.us の文字をメインにした縦長の画像が表示され、その画像を D & D でデスクトップに保存すると「317243777screen.png」や「303442216screen.png」のファイル名で同じ中身の画像が保存されます。
しかし、これらの URL をコピーして、別のブラウザ（例：Firefox 3.0.11／Safari 4.0.2／IE6 など）、あるいは同じ Firefox（キャッシュ全無効）で新タブを開きロケーションバーに URL を貼り付けて開くと、それぞれまったく別の画像が表示されます。例えば、前者は 3DCG で作られたサッカーの PK の場面、後者は「AT&T 3G 9:20 PM」がタイトルバーに記され下にサイコロのある画面とか。それも時間によって変わることがあるようです。（これ、アクセス経路によってサーバー側が切り替えてるんですかね？）
で、これらの画像自体は、 D & D で問題なくデスクトップに保存できます。

これも試したのですが、Windows上の Firefox 3.5.1 で開いた
http://appulo.us/appdb/appimages/screen ... screen.jpg
や
http://appulo.us/appdb/appimages/screen ... screen.jpg
を Safari 4.0.2 に D & D すると、Firefox 上で見えていたのとは別の画像が出てくるんですよね。ロケーションバーに表示された URL はまったく同一なのに。Windows だからかもしれませんけど。

あと、http://www.dotup.org/ のようなアップローダでは、もともとアップされる画像の中に意図的あるいは単純ミスによって、本来の画像形式とは異なる拡張子が付いていることがあります（例：ほんとは PNG 形式なのに .JPG の拡張子がついているなど）。
この場合、Firefox 上では普通に表示されていても、ダウンロードしたファイルを画像ソフト（ビューア）で正しく開けないケースがあります。
Windows の場合ですと、拡張子と実際の画像形式の不一致をチェックしてくれるビューアなら開くときに自動修正してくれるんですが、そういう機能がなく単純に拡張子を信じて開こうとして失敗するビューアもありますから。（Mac の場合は、拡張子ではなくファイルタイプ＋クリエータでしょうか？）
画像ファイルは落とせているみたいだが、ローカルのビューアで正しく開けないという場合には、このようなケースもまれにあるってことで...。

以下、勝手な想像によるたわごとですが、Safari では問題なしというのは、その画像を開いたときに Safari が認識したファイルタイプで保存するが、Firefox はサーバーが送ってきた MIME Type を信用してファイルタイプを保存するので、実際のファイル形式と Mac のファイルタイプに不一致が生じ、ビューアによっては正しく開けない...ということなのでしょうか？？
流れの早いアップローダでは、ブラウザ上では直前に見たキャッシュで見えていても、実データはすでに消えていて、ダウンロードできないということもありますし...。たまにキャッシュをクリアするのではなく、キャッシュを全て無効にして試してみても同様なのでしょうか？？

なんだか問題解決とは程遠い駄文なのに長話になってすみません。

一応他のブラウザでも実行して見た。
新規profileでの3.5.1は前者は駄目で、後者が破損ファイル扱い。
safari4.0(530.17)では両方成功。
opera9.64(10487)では何故かインターネットショートカット化してる。
然もブラウザ上の表示として・・・
「http://appulo.us/appdb/appimages/screenshots/322186427screen.jpg」
は青い背景に２０Qmindreaderのタイトル画像なのに、黒背景の「Appulo.us」の画像に変更されてる。
google_chrome2.0.172.31では両方成功。

訳が解らなく成って来た（汗

_________________

＊Windows 10 21H1 64bit/＊GoogleJapaneseInput：ATOK2017：MS-IME
Firefox 95.0：Beta 96：Developer Edition 96：Nightly 97.0a1：
Thunderbird 91.4.0：Earlybird 96：Daily 97.0a1：SeaMonkey 2.53.10/2.58a1：
Opera 82.0.4227.23：Google Chrome 96.0.4664.93/98.0.4756.0（Official Build）canary：
SRWare Iron 96.0.4900.0：Lunascape 6.15.2：Avant Ultimate 2020 build 3, 3.17.2020

＞偶然的通行人さま

お世話になります！！

やはり、Firefox 3.5.1 + Windows XP SP3の組み合わせは問題ないですかー。

Vistaはaidesさましかご報告ないのですが、今のところダメだということで
私の環境のFirefox3.5.1 + OSX10.5.7も私しかいないのでなんともですがダメですね・・・。


> http://appulo.us/appdb/ のほうは、ちょっと不可解なことがあります。

の件ですが、先程、先日の記事に追記したのですが、最初にアクセスしたときにはゲーム画面なのですが
画像がPNGだとご指摘戴いたときに同じURLにアクセスすると、仰るとおり黒地に白と青の Appulo.us の文字画面になってしまいます。
ただ、そのURLをSafariでアクセスすると、元のゲーム画面が表示されます。
なので、偶然的通行人さまと同じ状況ですので、Windows XPだからではないですねー。


> あと、http://www.dotup.org/ のようなアップローダでは、もともとアップされる画像の中に意図的あるいは単純ミスによって、本来の画像形式とは異なる拡張子が付いていることがあります（例：ほんとは PNG 形式なのに .JPG の拡張子がついているなど）。

の件ですが、たしかにそういうことはあると思うのですが、Macの場合、元々画像であれば拡張子を他の画像系の拡張子に換えたとしても普通に見られますし
今回の場合、そのことでは無いような気がします。

というのも、これはここにポストしてからあさまからご教授戴いて気づいたのですが
D&Dで保存した閲覧できない画像は右クリックで保存ではJpegやPNGであっても
D&Dで保存するとGzipで圧縮されたファイルになってしまうからです。
さすがに圧縮データですので、解凍して中身を取り出すか、自己解凍機能がないビュワーではそのままでは見ることが出来ません。

しかも、aidesさまも同じ状況だとご報告戴けて、これは私だけの環境かと思っていたのですがそうでもないみたいですし、OSの問題でもなさそうですし
なので、何故Firefoxだけそのような仕様になっているのか、そしてその解決法はどうすればいいのかが分かればとてもすっきりするのですが・・・。

＞aidesさま

お世話になっております！！

同じく新規Profile、セーフモードで試してみてもFirefox3.5.1は破損ファイル扱いになります。
Safari4.0.2では問題なくD&Dでも閲覧出来ます。

そして何故破損ファイルになるかというと、D&Dで保存した画像は.jpgになっているのですが
実際はGzip圧縮されたファイルとなっているからです。

ですので、そのファイルの拡張子を.gzにし、解凍ソフトで中身を取り出してそのデータの拡張子を再度.jpgにすると元画像を見ることが出来ました。

お手数ですが、Windowsで同じようにするとどうなるかお試しいただけますでしょうか？

拡張子変更して展開実行するとエラーでした。
Lhaplusと7-Zipでの結果です。
（共にgz展開可能。）
そして前回とは違い全ての画像はAppulo.usに成る。
（safari、Opera問わず。）
そして両方共にD&Dすると「png」に成る。
フォトギャラリーとi_view32では、前者は共に破損で、後者は正常。
ペイントでの確認は破損して居らず。
322186427screen.png：4.07 KB (4,169 バイト)
303442216screen.png：4.07 KB (4,169 バイト)
益々混乱です（汗

_________________

＊Windows 10 21H1 64bit/＊GoogleJapaneseInput：ATOK2017：MS-IME
Firefox 95.0：Beta 96：Developer Edition 96：Nightly 97.0a1：
Thunderbird 91.4.0：Earlybird 96：Daily 97.0a1：SeaMonkey 2.53.10/2.58a1：
Opera 82.0.4227.23：Google Chrome 96.0.4664.93/98.0.4756.0（Official Build）canary：
SRWare Iron 96.0.4900.0：Lunascape 6.15.2：Avant Ultimate 2020 build 3, 3.17.2020

＞aidesさま

ご返信有難うございました！！

そうですかー、Windowsでは解凍出来ないのですね・・・。
再度私の方でも322186427screen.jpgと303442216screen.jpgを試してみましたが
やはり解凍すると問題なく見ることが出来ました。D&DでもPNGにはなりませんでした。


> フォトギャラリーとi_view32では、前者は共に破損で、後者は正常。
> ペイントでの確認は破損して居らず。

うーん、ペイントでは問題なく見ることが出来るということですか？
それなら、やはり圧縮ファイルとしてなっていないのかもしれませんね・・・。

どうしよう・・・。（笑）


[追記]
今、322186427screen.jpgと303442216screen.jpgを見てみると、PNGになっていました。これはサーバ側の問題でしょうかね・・・。

Windows 2000 Professional SP4 / Firefox 3.5.1 で改めて確認してみました。
結果、 http://www.dotup.org/ および http://appulo.us/ のどちらの画像も
デスクトップに Drag & Drop し、閲覧もできました。


この件に関して wget を使ってダウンロードテストをしてみたところ、

• Referer なし
• Referer: http://appulo.us/
  → (たぶん)アップされたそれぞれの画像 (3DCGのPK場面や「AT&T 3G 9:20 PM」)
• Referer: http://forums.mozillazine.jp/viewtopic.php?p=28577
  → Appulo.us の黒背景のPNGイメージ

となりました。
おそらく appulo.us の運営者が他サイトからの画像ファイルへの直リンクを嫌って
このように設定されているのでしょう。

Firefox では、このページに貼られたリンクを辿らずに、画像URLを直接アドレスバーに
貼り付けて表示し、ダメ押しで Shift キーを押しながら[更新]すれば
Appulo.us の黒背景のPNGイメージにならずに済むようです。


とのことですが、それならば(場当たり的ですが)Gzipエンコードを受け付けないように
設定してみたら解決するでしょうか?
about:config で network.http.accept-encoding を空文字列にすれば
Gzipエンコードされることなく画像ファイルがダウンロードできると思います。
(当方ではこれで問題なくD&Dおよび閲覧できます……が、Gzipエンコードされていた場合でも
問題が再現していないので、これが妥当な解法か判断できないのです)

＞ゅゅちょさま

お世話になっております！！

す、凄い！！
about:config で network.http.accept-encodingの値をnullにしたところ
http://www.dotup.org/にある画像
http://appulo.us/appdb/appimages/screen ... screen.jpgや
http://appulo.us/appdb/appimages/screen ... screen.jpgも
D&Dで見ることが出来ました！！

ちなみに、network.http.accept-encodingの値をdeflateだけにしたところ
http://www.dotup.org/にある画像はD&Dで見ることが出来ましたが
http://appulo.us/appdb/の方は見られませんでした。

とりあえず、gzip,deflateはこのまま外しておこうと思うのですが
これを外したことによって、なにかしら影響が出そうなことがありますでしょうか？
圧縮されなくなるから、回線速度が遅い場合は厳しくなるという感じでしょうか？

とにかく、D&Dで保存し閲覧が出来まして、本当に有難うございました！！


[p.s.] aidesさま、一度お試しになって、ご報告戴けると幸いです。

• 隠し設定をいじることになりますので、通常であれば遭遇しなかったであろうバグに遭遇してしまう可能性がないとは言い切れませんのでご承知おきください。
• データ転送量が多くなりますので、サーバの管理者等には嫌われるかもしれません。だからといって即どうこうということは無いと思いますが。

確認が取れました。
一応は質問者の希望の挙動が可能な様子。
取敢えずは問題解決なのかな？
でもabout:config絡みだから「根本的」では無い気も（汗

私は右クリかファイルからの保存なので、今回は参考程度でしか発言出来ませんでした。
済みません。

_________________

＊Windows 10 21H1 64bit/＊GoogleJapaneseInput：ATOK2017：MS-IME
Firefox 95.0：Beta 96：Developer Edition 96：Nightly 97.0a1：
Thunderbird 91.4.0：Earlybird 96：Daily 97.0a1：SeaMonkey 2.53.10/2.58a1：
Opera 82.0.4227.23：Google Chrome 96.0.4664.93/98.0.4756.0（Official Build）canary：
SRWare Iron 96.0.4900.0：Lunascape 6.15.2：Avant Ultimate 2020 build 3, 3.17.2020

＞あさま

お世話になっております！！


> 隠し設定をいじることになりますので、通常であれば遭遇しなかったであろうバグに遭遇してしまう可能性がないとは言い切れませんのでご承知おきください。
> データ転送量が多くなりますので、サーバの管理者等には嫌われるかもしれません。だからといって即どうこうということは無いと思いますが。

なるほどですね、転送量が多くなるから、サーバ側に負担がかかるということですね。
あと、隠し設定の件は、なにか問題があったら元に戻して試してみるというのを忘れないようにメモっておきます。有難うございました！！

＞aidesさま

お世話になっております！！


> 確認が取れました。
> 一応は質問者の希望の挙動が可能な様子。
> でもabout:config絡みだから「根本的」では無い気も（汗

Windows VISTAでも解決しましたかー。
とりあえずはabout:configをいじることになりましたが、私がポストした問題は解決しました！！

ただ、いくつか疑問点が残っております・・・。

・他のブラウザでは同じサーバにアクセスしてもこの問題が発生しない（Operaは例外？）
・about:configを使って、ノーマルの設定からいわば「裏」設定をしないと解決しないというのはデフォルトに問題を抱えているのではないか？
・デフォルトでも問題ない人も存在する（今のところWindows XP/2000+3.5.1の人は問題なし）
・問題のある人でも画像を右クリックで保存なら問題なく保存・閲覧が出来る

もしかしたら、これらの解決策は開発者の方しか解決出来ないのかもしれませんね。
バグなのかなんなのか良く分かりませんし・・・。


> 私は右クリかファイルからの保存なので、今回は参考程度でしか発言出来ませんでした。

いえいえ、本当に貴重な書き込みを戴きまして有難うございました。
特に私固有の問題ではないというご報告やいろいろテスト戴いたことはとても感謝しています。

とりあえず、この場をお借りしまして、ご協力戴きました皆さまに御礼を申し上げます。
有難うございました！！

ネットワーク環境の貧弱なサーバーで提供されているサイトでは、
Accept-Encoding: gzip 等の指定のないリクエストは全て
「gzip エンコードに対応したモダンブラウザ(笑)で御閲覧願います」
のようなページに転送してしまう……なんてことも極々々々稀には
無きにしも非ずと言えなくもないような気がしたりしなかったり……?


まぁ、場当たり的ですよね。


私も右クリックやページの情報を表示＞メディア＞画像を選択＞名前をつけて保存等なので
D&D でデスクトップに保存できることも今回初めて知りました。
普段は Firefox を最大表示しているので Firefox の外に Drop するという発想が
そもそも無かったです ;-P


環境に依って再現する Firefox のバグっぽいですよね。
about:config をいじらずに問題解決できれば万々歳なのですけど。

なお、KNOPPIX 6.0.1 + Firefox 3.5.1 でどうなるか試してみましたが、
この環境ではデスクトップへの D&D はサポートされていないのか、
何度か繰り返し画像を D&D してもデスクトップには何も
保存されませんでした。
更に何度か繰り返したら Firefox が堕ちてしまいました(愕
役に立たない追加情報ですみません。

＞ゅゅちょさま

お世話になっております！！


> Accept-Encoding: gzip 等の指定のないリクエストは全て
> 「gzip エンコードに対応したモダンブラウザ(笑)で御閲覧願います」
> のようなページに転送してしまう……

そのようなこともあるのですね。アクセス出来ないサイトが出てきたなら
元の設定に戻せば良いのですよね？


> 私も右クリックやページの情報を表示＞メディア＞画像を選択＞名前をつけて保存等なので
> D&D でデスクトップに保存できることも今回初めて知りました。

私の環境は2画面なので、片方の画面にブラウザを最大にし、片方で作業する感じですので
簡単にD&Dすることが出来ますので、画像右クリック＞別名で保存＞保存フォルダ移動＞保存
という手間がとても面倒でした。（まあ、毎日画像を保存するかと言えばそうでもないので、ただ私の怠慢ですが（笑））


> 環境に依って再現する Firefox のバグっぽいですよね。
> about:config をいじらずに問題解決できれば万々歳なのですけど。

そうですよねー、新規プロファイル、セーフブート、キャッシュクリア等々を行っても
再現されるので、たぶん潜在的なバグなのかと思うのですが、この報告は開発者にポストした方が良いのでしょうか？英語が出来ないところは汗ですが・・・。


> なお、KNOPPIX 6.0.1 + Firefox 3.5.1 でどうなるか試してみましたが、
> この環境ではデスクトップへの D&D はサポートされていないのか、
> 何度か繰り返し画像を D&D してもデスクトップには何も
> 保存されませんでした。
> 更に何度か繰り返したら Firefox が堕ちてしまいました(愕

新しい情報を有難うございます！D&Dを繰り返すとFirefoxが落ちるって
もしかしたら、描画エンジンまわりとかエンコード・デコード関係のコードに
バグを持っているのかもしれませんよねー。改善して欲しいです！！


> 役に立たない追加情報ですみません。

とても有益な情報だと思います！！
たしかに、通常の方法では解決出来ませんでしたが、当初の目的は果たせましたので
本当に助かりましたし、勉強にもなりました。
こちらにポストして戴いた皆さまにはとても感謝しております！！

ぼくもいろいろ勉強になりました。みなさんありがとうございます。


これ、ぼくもまったく同様です。モニタが小さいので Firefox はいつも最大表示なもので。

それで、今回のことでひとつ疑問が残っています。初歩的なことかもしれないんですけど。

そもそも、ブラウザでは画像が正常に表示できていたということは、そのデータをローカルのメモリなりディスクなりに問題なく取り込めているということですよね？　その画像をデスクトップに保存する場合、メモリキャッシュやディスクキャッシュにあるデータを利用するのでしょうか。それとも、もう一度サーバーにリクエストを出してデータを持ってくるんでしょうか。
また、Firefox の保存に関する操作で、「右クリック -> 名前を付けて画像を保存」と「画像の D & D」では、保存のプロセスが異なったりするのでしょうか？

network.http.accept-encoding の値から gzip と deflate を外すことで、当該サイトの画像を D & D でデスクトップに保存できるようになった経過から考えると、D & D ではもう一度サーバーにリクエストを出しているような気もしますし...。あるいは、最初にブラウザで画像を要求した段階で、非圧縮の生データで取り込んでいると D & D 可能ということなら、圧縮データのデコードに（少なくとも Mac 版 Firefox が）何か問題を抱えているようにも思えますし...。
ブラウザに表示された画像をコピーするときなどは、おそらくすでに取り込まれたデータを利用しているように思える（あくまで「思える」）のですが、それと比較して今回の事例では上述のあたりに何か問題のヒントが隠されてはいないのかな、と...。

まったく的外れなド素人のたわごとでしたら、どうぞ無視してください。