User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 If I have two separate processes using the ActiveX control, the first one that was started will be able to submit forms (such as clicking "Search" on Google), but the second one will not (regular links work in both). If two instances of the control are used in the same process, they will both work. I tested this using both the CBrowse example provided with the source, and Microsoft's "ActiveX Control Test Container" tool (provided with Visual Studio 6). Reproducible: Always Steps to Reproduce: 1. Compile the CBrowse test application located in <src>\embedding\browser\activex\tests\cbrowse 2. Start two separate instances of the CBrowse executable. Select the Mozilla control for each of them. 3. Navigate to http://www.google.com with each instance. 4. Attempt to search with each instance. Actual Results: The first instance searched successfully, but the second instance did nothing. Expected Results: Both instances should have searched. I have tested this on both Windows XP and 2000. The 2000 machine had never had a previous Mozilla installation on it, and so it was a pretty clean run. Another problem that is perhaps related to this is that the Security Warning message dealing with sending unencrypted information pops up each time a new instance of the control is used (e.g. it doesn't remember the "don't show this again" setting).
This explains more than I first read in the npm.embedding article about form submit issues. Basically the control is opening a profile when it starts. If you open two processes each containing a control, the second will fail to open the profile because it is already locked. I don't know if it is now possible to share a single profile between processes (Conrad?), but if it is then I guess the answer is to add code to do that.
Yeah, it sounds like a good application for profile sharing. All instances of the control could share the same profile. 2 problems right now: (1) The only data that's currently shareable is prefs. (2) Since not all data is shareable, each instance of the control would have to have unique non-shared data, which is identified by name. The implementation was designed for a suite of apps which use, say, "mail" or "browser" non-shared data, but only 1 instance of each named client at a time. This is until we can: (a) share all data in a profile or (b) have some way of creating "temporary" non-shared data.
I'm going to dupe this against bug 209787 which is a big reorg of the init and shutdown of the control and would have to take this into account anyway. From Conrad's description it doesn't sound like profile sharing is a good idea so my ideas to alleviate this issue are twofold: a) Allow the embedder to specify their own profile name via a persistable property. So in VB you could create the control, set the "MozProfileName" property to "foo" and that app would use that profile. b) Allow the control to create a temporary profile if the one specified is locked. By default this would enabled on but it could be controlled with another "MozUseTempProfileIfLocked" property. I have an updated patch for this which will appear on the other bug when I've debugged it. *** This bug has been marked as a duplicate of 209787 ***