[ActiveX] form submissions don't work with more than one process using the activex control



16 years ago
7 years ago


(Reporter: jrv4595, Assigned: adamlock)


Windows XP

Firefox Tracking Flags

(Not tracked)




16 years ago
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 

Reproducible: Always

Steps to Reproduce:
1. Compile the CBrowse test application located in 
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).

Comment 1

16 years ago
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.
Ever confirmed: true
Summary: form submissions don't work with more than one process using the activex control → [ActiveX] form submissions don't work with more than one process using the activex control
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. 

Comment 3

16 years ago
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 ***
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
Component: Embedding: ActiveX Wrapper → Embedding: ActiveX Wrapper
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.