User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_7; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.204 Safari/534.16 Build Identifier: 4.0 The page sits there while the file is downloaded. The quicktime object isn't instantiated until the download finishes so trying to utilize the JS interface is impossible. This used to perform as expected in FF 3.6.x. Reproducible: Always Steps to Reproduce: 1. Load the page 2. Check firebug/net panel 3. Wait until the file loads, then the video will play. Actual Results: The QT player does not actually appear on the page and is inaccessible via the javascript api until the entire video is downloaded. Expected Results: The QT object should load and progressivly play the video as it's being downloaded. Which is the behavior under FF 3.6.x. Support tickets have been filed, but no actual bugs as far as I know. I am running with plugins installed, I've tried disabling them all and I still get the issue. https://support.mozilla.com/my/questions/799395 https://support.mozilla.com/en-US/questions/798373

My actual user agent, I had it switched. Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0) Gecko/20100101 Firefox/4.0

This issue is reproducible on other browser so in my opinion this is site related.

Which browsers? Can you be more descriptive please? (In reply to comment #2) > This issue is reproducible on other browser so in my opinion this is site > related.

I have used Chrome and Opera with the same result. The player does not appear until the clip is loaded

Tested in Opera and I don't see that behavior. Chrome will load the quicktime object but wait until the file has completed to play. The difference is that the object is accesible. Regardless this is a regression in Firefox and has nothing to do with any other browser.

confirmed that QT object does not load and video does not play progressively this is a regression from 3.6.x video also starts immediately and plays progressively in Safari 5.0.3 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 MacOS 10.6.6 safe mode QuickTime Plug-in 7.6.6 installed launched in 32-bit mode there is something definitely different with the QuickTime plugin in 4.x see also bug 644253, bug 643802, bug 647508

Reporter, do you have anything new to add about this issue?

I've been working around the issue with a flash fallback which is not preferred. Just tested in 4.0.1 and I'm still experiencing the same behavior.

Reporter, does the issue is still present in Firefox 5?

I can confirm this still exists on Firefox 5, but appears to be Mac only Windows XP SP3 Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0 QuickTime plugin File: npqtplugin5.dll Version: 7.4.5.67 Fresh install and fresh profile Results: video loads and begins progressive streaming immediately MacOS X, 10.6.6 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20100101 Firefox/5.0 64-bit mode QuickTime Plug-in 7.6.6 fresh testing profile Results: video does not progressively stream. Once the video has loaded, 100 pixels or so at the top of the video is masked out in white. See bug 654432 Additional test MacOS X, 10.6.6 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 Results: video loads and begins progressive streaming immediately

Interestingly, I can reproduce this bug on OS X 10.6.8 (using FF 5) but not on OS X 10.5.8. I also get *very* bad behavior testing with FF 3.6.18 on OS X 10.6.8 -- the video flashes occasionally but is mostly blank, and FF-plus-Quicktime eats virtually all CPU cycles (usually requiring a force quit). This is on a very fast machine (a brand new MacBook Pro). There aren't any problems on OS X 10.5.8. So this may be at least partly an OS bug. I wonder if changing the values of some of your EMBED tag attributes might make a difference -- things like enablejavascript, controller, scale, postdomevents and autoplay. Please try this out and let us know your results.

I can also reproduce this bug on OS X 10.7 (I tested with FF 5 on the latest Lion DP, which is build 11A494a). But on 10.7 I don't get the terrible behavior in FF 3.6.18 that I described in comment #11 (I also don't see this bug in FF 3.6.18). I also found another symptom: In FF 5 on both OS X 10.6.8 and 10.7, you can't replay this bug's testcase until you explicitly clear the network cache (Firefox : Preferences : Advanced : Network : Clear Now). Even quitting the browser and restarting it isn't enough.

I've found out what's different about OS X 10.6.X and 10.7 -- they both have a newer QuickTime player and plugin -- something called QuickTime X (http://developer.apple.com/technologies/mac/snowleopard/quicktimex.html). So this bug (and its friends) may be a bug in QuickTime X, or a bad interaction between Firefox and QuickTime X.

As the previous commenters have stated this is still an issue with FF5. I'm running OSX 10.6.8. I have not tested on Windows yet. UA: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20100101 Firefox/5.0

Is QuickTime X available for Windows?

> Is QuickTime X available for Windows? As best I can tell, it isn't.

QuickTime X may be not really be the issue. It's not clear that the introduction of QuickTime X has an effect on the QuickTime plugin (at least in 10.6). I don't have a 10.5 machine to check but take a look about:plugins for the plugin version. I checked a 10.4 machine and the version number is 7.6. On 10.6 I have version 7.6.6. In any case there still does appear to be an issue with FF 4 and FF 5 since progressive playback does work in FF 3.

All the evidence currently points to this being a QuickTime X issue. It's apparently true that Apple uses the same numbering system for both "QuickTime" and "QuickTime X". But they do consider "QuickTime X" to be a different beast. Which isn't to say that we can't do anything about this bug. Just that it appears to be a bad interaction with QuickTime X.

Testing on OS X 10.7 (where I don't see such terrible performance in older code, as found in FF 3.6.X), I've found the following regression range for this bug (it starts happening with the second of these two nightlies): firefox-2010-03-23-03-mozilla-central firefox-2010-03-24-03-mozilla-central The likeliest trigger for this bug in that range is: Add support for the NPAPI Core Animation drawing model. b=497225 r=josh sr=roc author Benoit Girard <bgirard@mozilla.com> Tue Mar 23 20:51:11 2010 -0400 (at Tue Mar 23 20:51:11 2010 -0400) changeset 39757 e687f97bbb6e Benoit, do you know if the QuickTime X plugin tries to use the Core Animation drawing model?

I will take a look in a moment. My guess is that the plugin using CoreAnimation and not InvalidatingCoreAnimation. The difference between the first and the second model is that with the second we receive paint notification, with the first drawing model we paint have no choice to paint continuously. If my guess turns out to be right we might have to contact Quicktime. We have discussed deprecating support for CoreAnimation without the invalidation event for performance reasons.

(In reply to comment #5) > Regardless this is a regression > in Firefox and has nothing to do with any other browser. That's possible but not necessarily the case. The plugin and browser work with different drawing models so it's possible that it's a plugin regression as well as a browser regression. (In reply to comment #19) > Benoit, do you know if the QuickTime X plugin tries to use the Core > Animation drawing model? It is using InvalidatinCoreAnimation however the plugin is spamming invalidate event continuously regardless if the content is changing or not. That account for wasted CPU cycles but I'm not sure why it fails to draw during buffering. Set for logging: NSPR_LOG_MODULES=Plugin:5,PluginNPP:5,PluginNPN:5,IPCPlugins:5

I'm marking this bug as WONTFIX per bug #1269807. For more information see - https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/