Issue 114180 - OO crash on enabling "support assistive technology tools" and opening a Basic Macro file
Summary: OO crash on enabling "support assistive technology tools" and opening a Basic...
Status: CLOSED FIXED
Alias: None
Product: Writer
Classification: Application
Component: programming (show other issues)
Version: OOO320m12
Hardware: PC Windows XP
: P2 Trivial (vote)
Target Milestone: ---
Assignee: eric.savary
QA Contact: issues@sw
URL:
Keywords: accessibility
Depends on:
Blocks:
 
Reported: 2010-08-29 13:41 UTC by yajva
Modified: 2017-05-20 11:41 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description yajva 2010-08-29 13:41:25 UTC 
Hi

I have enabled Tools->options->java->"use a java run time environment"
I have JRE 1.6.0_19 (with accessibility support)

I enable Tools->options->Accesibility->"Support assistive technology tools and 
restart OO"

OO crashes consistently on trying to open a Basic Macro file through macro 
editor, the monment 'edit' button is clicked on the dialog Tools->macros-
>organise macros->OO.org Basic ...-> "Choose OpenOffice.org Macros" -> Depot-
>CommonLang->LoadLanguage

The crash does not occur for some files, however (eg. XrayDyn->XXXray with XRay 
tool installed). I am unable to find the distinctive criteria.

Regards
Comment 1 eric.savary 2010-08-30 14:39:17 UTC 
Reproduced on Windows (not reproducible on Unix) with JRE 1.6 and JAB 2.0.1 (and
1.0).
- A11y ON
- "Tools - Macros - Organize Macros - OpenOffice.org Basic"
- "OpenOffice.org Macros - Depot - CommonLang"
- Edit "LoadLanguage"
-> Crash

After a first crash, a second try did not crash. A third or forth yes.
- Choosing: "OpenOffice.org Macros - Depot - Lang_de"
- Edit "LoadGermanLanguage" also crashed.

@AB: please evaluate risk/effort of a fix as stopper for 3.3.
Comment 2 groucho266 2010-08-31 15:34:58 UTC 
Taking over.
Comment 3 groucho266 2010-08-31 16:49:19 UTC 
The crash is caused by VCLXWindow which does not listen to VCLEVENT_OBJECT_DYING
events.  As a result, in its destructor, it tries to unregister listeners from
an already destructed Window object.
Comment 4 groucho266 2010-09-01 14:47:25 UTC 
The root cause is different from what I wrote above (which describes a symptom.)

When one of the windows involved in the actions describe above is created via
the toolkit, there are two VCLXWindow objects created for one vcl window:
One is created and creates its VCL window.  This is broadcasted and one of the
listeners asks for its VCLXWindow. Because the first VCLXWindow construction is
not yet finished a second one is created.

Fixed by adding a check to VCLXToolkit::ImplCreateWindow whether its VCL window
is already connected to a VCLXWindow object.  If so, then that is returned. 
Otherwise a new one is created.
Comment 5 groucho266 2010-09-02 13:44:22 UTC 
@es: Please verify.
Comment 6 eric.savary 2010-09-02 14:16:04 UTC 
Verified in CWS impress200.