Closed Bug 208265 Opened 21 years ago Closed 21 years ago

Accessibility can crash after profile manager closes

Categories

(Core :: Disability Access APIs, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: aaronlev, Assigned: aaronlev)

Details

(Whiteboard: in-process-accessibility)

Attachments

(1 file)

If accessibility is active and the profile manager is run, there can be a crash
after the window closes.

This seems to happen when we do:
    nsCOMPtr<nsICommandManager> commandManager = do_GetInterface(container);

on the for the XUL window's docshell.
Attachment #124900 - Flags: review?(kyle.yuan)
Comment on attachment 124900 [details] [diff] [review]
Only checks the command manager for content docs. Also moves timer shutdown to more appropriate place, symmetrical to where the timers are created.

r=kyle
Attachment #124900 - Flags: review?(kyle.yuan) → review+
Attachment #124900 - Flags: superreview?(alecf)
Comment on attachment 124900 [details] [diff] [review]
Only checks the command manager for content docs. Also moves timer shutdown to more appropriate place, symmetrical to where the timers are created.

sr=alecf
Attachment #124900 - Flags: superreview?(alecf) → superreview+
checked in
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Severity: normal → enhancement
Whiteboard: in-process-accessibility
Comment on attachment 124900 [details] [diff] [review]
Only checks the command manager for content docs. Also moves timer shutdown to more appropriate place, symmetrical to where the timers are created.

For making the accessibility feature work better and more stable in 1.4.x, we
need to get this patch in. This fix has been in trunk for a long period. It
won't affect other modules.
Attachment #124900 - Flags: approval1.4.x?
Comment on attachment 124900 [details] [diff] [review]
Only checks the command manager for content docs. Also moves timer shutdown to more appropriate place, symmetrical to where the timers are created.

This is not going to make 1.4.1.  Please re-request aproval after 1.4.1 ships
if you'd like to get this in for 1.4.2. 
Kyle, can you all take this into your tree locally until after 1.4.1 ships
(real soon now) and then work with us to get it landed first thing for 1.4.2?
Attachment #124900 - Flags: approval1.4.x? → approval1.4.x-
Asa, sure, we can wait for 1.4.2.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: