Closing plugin's context menu doesn't restart drawing

NEW
Assigned to

Status

()

P3
normal
11 years ago
11 years ago

People

(Reporter: alanliu, Assigned: smichaud)

Tracking

unspecified
x86
macOS
Points:
---
Bug Flags:
wanted1.9.1 +
wanted1.9.0.x +

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 years ago
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?
(Reporter)

Comment 2

11 years ago
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.
(Reporter)

Comment 5

11 years ago
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.
(Reporter)

Comment 6

11 years ago
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.
Flags: wanted1.9.1?
Flags: wanted1.9.0.x?
Priority: -- → P3
(Assignee)

Updated

11 years ago
Assignee: nobody → smichaud
Flags: wanted1.9.0.x? → wanted1.9.0.x+

Updated

11 years ago
Flags: wanted1.9.1? → wanted1.9.1+
You need to log in before you can comment on or make changes to this bug.