Closed
Bug 1040751
Opened 11 years ago
Closed 10 years ago
CodeMirror editor.destroy() isn't e10s compatible
Categories
(DevTools :: Source Editor, defect)
DevTools
Source Editor
Tracking
(e10s+)
RESOLVED
WORKSFORME
| Tracking | Status | |
|---|---|---|
| e10s | + | --- |
People
(Reporter: miker, Unassigned)
References
Details
(Whiteboard: [e10s-m7])
The following listeners do not get removed when CodeMirror's editor.destroy() is called in e10s mode:
this._prefObserver.off(TAB_SIZE, this.reloadPreferences);
this._prefObserver.off(EXPAND_TAB, this.reloadPreferences);
this._prefObserver.off(KEYMAP, this.reloadPreferences);
this._prefObserver.off(AUTO_CLOSE, this.reloadPreferences);
this._prefObserver.off(AUTOCOMPLETE, this.reloadPreferences);
this._prefObserver.off(DETECT_INDENT, this.reloadPreferences);
This prevents the next line being called, which is:
this._prefObserver.destroy();
| Reporter | ||
Updated•11 years ago
|
Summary: CodeMirror iframes leak when e10s enabled → CodeMirror editor.destroy() isn't e10s compatible
Updated•11 years ago
|
tracking-e10s:
--- → +
Comment 2•10 years ago
|
||
devtools bugs will block the e10s merge to Aurora, but blassey would like them to be tracked by dte10s meta bug 875871, not the tracking-e10s=m6+ flag.
Updated•10 years ago
|
Whiteboard: [e10s-m6]
Updated•10 years ago
|
Whiteboard: [e10s-m6] → [e10s-m7]
Comment 3•10 years ago
|
||
(In reply to Michael Ratcliffe [:miker] [:mratcliffe] from comment #0)
> The following listeners do not get removed when CodeMirror's
> editor.destroy() is called in e10s mode:
> this._prefObserver.off(TAB_SIZE, this.reloadPreferences);
> this._prefObserver.off(EXPAND_TAB, this.reloadPreferences);
> this._prefObserver.off(KEYMAP, this.reloadPreferences);
> this._prefObserver.off(AUTO_CLOSE, this.reloadPreferences);
> this._prefObserver.off(AUTOCOMPLETE, this.reloadPreferences);
> this._prefObserver.off(DETECT_INDENT, this.reloadPreferences);
>
> This prevents the next line being called, which is:
> this._prefObserver.destroy();
I wonder if we actually need to manually call off on all of these before calling destroy, or if destroy will handle that for us.
Comment 4•10 years ago
|
||
How can this be tested? Based on the description it sounds like it maybe one of those lines is throwing an exception, causing the destroy function to not fire. But I'm not seeing any errors in the Browser Console when opening and closing the Style Editor.
Flags: needinfo?(mratcliffe)
| Reporter | ||
Comment 5•10 years ago
|
||
(In reply to Brian Grinstead [:bgrins] from comment #4)
> How can this be tested? Based on the description it sounds like it maybe
> one of those lines is throwing an exception, causing the destroy function to
> not fire. But I'm not seeing any errors in the Browser Console when opening
> and closing the Style Editor.
No idea, maybe try / catch, using dump between each line, stepping through the code etc.
Flags: needinfo?(mratcliffe)
Comment 6•10 years ago
|
||
(In reply to Michael Ratcliffe [:miker] [:mratcliffe] from comment #5)
> (In reply to Brian Grinstead [:bgrins] from comment #4)
> > How can this be tested? Based on the description it sounds like it maybe
> > one of those lines is throwing an exception, causing the destroy function to
> > not fire. But I'm not seeing any errors in the Browser Console when opening
> > and closing the Style Editor.
>
> No idea, maybe try / catch, using dump between each line, stepping through
> the code etc.
There are no errors in the editor.destroy function, it runs through all the way to the end. And there don't seem to be any leaks. So unless if you remember anything else specifically about this issue, going to resolve.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Updated•7 years ago
|
Product: Firefox → DevTools
You need to log in
before you can comment on or make changes to this bug.
Description
•