Re: [firebreath-dev] IE-specific null getDOMWindow() question

[Richard Bateman]

I don't have time to track down all the details of what you're doing, but at initial glance it sounds like it might be possible but could require a change in the way that the activex initializes.  You'd just have to play around with it and see if you can make it work.

Richard

On Apr 18, 2013, at 03:02, Christopher Nilsson <other...@gmail.com> wrote:

Hi folks,

I'm hitting an odd issue, which might just be due to my newness to firebreath, and my taking the easy (lazy?) road with internet explorer context menus.

Quick background: 

My plugin has been working nicely, when called via javascript on a regular html page.

I was hoping to reuse this plugin, when called by the context entries I've set up, using this method: http://msdn.microsoft.com/en-us/library/aa753589.aspx 

In short, IE will add some context menu items, based on a couple of simple registry entries.

Those entries point to html files on the local filesystem, and you get to do whatever javascript stuff you want from that point on.

I've added my <object> tag to this context html file, and was wanting to run it's stuff.

The problem:

Firebreath explodes quite early on while being loaded (not FB's fault -- obviously I'm doing something silly...).

Specifically, in FB::ActiveX::CFBControl<>::Load(), when it's calling PluginCore::setParams():

FB::JSObjectPtr tmp;

tmp = m_host->getDOMWindow()

->getProperty<FB::JSObjectPtr>(value);

As it turns out, m_host->getDOMWindow() is returning NULL, so the call to getProperty()

explodes.

Likely cause of the null window (maybe?):

On that MSDN page I linked to, it says, 

"This script can obtain the parent window object, 
the screen where the context menu item was executed, from the menuArguments property 
of the external object."

In javascript, to get a reference to the parent window, I have to do something like this:

var windowObject = external.menuArguments;

var docObject = windowObject.document;

So this makes me think the window object isn't where it usually is, when Firebreath is initialised.

Is it feasible (or at least, not impossible) to access this "external.menuArguments" reference, when the interface 

we're chasing for the window object yields a "not available"? 

Before I hunt further, was hoping to hear if it can be done, or if maybe I'm completely insane for doing things this way. :)

If it turns out I am insane, I'll probably just need to make an extension with "real" context menu entries, I guess.

If it's any help, here's a cut down stack trace:

Plugin.dll!_wassert(const wchar_t * expr=0x58ec6ae4, const wchar_t * filename=0x58ec6c00, unsigned int lineno=424) Line 344 C

Plugin.dll!boost::shared_ptr<FB::DOM::Window>::operator->() Line 424 C++

Plugin.dll!FB::PluginCore::setParams(const std::map<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,FB::variant,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<std::basic_string<char,std::char_traits<char>,std::allocator<char> > const ,FB::variant> > > & inParams={...}) Line 75 C++

Plugin.dll!FB::ActiveX::CFBControl<&CLSID_FBControl0,&FB::ActiveX::FBCONTROL0_MIMETYPE,IFBControl,&DIID_IFBComEventSource,&LIBID_HelpaPluginLib>::Load(IPropertyBag * pPropBag=0x06a0ae28, IErrorLog * pErrorLog=0x00000000) Line 411 C++

mshtml.dll!COleSite::LoadObject() Unknown

mshtml.dll!COleSite::CreateObjectNow() Unknown

...

Thanks for any advice.

Cheers,

Chris.

--
 
---
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.