The control is throwing the above exception in response to all methods. For example, load the control into Microsoft's ActiveX Control Test Container and invoke the Resizable (Prop Get) method. Build: 2000060908 (and at least several previous builds)
What sort of control? Please tell us exact steps to reproduce, eventually supply an URL or/and attach a test case. That would help, TIA.
The control is mozctl.dll, the COM control for embedding the Mozilla browser into an application. Assuming you have Microsoft Visual C++, Microsoft's ActiveX Control Test Container is the easiest way to demonstrate the problem. No URL is needed because it isn't necessary to execute the Navigate method. Just load the control and invoke the Resizable (for example) method. But the problem isn't unique to the ActiveX Control Test Container. This problem is new since build 2000052920.
Do you have the ambient property UserMode set to -1 or 0? The control might think it's in "design mode" if it's not set correctly in which case method calls could very well fail, especially if there is no browser window.
My container application doesn't supply an explicit UserMode value, so if the control asks, it should get the default TRUE. But I don't think this has anything to do with the problem. Neither the control from the 2000052920 build (which works) nor the one from the 2000060908 build (which doesn't work) behaves any differently when I change the UserMode property using Microsoft's ActiveX Control Test Container.
I just tried M16 and it didn't work. It looks like the Mozilla control is having a failure somewhere during initialization and refuses to accept any method calls because it has not been set up. Since the control has hardly changed in the last few months I'm guessing that something in docshell or webbrowser has fouled up the control. My local copy of the control (which has changed a lot) DOES work, so I'll look to see if I can find the reason why it does and the other one doesn't.
Reassigning to myself!
This is a duplicate of 39155 *** This bug has been marked as a duplicate of 39155 ***