Firebreath will not create plugin window when object tag has data attribute and without and param tag

I have never seen an issue similar to this and I use my plugin on IE9 all the time; I need an example project that reproduces the issue or I will have to reject it because I have no idea how to repro it.

I've attached a test project with it's compiled binary, with modified FBControl.htm,

After register the dll, load the htm in IE9, you will see only first <object> has some info drawed into it's canvas, I just modified the generated source onMouseMove function to draw some text within the window client.

these two <object> in html both have a data attribute points to a existing readme.txt, but the second <object> don't have and <param> nested, so I don't draw at all.

I'm a bit behind on another project, so it may be a week or two before I can look at this, but I'll try to get to it before too long.

As a side note, you nearly always want to use the onload param so you know when the plugin is available anyway, so this doesn't affect many people, but if I can repro it with your project I'll try to figure out what is causing it.

any update on this?

Sorry, I still have not had a chance to look at it; I just finished moving (well, finished physically getting all our things into a new house) so my spare time has been extremely limited and I can't take work time to look at this. I would recommend that you set some breakpoints in FBControl.h and see if you can identify places where the startup lifecycle is different; that is what I would do. Pay particular attention to Load (https://github.com/firebreath/FireBreath/blob/master/src/ActiveXCore/FBControl.h#L411) and InitNew (https://github.com/firebreath/FireBreath/blob/master/src/ActiveXCore/FBControl.h#L375) which comprise the only places that I know of where the load should be different without params.

Let me know what you find.

Note "community additions" section of this page: (someone else has noticed this same strangeness with object activation) http://msdn.microsoft.com/en-us/library/ie/ms535880(v=vs.85).aspx

Thanks for the test project Steve. Try this fix: https://github.com/dougma/FireBreath/compare/FB-177

thanks, the problem has been fixed.

well, problem is not fixed, if there is no param tag, then FBControl::InitNew and Load function will never be called because the no param tag cause the IPersistPropertyBag thinks there is no property, so setReady will never be called, then JSAPI will fail, because setReady sets the host of JSAPI.

So I added a setReady() call in last line of InPlaceActivate, it seems good so far. but I'm not sure it's the right way to solve this.

Hmm; this is really strange. That is a definite divergence from how it used to work; it used to be that InitNew would get called if no properties were present.

This may take a bit more thinking on how to address properly. :-/

test page with two plugins side by side; one with param element, one without.

wowzer... i didn't test that very well did I? I wonder if I was testing with Firefox?!

Steve's on the right track; i've moved setReady from InitNew/Load to InPlaceActivate and it tests out ok with my test page (attached to this issue now).

well, this would really fix this problem, but one problem is that InPlaceActive seems will be called multiple times during the initialization and running, so should we create a member variable to mark ready has been set?

But, call setReady multiple times won't cause any problem, because JSAPI and host won't change during the life of the plugin.

sorry, InPlaceActive will only called once, after all initialize completed, so move setReady to InPlaceActive will be the final solution for this.

Unfortunately, that is not the case. InPlaceActivate can be called multiple times, just not without InPlaceDeactivate being called between each call. It's a definite edge case, but one we need to support without crashing.

and this related to another problem, if there is no <param> tag, plugin should parse the <object> tag's attributes to set plugin param. this is the code to parse the <object> tag, and this should be placed after SetClientSite:

// parse attributes in <object> tag as parameters
    FB::VariantMap paramMap;

    CComQIPtr<IOleControlSite> site(pClientSite);

    // if already setReady, then skip
    if(site == 0 || m_setReadyDone) return S_OK;

    CComPtr<IDispatch> dispach, attr_disp;
    site->GetExtendedControl(&dispach);

    // getting attributes of <object> tag
    CComQIPtr<IHTMLElement2> htmlElement(dispach);
    CComQIPtr<IHTMLDOMNode> domNode(htmlElement);

    domNode->get_attributes(&attr_disp);
    CComQIPtr<IHTMLAttributeCollection> attributs(attr_disp);

    long count;
    attributs->get_length(&count);
    VARIANT vIndex;
    vIndex.vt = VT_I4;
    VARIANT_BOOL vbSpecified;
    for(long i=0; i<count; i++)
    {
        CComPtr<IDispatch> item_disp;
        vIndex.lVal = i;
        hr = attributs->item(&vIndex, &item_disp);
        if(hr != S_OK || item_disp == 0)
            continue;

        CComQIPtr<IHTMLDOMAttribute> attr_item(item_disp);
        hr = attr_item->get_specified(&vbSpecified);

        // many of attributes will be not specified
        // only process specified attributes
        if(hr != S_OK || vbSpecified == VARIANT_FALSE)
            continue;

        CComBSTR name;
        CComVariant value;
        attr_item->get_nodeName(&name);
        attr_item->get_nodeValue(&value);

        if(value.vt == VT_NULL || value.pbstrVal == 0)
            continue;

        FB::variant varval(m_host->getVariant(&value));
        paramMap[FB::wstring_to_utf8(name.m_str)] = varval;
    }

    pluginMain->setParams(paramMap);

hmm; that's definitely an interesting idea. Do you get those params on npapi browsers automatically? I can't remember offhand. I'd welcome a pull request where this was already done so I could easily look at what you propose.

yes, under npapi, NPP_New will parse the <object> tag and send all attributs AND <param> tag's value through argn, argv.

But under IE, IE will not parse the attributes in <object> tag then won't parse these attributes to control.

finally getting to look at this; it seems like a good idea. I'm closing the issue because the actual issue is fixed, but I'd love to see this resubmitted as an improvement request.

I believe this is now fixed.