Re: [firebreath-dev] Plugin insertion on OSX Safari gets triggered on resize or mouse clicks

[Neil Griffiths]

How are you dynamically inserting the plugin objects into the DOM? Are you using innerHTML? The only way I've found to insert dynamically into the DOM that works on all browsers is by using the innerHTML property.

Good luck!

Neil

On Wed, May 8, 2013 at 7:18 AM, Utkarsh Khokhar <utkarsh...@gmail.com> wrote:

Hi Richard,

I know that similar issues have been raised earlier in past couple of years time to time. I believe I haven't missed any previous discussion on Firebreath plugin load issues on Safari so far.

The issue I am facing is slightly weirder in nature.

So, I am inserting one master and 4 slave plugins dynamically in the DOM, and it works well with usual nice guys, like Chrome, Firefox, etc (barring Firefox 20, which might be same or some other problem).

Enter Safari 5.1.7 on OSX 10.7.5, and I can see that only 1 of the 4 slaves get inserted, and not even the master makes it in. However, as soon as I do a window resize of the browser by even a pixel, it loads rest of the plugins as well.

I have another variation of my test page, with the exact same method of plugin insertion in DOM, where I am trying to insert just one master and one slave plugin.

Again, only on the above OSX/Safari combination, I face a unique problem.

None of the plugins gets inserted, unless I go to the DOM elements and double-click on the plugin element and then click anywhere on the page.

I have eliminated the possibility of plugin load issue with some of the internal functioning of my plugin by commenting out all of the functional code and leaving just a dummy plugin behind, that simply loads and renders, nothing else.

Looking forward to some help from the folks on this forum.

regards,

Utkarsh

--
 
---
You received this message because you are subscribed to the Google Groups "firebreath-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebreath-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Utkarsh Khokhar]

I am using appendNode. Basically, create node, then insert into page, and then setting the mimetype post insert complete.

I saw this innerHTML in couple of other threads but don't understand why that would work and appendNode wouldn't.

Perhaps, I am not an expert on this but can your or someone else please explain what difference is there between using appendNode or innerHTML for plugin loading?

thanks

[Neil Griffiths]

What the browsers SHOULD do and what they ACTUALLY do is a bit of a mystery to plugin developers. I agree with you that it SHOULD work - but the only way I've found that actually works is to use innerHTML.

I can't help you understand why it doesn't work (though I agree with you that it should), I can only tell you what I know works. :-)

Neil

[Utkarsh Khokhar]

I understand. Thanks for pointing that out.

I agree that "innerHTML vs appendNode" comparisons on elementary googling throw up lots of pages suggesting innerHTML for speed, etc.

But most of the references seem outdated or ambiguous.

Just out of curiosity, to narrow things down to the plugin load issue, is the DOM insertion speed as major (or perhaps, only) criteria, or there might be some other shenanigans which innerHTML seems to handle better than appendNode.

I know that this discussion might have become more JS specific than Firebreath specific now, but taking my chances here. :-)

thanks

[Utkarsh Khokhar]

Few updates on this issue :

innerHTML seems to have solved the problem, thanks to Neil for his confident suggestion. :-)

Now there is another problem where Chrome is creating and destroying the plugin immediately.

On some research I came across this reference [http://stackoverflow.com/questions/12833641/npp-destroy-gets-called-immediately-after-npp-new].

It highlights the new changes with OSX Chrome 22 onwards, which I checked for in Firebreath source and we already seem to handle.

Am I looking in right areas or there is something else happening here?

thanks

[Utkarsh Khokhar]

Apologies for spamming this thread. I debugged the Chrome issue more and found out that "pluginMain->getParam("drawingmodel")" in NpapiPluginMac::init method is returning NULL.

So basically we are not getting any drawing model in chrome.

This eventually leads to NPDrawingModel=NONE and that leads to NPEventModel=NONE as well.

Same is working fine with Safari and Firefox.

Any pointers on this one guys?

[Utkarsh Khokhar]

I found a possible issue with NPNFuncs.getvalue/setvalue calls made on Chrome (or any browser for that matter) and will raise the concern on a separate post.

This thread is closed from issue addressing perspective.

If someone is however kind enough to answer the appendNode vs innerHTML play, and how different criteria like speed, usage, etc. play a pivotal role in choosing one over other... that would be great.

thanks folks!

[Richard Bateman]

getParam("drawingmodel") is totally optional and has nothing to do with the drawing model selection if it has no return value.

You might have those drawing models disabled in your PluginConfig.cmake file.

Richard

[Utkarsh Khokhar]

I noticed that bit a little later Richard. That's why I just thought that I will debug this to as much depth as I could and I have started a new thread with my findings for this problem, titled "Not sure if Firebreath issue or Chrome issue".

You might want to check that one out.

thanks