Did a little more debugging. It appears that nsObjectFrame::CallSetWindow is being called, but mInstanceOwner isn't set (our Initialize call has NOT been called at this point). Minefield doesn't appear to crash, but our plugin still doesn't work. How is it that the layout/compositing code is attempting to paint us before initializing us? Do we need some special handling in NewStream for the data="anything" case?
Sorry minefield is crashing, I had some local changes I forgot about.
More details: The (pertinent) call chain appears to be like this: NPP_GetMimeDescription NPP_GetValue (NPPVpluginNameString) NPP_GetValue (NPPVpluginDescriptionString) nsObjectFrame::CallSetWindow () (on the plugin, triggered by reflow, mInstanceOwner is null) NPP_Initialize NPP_New I'm not entirely sure what set of circumstances causes this to happen (see the comments in the testcase about the <h1> causing this to trigger), but its almost certainly (?) flow layout related? I would guess the layout engine shouldn't be attempting to reflow plugins that are not yet initialized.
Created attachment 327145 [details] [diff] [review] Prevent flushing layout changes before a plugin has been initialized.
Comment on attachment 327145 [details] [diff] [review] Prevent flushing layout changes before a plugin has been initialized. Boris, what's your thoughts on this fix?
The first thought is that it just backs out the key part of the fix for bug 381512 and thus would regress it. Some bonsai due diligence would have been good here.... The second thought is that we need plug-in regression tests. The third thought is that the stack in this bug has to do with painting, not layout, so I'm not quite sure why this patch is helping. Why is it?
Comment on attachment 327145 [details] [diff] [review] Prevent flushing layout changes before a plugin has been initialized. r-, given that it breaks other things, as far as I can see. If it somehow doesn't, I'd like to know why not.
boris, The bug was moved to layout because the reflow caused at the changed section calls SetWindow before the plugin has had NPP_New/NPP_Initialize called on it (see my previous comments). Causing the reflow to not flush prevents this crash. If you look at the testcase (.html) and the comments included it shows that its something to do with layout (I think) as the <h1 /> being removed obscures the bug again. Admittedly I'm not deeply familiar with the mozilla codebase, in fact this is the first time I've dug into it in earnest, but the patch was included as something that seemed logical given the exhibited behavior. At the very least we should NEVER be calling SetWindow down the call chain before a plugin as had Init/New called on it.
(In reply to comment #10) > At the very least we should NEVER be calling SetWindow down the call chain > before a plugin as had Init/New called on it. I expect nsObjectFrame::CallSetWindow skips the SetWindow unless Init/New has been called, but let me know if you see otherwise. I'm pretty sure that you are right in suggesting that this is a dupe of Bug 435764. Thank you for all your analysis. Please test attachment 327742 [details] [diff] [review] if you can, or at least the tryserver build at bug 435764 comment 11. If that doesn't resolve the problem then reopen this bug.