When the context menu is invoked (through right-clicking) on a Silverlight site, the rendering stops because the menu is active. Once you click away from the menu, the rendering should resume. However, Firefox is not sending Silverlight paint notifications and as a result, nothing is displayed on the screen. This is fixed by left-clicking anywhere whereby Silverlight receives paint notifications again. Steps to reproduce the problem: - Navigate to http://www.nbcolympics.com/video/ - Install Silverlight 2 beta 2 when prompted - Restart browser, navigate back to http://www.nbcolympics.com/video/ - Right click on Silverlight portion, the content should stop rendering - Left click anywhere to deactivate menu, content should start rendering again -- But it doesn't. - Left click onto the Silverlight portion, content begins to render again
> - Right click on Silverlight portion, Where is this?
My bad, you have to click on any of the video before the Silverlight content shows up.
What I see (in FF3 on both OS X and Windows) is actually much more severe than what you report, and this makes it very difficult to isolate the symptoms you do report. To reduce the complexity, I concentrated my tests on just one video ("Speaking with Julie Ertel"). As you say, you don't see any Silverlight content until you click on the "play symbol" button in a video's thumbnail. Once you do that, a new window opens up with the Silverlight content in its upper left. As best I can tell, the Silverlight content is supposed to function as follows (and actually does so in Safari (on OS X) and FF2 (on OS X and Windows)): 1) Once the Silverlight content finishes loading, the video starts to play "automatically" (after a few seconds delay). 2) The first part of the "show" is a short (~30 seconds) teaser, which appears to be randomly chosen (from a list of six or seven). 3) Once the teaser finishes, the "main event" also starts to play "automatically" (again after a few seconds delay). But in FF3 (or 3.0.1), a teaser starts up, then aborts after a few seconds. Then a second teaser starts up and aborts. This continues on for five or six teasers (possibly all that are available). Finally the main show starts (the video of Julie Ertel). But often there's no display -- only sound. Additionally, on Windows (and not on OS X) both FF3 and FF2 become partially non-responsive when you close the video window, and often have to be force-quit (using the Task Manager). These problems are so severe, and so deep, that Silverlight bugs must be involved (in addition to whatever Firefox bugs may be involved). (All my tests were done with Silverlight 2 Beta 2.)
Forgot to mention that I tested on OS X 10.5.4 and Windows XP SP3.
Microsoft released an update to Silverlight 2 beta 2 today to address all those issues. It should either auto update to the latest version, or you can go to www.silverlight.net to get the latest one. Sorry for the confusion.
Quick note: it doesn't auto update for now. You have to go to www.silverlight.net to get the latest one.
OK, I've now downloaded and installed Silverlight 2 Beta 2x (for lack of a better name) on OS X and Windows. I can now confirm your report from comment #0 (only on OS X, only in Cocoa-widgets-based browsers), and add a few (puzzling) details. (The Cocoa-widgets-based browsers are FF3, FF3.0.1, 1.9.0-branch Camino and Camino 1.X (aka 1.8-branch Camino).) 1) In all Cocoa-widgets-based Mozilla.org browsers, right-clicking (or ctrl-clicking) on the Silverlight video always replaces the display with a red background. This doesn't happen in other browsers (e.g. FF2 or Safari), so the Silverlight plugin must (I assume) somehow special-case Cocoa-widgets-based browsers. The question is why? It's true that FF2 stops updating plugins whenever a menu is displayed (even a context menu). But this is no longer true for FF3 (since the patches were landed for bug 395397 and bug 389931). You should consider dropping the code that displays the red background. Doing so may make this problem go away. 2) In FF3 (and FF3.0.1 and 1.9.0-branch Camino), your bug (what you reported in comment #0) doesn't happen if the single-item context menu (what you get when you right-click on the Silverlight video) extends outside the view where the video is running. In that case, you only have to left-click once to make the red background disappear and the video's display reappear. In the other case (if the context menu is entirely over the view containing the Silverlight video), you have to left-click twice to make the video's display reappear. I can't explain this. Is there any difference between these two cases in the event stream sent to the plugin (via the NPAPI) by the browser?
> (The Cocoa-widgets-based browsers are FF3, FF3.0.1, 1.9.0-branch > Camino and Camino 1.X (aka 1.8-branch Camino).) Oops, I forgot that 1.9.0-branch SeaMonkey and Thunderbird also use Cocoa Widgets.
(Following up comment #7) > Is there any difference between these two cases in the event stream > sent to the plugin (via the NPAPI) by the browser? I suppose you've already answered this question by what you say in comment #0: > Once you click away from the menu, the rendering should resume. > However, Firefox is not sending Silverlight paint notifications and > as a result, nothing is displayed on the screen. I assume that Firefox fails to send the paint notification only when the context menu is entirely over the view containing the Silverlight video.
As I say in comment #7, it's likely that the Silverlight plugin could avoid this problem by a change in design (getting rid of the red background, since it's probably not needed). But this does appear to be a bug in Firefox, which might effect other plugins. All in all I rate this P3.
Priority: -- → P3
Flags: wanted1.9.0.x? → wanted1.9.0.x+
You need to log in before you can comment on or make changes to this bug.