542248 - [OOPP] silverlight: ###!!! ASSERTION: Shouldn't return null and NPERR_NO_ERROR!: 'npobject' (or crash [@ mozilla::plugins::PluginInstanceParent::GetActorForNPObject(NPObject*)])

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Benjamin Smedberg]

Silverlight OOPP:
###!!! ASSERTION: Shouldn't return null and NPERR_NO_ERROR!: 'npobject'
in PluginInstanceParent::InternalGetValueForNPObject

This is requesting NPNVPluginElementNPObject. I don't think this is a good assertion (an immediate crash follows). As far as I know, if a plugin doesn't want to provide a prototype NPObject, it can still respond to NPNVPluginElementNPObject with NPERR_NO_ERROR and a null object.

Comment 1

[Benjamin Smedberg]

Hrm, my thinking is wrong... this is our plugin host returning NPNVPluginElementNPObject, and it should always have a value.

STR:
visit http://timheuer.com/silverlight/bouncingplane/
http://silverlight.net/learn/videos/all/how-do-i-improve-graphics-performance-using-cachemode/

Comment 2

[[not reading bugmail]]

Ben, I have a few signatures in the crash reporter on this.

Comment 3

[Tanner M. Young [:tmyoung]]

I have the same crash signature for the Adobe PDF Plugin, when I try to save pdfs or (less frequently) when I open them:

http://crash-stats.mozilla.com/report/index/9cdcc0f1-b470-4e29-9c5f-b4bae2100130
http://crash-stats.mozilla.com/report/index/243f0d73-8dad-44f1-bd78-721f32100130

I don't know if this is the same problem, but at least it is the same signature.

Comment 4

[Benjamin Smedberg]

Attachment: Null-check, rev. 1

If we navigate away from the page, there is a period of time where the plugin is still trying to do stuff before we tear down the frame tree and call NPP_Destroy. In this period of time, NPN_GetValue(NPNVPluginElementNPOBject) will return null/NPERR_NO_ERROR because it can't get a JSContext* for the page. This patch just makes it so that we return an error just as NPNVWindowNPObject does.

Comment 5

[Josh Aas]

Comment on attachment 424776 [details] [diff] [review]
Null-check, rev. 1

Great, I assume you're planning to put this on the 1.9.2 branch. We should probably do it as a normal stability update, no need to wait for Lorentz.

Comment 6

[Benjamin Smedberg]

http://hg.mozilla.org/mozilla-central/rev/101321ab7040

Comment 7

[Benjamin Smedberg]

Comment on attachment 424776 [details] [diff] [review]
Null-check, rev. 1

I don't think it really matters whether this hits branches (at least until Lorentz hits), but I also don't think it could hurt.

Comment 9

[Jim Jeffery not reading bug-mail 1/2/11]

Verifying fixed using today's nightly on Win7 x-64

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100203 Minefield/3.7a1pre ID:20100203081257

Comment 10

[Daniel Veditz [:dveditz]]

Comment on attachment 424776 [details] [diff] [review]
Null-check, rev. 1

Didn't make 1.9.2.2, we'll look at next time.

Comment 11

[Benjamin Smedberg]

http://hg.mozilla.org/projects/firefox-lorentz/rev/2d78ecf843ec

Comment 12

[Mike Beltzner [:beltzner, not reading bugmail]]

Blanket approval for Lorentz merge to mozilla-1.9.2
a=beltzner for 1.9.2.4 - please make sure to mark status1.9.2:.4-fixed

Comment 13

[Benjamin Smedberg]

Merged into 1.9.2 at http://hg.mozilla.org/releases/mozilla-1.9.2/rev/84ba4d805430