495196 - Drag / drop results in corrupted image on Mac OS X - expires / gzip headers not correct interpreted on MACOSX

Status: RESOLVED DUPLICATE of bug 510670

(Core :: Networking: HTTP, defect)

Description

[Reindl Harald]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.0.10) Gecko/2009042708 Fedora/3.0.10-1.fc10 Firefox/3.0.10
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.10) Gecko/2009042315 Firefox/3.0.10

We have changed two things on our webserver:
* mod_expires: 30 minutes for css-files
* mod_deflate: Also for images

If you download a image from the page with drag&drop under macosx the image is broken, with context-menu its ok. Seems there will be saved the compressed one in this case. Wrong handling from cache or downloading again directly from the server without decompress - Not sure what happens but it fails every time on different machines

If you change the css-file since mod_exipres is active its very strange. Somethimes it seems even "clear cache" will not work sometimes AND wath makes us crazy is that it happens that one url uses the old and another one the new css-file. This MUST NOT happen - If the css is referenced as external file you can have a cached version or the new one but never differnet versions for different pages based on the same template and css-reference. If you are working together with people on osx on a page this hurts

This affects only the macosx-version and i wondered yesterday on my linux machine why our ceo is crying loud the whole time while i can not reproduce even in a windows-vm. Please take a look a this before he gets crazy

Reproducible: Always

Steps to Reproduce:
Drag&Drop a image to the desktop and try to open with photoshop after that

Change a css-file many times while working on layout changes and look what different versions are used on different subpages
Actual Results:  
Mac OSX-Users working together with linux-users gets confused

Expected Results:  
Get unbroken images and use the latest css-version after reload on every subpage independent if you have the page in cache or not because also the cached page have to use only one version of a url-based stylesheet

Comment 1

[Mike Polo]

also have found this from time to time on random web pages
with firefox mac.

here's a reproducible test case (lame image, I know):

http://imgur.com/2EgEQ.jpg

  $ file 2EgEQ.jpg 
  2EgEQ.jpg: gzip compressed data, from Unix

If I save the image to the desktop using "File -> Save page as..."
then the image is saved correctly:

  $ file 2EgEQ.jpg 
  2EgEQ.jpg: JPEG image data, JFIF standard 1.02

You can correct the image (there are any number of
ways):

$ mv 2EgEQ.jpg 2EgEQ.jpg.zip
$ open 2EgEQ.jpg.zip
(2EgEQ.jpg is fixed)

Comment 2

[Reindl Harald]

What happens here?
No response after nearly two months

But for idiotic discussions is time?
https://bugzilla.mozilla.org/show_bug.cgi?id=404661#c81

Instead a long discussion after such an idiotic "bugreport" really errors
should removed dmaned: https://bugzilla.mozilla.org/show_bug.cgi?id=495196

3.5 has a "little" caching problem ALSO on linux
After "clear cache" and reload most time NOTHING happens and after a secornd
reload the page refreshs

What is so really difficult on "clear cache" and "reload"
There is no need to SHIFT+Reload and such ****
If a user clicks at reload he means reload, the whole page and all linked
contents


FIX BUGS INSTEAD MAKE THE BROWSER MORE UNUSEABLE WITH EACH RELEASE
* Caching / Reload killed
* Web-Apps have a useless adressbar - open with "location=off" means this!
* Get window focus is disabled since some realeases: Damned if i use dialogs ina webapp and always use the same window-name to prevent thousands of windows it loads the new url but is behind other windows - for normal users this is a no-go-area but you think its coll to disable every useful option and enable things that are not needed
* The "awesome bar" is **** showing anything instead history entries beginning with input - If i type "www.ca" and there is a url which exactly begins with this string there is NO REASON to show anyhing alse first in history

Comment 3

[Reindl Harald]

Congratulations - Caching/Clear-Cache in FF 3.5 is completly unuseable

If a CSS has a expires header with EVERY RELOAD i get one of the last three versions, every reload another one

WHERE is "clear cache" hidden in the menus?
Under "extras" there is only "private mode"

Damned why do you cut with every release options from the browser to make it only useable for idiots who do nothing really and make it uneusable step by step for developers?

are you arrogant to think your marketshare is big enough to make the same mistakes as microsoft? WHAT is the problem to use the http-headers from the server and reload if the user clicks on reload?

I know that i am not friendly, but i see no reason for be friendly if a developer KILLS BASIC FUNCTIONS in a webbrowser like cache-handling and http-header-interpretation (expires, cache, etag, gzip....) and damned NOBODY make a response - Look at the date of my inital burgreport and THEN look at the date when i got angry!

Comment 4

[Reindl Harald]

Jokingly?

> Changes submitted for bug 495196
> Excluding: [e-mail]
> QA Contact: [e-mail]

The QA-Contact is excluded, nobody is assigned
Cool, and so we wait if you damage the next things in newer releases instead fix existing bugs after nearly two months? 

Should i turn of every caching headers on every server for get a normal workflow? 

Even with DISABLED CACHE this browser does not reload as it should any longer

Comment 5

[Nochum Sossonko [:Natch]]

Reporter: your report is based on an older version of Firefox, please try this again on the latest development version, ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central/ , and let us know if it still is problematic. When you do comment next, please include your user-agent string, located in Help::About Minefield.

Also, please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html as some of your comments seem to be demanding, not in tune with what's expected on a bug report.

Finding a regression-range can definitely help resolve this issue, see http://new.quality.mozilla.org/projects/finding-regression-windows for help with that. I also see no confirmations of this report on any os other than MAC OSX, so I'm adjusting the platform/os fields appropriately.

Comment 6

[Mike Polo]

my example (from comment #1) does not occur with firefox 3.5.2

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

Comment 7

[Reindl Harald]

Drag&Drop Problem on the machine from one of my co-workers occurs with FF 3.5.2 on apple too - For me as KDE-User on Linux Drag&Drop never worked 

The caching problems are since 3.5 on linux too and this could be a suicide-reason for web-developers :-(

Comment 8

[Nochum Sossonko [:Natch]]

(In reply to comment #6)
Thank you for that.

(In reply to comment #7)
Have you checked the _latest_ version of Firefox as indicated in comment 5? Nothing in your comment indicates that you did.

See also bug 437376, which this might be a dupe of. Again, finding a regression range would *really* help here.

Henrik, can you test this on a Mac?

Comment 9

[Reindl Harald]

3.5.2 is the latest and yes the user has 3.5.2 and since 3.5 (i have ALWAYS the latest build) the caching-problems are also on linux and in a terrible way that no-caching-headers also ignored and "clear private data -> cache" from webdeveloper-toolbar is also silently ignored - its like a pokergame what versions firefox will show

Comment 10

[Nochum Sossonko [:Natch]]

Ok, so this seems to be a Networking issue, D&D being just a symptom.

3.5.2 is the latest realease version, I asked you in comment 5 to check the latest developer version (a new one comes out every night, known as the "nightlies"), and its version number is 3.7a1pre currently. Please see that link in comment 5 and try it out, it might be fixed already.

Do you mean that your browser cache is *not* cleared when you use "Clear Recent History" and select "cache" (make sure you select "Everything" in the drop-down menu, otherwise it will only clear a certain amount of time as indicated in the drop-down).

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Reindl, please calm down and obey https://bugzilla.mozilla.org/page.cgi?id=etiquette.html. It's a bug tracking system yes but not each component is followed the same way. Some have lesser listeners. You simply filed it into the wrong component. And 3 months aren't an indicator through. There are a couple of other bugs which are more important to fix. So please let us keep this going forward in a friendly manner.

To be able to do any tests I would need some clear steps. It would be great when you can give us those so we can reproduce it.

Comment 12

[Jo Hermans]

bug 510670 ?

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Looks like, yes.