510082 - Silverlight 3 plugin elements don't repaint correctly

Status: RESOLVED FIXED

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

Description

[Sylvain Pasche]

Silverlight 3 plugin elements don't repaint themselves. Try to view a video on http://channel9.msdn.com/ for instance, you can hear the sound but the image is frozen. If you force invalidation by minimizing and restoring the window the element is updated.

Tried with Plug-in version 3.0.40723.0.

Another sample with less HTML: http://www.visitmix.com/labs/descry/awebsitenameddesire/

Comment 1

[Leman Bennett [Omega]]

I think this happened when Compositor landed.

I've also had problems interacting with some Silverlight apps since the landing.

Comment 2

[Peter S.]

I was pointed to this bug by 
http://forums.mozillazine.org/viewtopic.php?f=23&t=1444695&p=7357995#p7357995

Text of linked post:
Potential bug at http://tinyurl.com/36nlds

Go to the dropdown menus at the top (Sports, Schedules, etc.)
Right-click one of the options in the menu.

Does the right-click menu appear way higher and to the left of where it should be?

Comment 3

[[not reading bugmail]]

>I was pointed to this bug by 
>http://forums.mozillazine.org/viewtopic.php?f=23&t=1444695&p=7357995#p7357995

Peter: This a Silverlight 3.0 bug, which doesn't update the screen.  The Forum post for what you see is something completely different and unrelated.

Comment 4

[Peter S.]

Ah, sorry.  I was confused by polidobj's post, which pointed to this bug.

Any assistance in pointing me to the proper bug report would be much appreciated.

Comment 5

[Johnny Stenback (:jst)]

Blocking on this regression.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I looked into this. I tried Silverlight 2.0.40115.0 and 3.0.40818.0 on
http://www.visitmix.com/labs/descry/awebsitenameddesire/

I tried to trigger repainting by operating the slider to the left of the "home" button near the top right corner. But NPN_InvalidateRect, NPN_InvalidateRegion and NPN_ForceRedraw just don't seem to be called.

CCing Andy Rivas, who I believe is associated with the Silverlight team ... does Silverlight try to trigger repainting via some method other than NPN_InvalidateRect etc? If so, how? I could easily believe that if they're trying to find the browser's HWND and call InvalidateRect directly, my changes could have broken that. However, that's not what plugins are supposed to do...

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Oh, this testcase uses the plugin in windowed mode, so those functions shouldn't be used. Silly me.

The window is visible; if you force it to repaint, it paints correctly. Using Winspector I can see that it's receiving mouse messages and other messages as expected. It's just not being invalidated correctly for some reason. I can't figure out why since that doesn't happen in Gecko code. Perhaps someone from Microsoft can help us out here?

Comment 8

[[not reading bugmail]]

Roc, any chance for a fix here?  Maybe Shaver can call em over.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

It's going to be hard to fix without Microsoft help. It may be a Silverlight bug. I'm surprised they're not responding here.

Comment 10

[Andy Rivas]

Robert and others,

I opened a bug on our end and we just completed the investigation yesterday.  We're going to need some help reproing this because we're unable to repro.

What build of XP are you able to repro on?

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

What build of Firefox are you testing? You want to test from here
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.2/
(This will become Firefox 3.6)

and/or here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/
(This will become Firefox > 3.6)

Comment 12

[Andy Rivas]

We were testing against 3.5  I'll get the new build pointer to our test team and we'll get back to you with results.

Comment 13

[Andy Rivas]

We have investigated this issue on our end. To answer a previous query, we are calling the correct NPN_InvalidateRect, NPN_InvalidateRegion and NPN_ForceRedraw api’s. In our investigations we’ve found that we are not getting WM_PAINT messages from the host. As noted in the bug manually invalidating the window by resizing, moving window etc.. causes the WM_PAINT message to get posted for us to handle and render. Currently it appears that this issue is stemming from changes made to in FireFox 3.6.

Please let us know if you need more data for analyzing this issue.

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We have never implemented NPN_InvalidateRegion, so calling that would never have worked in any version of Firefox.

In comment #6 I was testing a windowed plugin instance. Why would you call NPN_InvalidateRect/NPN_InvalidateRegion for a windowed plugin? Those APIs are for windowless instances only. For a windowed instance, you should be calling Win32 InvalidateRect etc on your own window's HWND. Are you?

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Apparently Silverlight does call NPN_InvalidateRect, even when in windowed mode, and expects this to invalidate its window. That's easy for us to ensure, so we'll do that.

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Note that it doesn't really make sense to call NPN_InvalidateRect when you have a window, it's more efficient to just call Win32 InvalidateRect directly. But it's easy enough to support our old behaviour.

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

BTW this patch also fixes a bug on Mac where we were falling through from the "paint normal" case to the "paint solid color" case ... fortunately the default solid color is transparent!

Comment 19

[Josh Aas]

Comment on attachment 408965 [details] [diff] [review]
fix

Did you mean to drop the check for "mWidgetVisible"?

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix v2

No, good catch.

Comment 21

[Andy Rivas]

Which build should we expect this fix to be in for verification on our end?

Thanks

Comment 22

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'll try to land it tomorrow.

Comment 23

[Robert O'Callahan (:roc) (email my personal email if necessary)]

http://hg.mozilla.org/mozilla-central/rev/650ad2ba0092

The test is failing on Linux for some reason, so I disabled it on non-Windows:
http://hg.mozilla.org/mozilla-central/rev/19286884f3da
I'll look into that, since it should really pass on all platforms.

Comment 24

[Robert O'Callahan (:roc) (email my personal email if necessary)]

OK the test fails on Linux because the widget that the plugin knows about is actually the child of the nsIWidget owned by the nsObjectFrame, so invalidating the latter does not repaint the former. So I'll leave it disabled on non-Windows for now.

Comment 25

[[not reading bugmail]]

I tested this with yesterday's build.  It works on every site I tried.  

I noticed on the Silverlight website that it's a multi-platform Windows Foundation based plugin and it's suppose to work with mac and linux.

Comment 26

[Andy Rivas]

Dale,

Where did you get yesterdays build?  Here? http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.2/

Thanks

Comment 27

[[not reading bugmail]]

(In reply to comment #26)
> Dale,
> 
> Where did you get yesterdays build?  Here?
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.2/
> 
> Thanks

No, Roc has yet to land it there for 3.6.  Andy, here is the one you want:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

I actually tested one of the trunk hourly builds last night after it was compiled in, the nightly looks likes up to date, so you should be ok by using this link.

Comment 28

[Robert O'Callahan (:roc) (email my personal email if necessary)]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/e628b9552999

Comment 29

[Robert O'Callahan (:roc) (email my personal email if necessary)]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/6ca958aa4c8a

Comment 30

[[not reading bugmail]]

(In reply to comment #27)
> (In reply to comment #26)
> > Dale,
> > 
> > Where did you get yesterdays build?  Here?
> > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.2/
> > 
> > Thanks
> 
> No, Roc has yet to land it there for 3.6.  

This works now for 1.9.2 in latest nightly.