Flash movie is not loaded if disk cache is disabled

VERIFIED FIXED in mozilla0.9.9

Status

()

Core
Plug-ins
P3
normal
VERIFIED FIXED
16 years ago
10 years ago

People

(Reporter: Ed Fry, Assigned: gordon)

Tracking

({regression})

Trunk
mozilla0.9.9
x86
All
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: patch, URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.7) Gecko/20011221
BuildID:    2001122106

When loading a Page which uses The Macromedia Flash Plugin, The Plugin will not
load the Flash Animation. Right Clicking on the Flash Animation brings up a Menu
which says "Movie Not Loaded", Which is Greyed out.

Reproducible: Always
Steps to Reproduce:
1.Go to page with Flash Content
2.No Flash Content Displayed
3.Right clicking on Blank box where Flash content should be will reveal a menu
which says "Movie Not Loaded"

Actual Results:  No Flash Content Displayed

Expected Results:  Display Flash Content

Flash Animation loads correctly in Version 0.96, upgrading to version 0.97
causes to Problem, uninstalling and reinstalling 0.97 does not fix the problem.
Reinstalling the Flash Plugin with the newest Version doesn't fix the Problem.
Uninstalling and reinstalling 0.96 Does fix the Problem.

This also Occurs with Windows 2000.
wfm with win2k build 20011222..

Comment 2

16 years ago
Happens to me too. Build 2001122106 on WinME.

Comment 3

16 years ago
Confirming on 2001122208 WinME as well. About to try the latest nightly.

Comment 4

16 years ago
Nope, nothing works. Going back to Mozilla 0.9.6 release (2001112009), which
does work on WinME.

Is there anything I can do to help clear this up? It's very annoying...

BTW: Flash version is 5.0 r41

Comment 5

16 years ago
Ok, found it: Flash will not work if the disk cache is disabled.

For Flash to work, the disk cache must be enabled
(Preferences->Networking->Enable disk cache) and the cache size must not be zero
(Preferences->Advanced->Cache->Disk Cache).

I consider this a bug. I do not use a disk cache as I have a fast proxy server.

Reporter, could you change the Summary to "Flash plugin does not work if Disk
Cache disabled" please? I do not have sufficient privileges to do so.

(Reporter)

Comment 6

16 years ago
Setting the Disk cache to 1kb fixed it on my end.
Summary: Flash Plugin: Movie Not Loaded Error - Will not load Flash → Flash Plugin: Movie Not Loaded Error - Will not load Flash If Disk Cache Disabled

Comment 7

16 years ago
does this need to be reassigned to 'networking/cache' ?

Comment 8

16 years ago
This is a good question, maybe not. Peter, what are we supposed to do if a 
plugin requests a stream as STREAMASFILEONLY and we don't have any local disk 
capabilities? Is it legitimate just to fail? If user disables cache, does it 
mean he wants not to use the disk no matter what?

Maybe we should throw a pop up warning that caching mechanism the plugin relies 
on is disabled and the plugin is not going to work properly.

Changing summary to make it shorter.
Summary: Flash Plugin: Movie Not Loaded Error - Will not load Flash If Disk Cache Disabled → Flash movie is not loaded if cache is disabled

Comment 9

16 years ago
Plugins are simply agents of the Necko cache, we use the same system. If a user
decides to disable the browser cache, plugins do not (and probably shouldn't)
have the authority to override the user's choice. Therefore, if a plugin
requests STREAMASFILEONLY stream, I think it is legitimate that it can fail
becuase the cache is disabled. It's up to Flash to decide how to handle the
error, and in this case, it simply doesn't load anything. It could be made
smarter, like some other plugins.

An argument can be made that plugins should use their own dedicated cache but
there are other problems with that plus I'm more in favor of recycling what
we've already got. Nominating---->Future
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Future
(Reporter)

Comment 10

16 years ago
Shouldn't STREAMASFILEONLY use the memory cache if a file cache is unavalable? 
My current settings is a 16Meg Memory Cache and a 1K Disk cache (for the 
workaround) and it works fine. of course setting the disk cache to 0k causes 
the problem.

If there has to be a Disk cache for compatibility with plugins, Is there a 
setting or could a setting be made for the disk cache to clear itself after 
the browser is closed? (similar to the "Empty Temporary Internet Files when 
browser is closed" option that Internet Explorer has) Not only would this 
option keep the hard disk cleaner and allow a cache to be avalable for plugins 
like flash, but it increases security on multi user systems as well.

Comment 11

16 years ago
No, the way STREAMASFILEONLY works is that we need to pass the plugin a path to
the filesystem. The plugin already does have a way of directly getting the bytes
from the stream without using the disk, but in this case, the plugin is
specifically asking the browser to cache to disk.

Why is the cache a security concern on multi-user systems? The cached files are
loacted with the user's profile in their home directory and security should be
set correct there.

There is one exception where we do not use the Necko cache because it refuses to
do the caching. For HTTPS documents, 4.x honored requests from the plugin to
cache to disk. This is needed for backwords compatibility with Acrobat but I
think updated versions of the plugin for Mozilla don't force writing to disk. In
the case of no cache, we create a folder and use the OS's temp directory. We
also clean up our files when done. 

It's possible we could do the same thing when the cache is disabled?

Comment 12

16 years ago
same with 2001122108 on Linux
(Reporter)

Comment 13

16 years ago
The Security concern I was talking about was on multi user systems Running 
Windows 98 either under a WinNT domain without Roaming User Profiles or no 
login whatsoever. On Those systems, if one user logs in, it uses the default 
user profile, if that person logs off and someone else logs in, it still using 
the default user profile, as well as the cached files with it.

Of course, under that environment, the History would give much of the locations 
of the last user away.

Comment 14

16 years ago
*** Bug 117244 has been marked as a duplicate of this bug. ***

Comment 15

16 years ago
Okay, thanks to Ian, we at Macromedia now know about this problem.  It's 
entered in our own Flash Player bugbase.  Macromedia does not officially 
support Mozilla, but PLEASE let me know if there is going to be a Netscape 
release that will be affected by this, as we would take that seriously.  If we 
know about that in advance, we can bump up the priority of this issue.

I am not personally familiar with the NPAPI (although we have many people here 
who are), so I haven't yet tried to figure out why we're using STREAMASFILEONLY 
or what our alternatives would be - any architectural suggestions appreciated 
(including just "rtfm").

Comment 16

16 years ago
Confirming on BuildID:2002010208 on MacOS9.1-Japanese as well.
Well, I want to add a comment to this bug.  When I uncheck "Enable disk
cache"(Preferences>Debug>Networking), QuickTime plugin doesn't work just like
Flash plugin.  But, MRJ plugin(Java applet) will work if the disk cache is
disabled.  What is the difference between Flash(or QuickTime) and MRJ(Java)? 

QuickTime: http://www.apple.co.jp/quicktime/
Java applet: http://www.hitsuji.to/appletHTML/ColorfulScroll.html

Comment 17

16 years ago
Hmmm, I have an additional question: is this NEW behavior?  That is, do the 
Flash and Quicktime plug-ins work OK in prior builds of Mozilla (and especially 
Navigator 6.x) with the disk cache setting turned off?  If so, then wouldn't it 
be fair to say that this is a back-compatibility breaker?  Even if the new 
behavior is more correct in some way, is that correctness more important than 
supporting existing plug-ins?

Comment 18

16 years ago
I tested four kinds of plug-in.  MRJ plug-in is installed by the default, when
installing Mozilla.  I have copied Shockwave Flash, Shockwave Director and
QuickTime plug-in from Netscape Communicator 4.7.x plug-ins folder to Mozilla
Plug-ins folder.  The result of Mozilla 0.9.6 and 0.9.7(or latest-trunk) was
compared.  It seems that this bug is regression.  The result was as follows.   
I'm sorry I didn't try Netscape Navigator 6.x.

Mozilla 0.9.6(Enable Disk Cache):
Shockwave Flash, Director, QuickTime and MRJ worked.  It seems all plug-in works
fine.

Mozilla 0.9.6(Disable Disk Cache):
All plug-in that I used worked as well as "Enable Disk Cache".

Mozilla 0.9.7(Enable Disk Cache):
Shockwave Flash, QuickTime and MRJ plug-in worked.  But, Shockwave Director
plug-in did not work.  

Mozilla 0.9.7(Disable Disk Cache):
Only MRJ plug-in worked.  Shockwave Flash, Director and QuickTIme plug-in didn't
work.  

Information of plug-in:
Macromedia Shockwave for Director Netscape plug-in, version 8.5r321
Shockwave Flash 5.0 r41
QuickTIme Plug-in 5.0.2
MRJ Plug-in(Java VM: MRJ 2.2.5)

Test page of Shockwave Flash and Director plug-in:
http://www.macromedia.com/jp/shockwave/welcome/main.html

Comment 19

16 years ago
Well please bring the old behavior back. 0.9.6 worked perfectly without disc
cache, this is new and doesn't help anybody. i got lots of memory and a slow
hard drive, so i turned disk cache off. :( no flash and no quicktime for me now?
:( i guess a lot of people stare at a blank screen now where the old version
displayed the plugin correctly, and hadn't i found this bugzilla entry i'd still
install and reinstall different mozilla versions. >:(

Comment 20

16 years ago
I have exactly the same problem with plugger on Linux - plugger would fail to
work (will not pass an empty file name to the helper app) is disk cache is
disabled. Should we set OS to All, or should I file a separate bug for this?

I am currently running BuildID 2002011021 on RedHat Linux 7.2, plugger 4.0
(4.0-4 RPM from RedHat Rawhide).

Comment 21

16 years ago
Confirmed on build 2002012606 on Linux. Changing OS to All.
OS: Windows XP → All

Comment 22

16 years ago
Re-reading the comments, this is a regression between 0.9.6 and 0.9.7. 

..taking bug to investigate why running plugins without a disk cache in 0.9.6
builds worked...

I wish we could go back and pull mozilla builds to find when the regression
happened, but I don't think they go back that far??? However, I think Netscape
Commercial ones DO go back to November:
ftp://sweetlou.mcom.com/products/client/6.x/windows/32bit/x86/
Assignee: av → peterl
Keywords: mozilla0.9.9, regression
Priority: -- → P3
Summary: Flash movie is not loaded if cache is disabled → Flash movie is not loaded if disk cache is disabled
Target Milestone: Future → mozilla0.9.9

Comment 23

16 years ago
I will ry to find out when this happened.

Comment 24

16 years ago
*** Bug 123280 has been marked as a duplicate of this bug. ***

Comment 25

16 years ago
this broke between the dates 1129 and 1130 ( working on 1129 ..stopeed working 
on 1130). This happened after 6.2.1 was released (11/28).  Will try to get this 
into 0.9.8 release notes.

Comment 26

16 years ago
*** Bug 123618 has been marked as a duplicate of this bug. ***

Comment 27

16 years ago
*** Bug 123522 has been marked as a duplicate of this bug. ***

Comment 28

16 years ago
Thanks Shrirang, I love Bonsai! 

Okay, I think I may have found the problem. Backing out attachment #58176 [details] [diff] [review] from
bug 110405 fixes Flash running with a disabled disk cache.

Darin/Gordon, can this be returned to an ASSERTION or is there another workaround?
Status: NEW → ASSIGNED
(Assignee)

Comment 29

16 years ago
Strange.  I presume entry->IsAllowedInMemory() returns FALSE because the entry
has a storage policy of nsICache::STORE_ON_DISK_AS_FILE, so we can pass the file
to the plugin.  What I don't understand is how this could have worked before if
the entry was simply stored in memory.

I'd like to find a better solution than simply changing the condition back to an
assertion.  I'm not familiar with the interaction between plugins and http, however.

Comment 30

16 years ago
*** Bug 123688 has been marked as a duplicate of this bug. ***

Comment 31

16 years ago
*** Bug 123701 has been marked as a duplicate of this bug. ***

Comment 32

16 years ago
*** Bug 116839 has been marked as a duplicate of this bug. ***

Comment 33

16 years ago
Lots of dups with 0.9.8...

-->over to Gordon, owner of bug 110405.

Assignee: peterl → gordon
Status: ASSIGNED → NEW

Comment 34

16 years ago
*** Bug 123965 has been marked as a duplicate of this bug. ***

Comment 35

16 years ago
*** Bug 95096 has been marked as a duplicate of this bug. ***

Comment 36

16 years ago
This *does* work with disabling of the cache and here is how I did it. It's weird.

Simply set *both* caches to zero. It's slow as a snail when on a page that uses
flash but it works.

This is on:
win2k
.98 build 20020204

Comment 37

16 years ago
You mean disable the memory cache too? That's not much of a workaround, though...

Comment 38

16 years ago
Back with Netscape 4.7.x, it was believed that you could speed up the browser's
BACK function by setting the disk cache to zero, forced the page to be redrawn
from the memory cache instead. I have no idea whether this was true or not, but
it was tossed about as a solution to speed problems. This is why I first set the
cache to zero when I started using Mozilla at M1.

If I may suggest a solution as an end user and not a coder: You should not be
able to set the cache to zero. Setting it to zero should return some minimum
value. Maybe even a line of text can be added to the preference box stating the
minimum value.

OR if the cache can be set to zero, a dialog should popup stating it can cause
some plugins not to function.

I do not think it's correct to assume a user sets the cache to zero to
deliberately disable plugins.

I offer these suggestions because I want Mozilla 1.0 to KICK ASS! :)

Thanks,
Michael

Comment 39

16 years ago
What about sides with hundres of users, like in Universitys, having their $HOME
on a shared nfs drive. As a system administrator you don't want every user to
have 50 megabyte of cache in nfs-server:/home/<user>/.mozilla/bla/Cache/.
Running squid as a caching server is the only solution - this is why setting the
disk cache to 0 should work!

Kind regards, Joerg.

Comment 40

16 years ago
another solution on such shared systems is to set a users cache directory to
something in /tmp or some equivalent local directory.

Comment 41

16 years ago
The local/tmp trick only works in a workstation with enough local disk space,
however. This doesn't really resolve the situation in a low space (ie
50MB/machine for boot, nfsmount rest of dir structure) or no space (network card
boot rom) net boot situation. I'd rather see the problem fixed on Mozilla's end
of things, if at all possible.

At the very least, I second the idea that some sort of error dialogue should be
generated if a plugin tries to use STREAMASFILEONLY when disk cache is disabled.
At least then users (and administrators) are aware of the problem and know the
solution immediately. The biggest concern to me right now is that this problem
is easily resolved on the client side, but not easily detectable.

I suppose having a preference option which patches STREAMASFILEONLY to redirect
to the RAM cache is unworkable because of the filesystem i/o involved?
(Assignee)

Comment 42

16 years ago
Yes, unfortunately the plugin interface expects access to a file, not just a
data stream.

Comment 43

16 years ago
How does one set the user's cache directory? Is that some setting in prefs.js?
All I found was something along the lines of browser.cache.directory, but that
didn't work.

Comment 44

16 years ago
nicolas: in a recent nightly build, you can set the cache location via the
preferences panel.  (see Preferences->Advanced->Cache)

Comment 45

16 years ago
How about in release 0.9.8? Is there a way to do that there?

Comment 46

16 years ago
user_pref("browser.cache.disk.parent_directory", "/tmp")

would create a directory called "Cache" for the disk cache in /tmp

Comment 47

16 years ago
Created attachment 68938 [details] [diff] [review]
Patch for type of cache

This patch resolve problem. I just change
    rv = cacheChannel->SetCacheAsFile(PR_TRUE);
to
    rv = cacheChannel->SetCacheAsFile(PR_FALSE);
So, cache policy become STORE_ANYWHERE. This make plugin work with zero cache.
Not sure it's correct. Check it.

Comment 48

16 years ago
ah... looks like plugins have support for SetCacheAsFile failure.

gordon: perhaps we're not returning an error from SetCacheAsFile when the disk
cache is disabled?!?

sergi: that probably isn't the right patch...
(Assignee)

Comment 49

16 years ago
SetCacheAsFile() is only called from nsPluginHostImpl.cpp and nsDownloader.cpp.
 nsPluginHostImpl appears to only use it as an optimization, so if
SetCacheAsFile(PR_TRUE) could return an error if the disk cache was currently
disabled, the existing code would work fine.

However nsDownloader cancels the download if SetCacheAsFile(PR_TRUE) returns and
error.  Maybe we should open a bug for that?

Comment 50

16 years ago
If SetCacheAsFile() from nsPluginHostImpl will return error for zero disk
cache, nsPluginHostImpl will call SetupPluginCacheFile (and create file
in NS_OS_TEMP_DIR. What the reason for plugins to work with files if memory
cache works?

Comment 51

16 years ago
sergi: some plugins require "/path/to/file" and cannot utilize mozilla's memory
cache.

gordon: yeah, but i think fixing nsDownloader is lower priority.  i believe that
it is currently only used for remote jar files, which are currently not used ;-)
but if you could file a bug (and future it) that would be great!

Comment 52

16 years ago
Another administrative question: If more than one user sets their
browser.cache.disk.parent_directory to /tmp then only the browser which created
the /tmp/Cache directory will be able to write to it, since it is created 700
and owned the creating browser process. Can I instead specify something like
/tmp/$USER or something of that sort for parent_directory?

Comment 53

16 years ago
i don't think /tmp/$USER will expand as you'd like it to.  not sure of a good
automatic way to achieve similar effect w/o editing each users prefs.js file.

Updated

16 years ago
Keywords: nsbeta1+

Comment 54

16 years ago
*** Bug 117986 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 55

16 years ago
Created attachment 69591 [details] [diff] [review]
patch to return error if storage for policy is not enabled.
(Assignee)

Updated

16 years ago
Attachment #68938 - Attachment is obsolete: true
(Assignee)

Updated

16 years ago
Whiteboard: patch
(Assignee)

Comment 56

16 years ago
Comment on attachment 69591 [details] [diff] [review]
patch to return error if storage for policy is not enabled.

sr=darin
Attachment #69591 - Flags: superreview+

Comment 57

16 years ago
Comment on attachment 69591 [details] [diff] [review]
patch to return error if storage for policy is not enabled.

r=gagan
Attachment #69591 - Flags: review+
(Assignee)

Comment 58

16 years ago
Patch checked in.  Marking FIXED.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 59

16 years ago
Anybody who has stumbled upon this bug..I kindly request you to pls try this fix 
with today's build and comment in the bug only if you think this is *not* 
working. I will verify this too. Thanks!!
This works for me now :)
Thanks !

Comment 61

16 years ago
Shrir: works for me now.

Comment 62

16 years ago
verified on all trunk builds 0220 (win/mac/linux).
Status: RESOLVED → VERIFIED

Comment 63

16 years ago
*** Bug 126904 has been marked as a duplicate of this bug. ***

Comment 64

16 years ago
*** Bug 127346 has been marked as a duplicate of this bug. ***
*** Bug 127572 has been marked as a duplicate of this bug. ***

Comment 66

16 years ago
*** Bug 89494 has been marked as a duplicate of this bug. ***

Comment 67

16 years ago
*** Bug 129058 has been marked as a duplicate of this bug. ***
*** Bug 130069 has been marked as a duplicate of this bug. ***

Comment 69

16 years ago
*** Bug 126223 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.