The profile service is returning errors in some circumstances that cause HRESULT CMozillaBrowser::Initialize() to return before it has registered window creator, prompt and helper dialog services. Move all the profile opening to the end of this function so it can't break anything else
Created attachment 134644 [details] [diff] [review] Patch Move the profile stuff to the end where it can't break anything
Comment on attachment 134644 [details] [diff] [review] Patch Requesting r/sr on this patch to reorder the ActiveX control init routine to minimize profile breakage.
BTW the profile problems I'm speaking of, are when you have multiple programs running the control at the same time (e.g. Devstudio .Net & the app you're testing), the second process can't obtain a profile lock error and exits the initialize method without registering the window creator & other components. So the behaviour is not correct. Even if the profile can't be locked I still want the behaviour to remain consistent.
Comment on attachment 134644 [details] [diff] [review] Patch r=bzbarsky
Attachment #134644 - Flags: review?(bz-vacation) → review+
Comment on attachment 134644 [details] [diff] [review] Patch sr=jst
Attachment #134644 - Flags: superreview?(blizzard) → superreview+
Is this bug blocking from using activeX controls in applications like HTMLKit ? I saw this problem earlier.
Fix is checked in The control still works without this patch, but it exhibits odd behaviour. Popup windows stop working, prompts don't work etc. So I moved the initialization around so even if the profile is locked, the control will function more or less properly when two apps are looking at the same profile.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
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.