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

RESOLVED FIXED

Status

Core Graveyard
Embedding: ActiveX Wrapper
RESOLVED FIXED
15 years ago
6 years ago

People

(Reporter: Adam Lock, Assigned: Adam Lock)

Tracking

Trunk
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

15 years ago
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
(Assignee)

Comment 1

15 years ago
Created attachment 134644 [details] [diff] [review]
Patch

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

Comment 2

15 years ago
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.
Attachment #134644 - Flags: superreview?(blizzard)
Attachment #134644 - Flags: review?(bz-vacation)
(Assignee)

Comment 3

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

sr=jst
Attachment #134644 - Flags: superreview?(blizzard) → superreview+

Comment 6

15 years ago
Is this bug blocking from using activeX controls in applications like HTMLKit ?
I saw this problem earlier.
(Assignee)

Comment 7

15 years ago
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.