224455 - [ActiveX] Profile error causes Initialize() to return early, breaks targetted links, new windows

Status: RESOLVED FIXED

(Core Graveyard :: Embedding: ActiveX Wrapper, defect)

Description

[Adam Lock]

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

Comment 1

[Adam Lock]

Attachment: Patch

Move the profile stuff to the end where it can't break anything

Comment 2

[Adam Lock]

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.

Comment 3

[Adam Lock]

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 4

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 134644 [details] [diff] [review]
Patch

r=bzbarsky

Comment 5

[Johnny Stenback (:jst)]

Comment on attachment 134644 [details] [diff] [review]
Patch

sr=jst

Comment 6

[Frederic Bezies]

Is this bug blocking from using activeX controls in applications like HTMLKit ?
I saw this problem earlier.

Comment 7

[Adam Lock]

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.