Closed Bug 116562 Opened 23 years ago Closed 23 years ago

Flash movie is not loaded if disk cache is disabled

Categories

(Core Graveyard :: Plug-ins, defect, P3)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.9

People

(Reporter: vfry, Assigned: gordon)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: patch)

Attachments

(1 file, 1 obsolete file)

patch to return error if storage for policy is not enabled.
886 bytes, patch
gagan
: review+
gordon
: superreview+
Details | Diff | Splinter Review 
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..


Happens to me too. Build 2001122106 on WinME.
Confirming on 2001122208 WinME as well. About to try the latest nightly.
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
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.


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
does this need to be reassigned to 'networking/cache' ?
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
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
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.
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?
same with 2001122108 on Linux
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.
*** Bug 117244 has been marked as a duplicate of this bug. ***
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").

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

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?
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

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. >:(
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).
Confirmed on build 2002012606 on Linux. Changing OS to All.
OS: Windows XP → All
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
I will ry to find out when this happened.
*** Bug 123280 has been marked as a duplicate of this bug. ***
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.
*** Bug 123618 has been marked as a duplicate of this bug. ***
*** Bug 123522 has been marked as a duplicate of this bug. ***
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
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.

*** Bug 123688 has been marked as a duplicate of this bug. ***
*** Bug 123701 has been marked as a duplicate of this bug. ***
*** Bug 116839 has been marked as a duplicate of this bug. ***
Lots of dups with 0.9.8...

-->over to Gordon, owner of bug 110405.
Assignee: peterl → gordon
Status: ASSIGNED → NEW
*** Bug 123965 has been marked as a duplicate of this bug. ***
*** Bug 95096 has been marked as a duplicate of this bug. ***
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
You mean disable the memory cache too? That's not much of a workaround, though...
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
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.
another solution on such shared systems is to set a users cache directory to
something in /tmp or some equivalent local directory.
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?
Yes, unfortunately the plugin interface expects access to a file, not just a
data stream.
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.
nicolas: in a recent nightly build, you can set the cache location via the
preferences panel.  (see Preferences->Advanced->Cache)
How about in release 0.9.8? Is there a way to do that there?
user_pref("browser.cache.disk.parent_directory", "/tmp")

would create a directory called "Cache" for the disk cache in /tmp
Attached patch Patch for type of cache (obsolete) — — Splinter Review 
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.
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...
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?
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?
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!
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?
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.
Keywords: nsbeta1+
*** Bug 117986 has been marked as a duplicate of this bug. ***
Attachment #68938 - Attachment is obsolete: true
Whiteboard: patch
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 on attachment 69591 [details] [diff] [review]
patch to return error if storage for policy is not enabled.

r=gagan
Attachment #69591 - Flags: review+
Patch checked in.  Marking FIXED.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
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 !
Shrir: works for me now.
verified on all trunk builds 0220 (win/mac/linux).
Status: RESOLVED → VERIFIED
*** Bug 126904 has been marked as a duplicate of this bug. ***
*** Bug 127346 has been marked as a duplicate of this bug. ***
*** Bug 127572 has been marked as a duplicate of this bug. ***
*** Bug 89494 has been marked as a duplicate of this bug. ***
*** Bug 129058 has been marked as a duplicate of this bug. ***
*** Bug 130069 has been marked as a duplicate of this bug. ***
*** Bug 126223 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: