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: