Closed Bug 510082 Opened 10 years ago Closed 10 years ago

Silverlight 3 plugin elements don't repaint correctly

Categories

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

x86
Windows XP
defect

Tracking

()

RESOLVED FIXED
mozilla1.9.2
Tracking Status
status1.9.2 --- beta2-fixed

People

(Reporter: sylvain.pasche, Assigned: roc)

References

()

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

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/
I think this happened when Compositor landed.

I've also had problems interacting with some Silverlight apps since the landing.
Assignee: nobody → roc
Flags: blocking1.9.2?
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?
>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.
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.
Blocking on this regression.
Flags: blocking1.9.2? → blocking1.9.2+
Priority: -- → P2
Target Milestone: --- → mozilla1.9.2
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...
Whiteboard: [need feedback]
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?
Whiteboard: [need feedback]
Roc, any chance for a fix here?  Maybe Shaver can call em over.
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.
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?
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)
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.
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.
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?
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.
Attached patch fix (obsolete) — Splinter Review
Attachment #408965 - Flags: review?(joshmoz)
Whiteboard: [needs review]
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.
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 on attachment 408965 [details] [diff] [review]
fix

Did you mean to drop the check for "mWidgetVisible"?
Attached patch fix v2Splinter Review
No, good catch.
Attachment #408965 - Attachment is obsolete: true
Attachment #409166 - Flags: review?(joshmoz)
Attachment #408965 - Flags: review?(joshmoz)
Attachment #409166 - Flags: review?(joshmoz) → review+
Which build should we expect this fix to be in for verification on our end?

Thanks
I'll try to land it tomorrow.
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.
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [needs review] → [needs 192 landing]
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.
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.
Dale,

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

Thanks
(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.
(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.
Depends on: 1318833
You need to log in before you can comment on or make changes to this bug.