Closed Bug 51825 Opened 25 years ago Closed 22 years ago

NS_NOTREACHED assert after not saving document

Categories

(Core :: DOM: Editor, defect, P2)

Product:
Core
Component:
DOM: Editor
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.5alpha

People

(Reporter: jband_mozilla, Assigned: sfraser_bugs)

References

Details

(Keywords: perf, Whiteboard: [code][perf])

Attachments

(1 file)

stack showing assert location (halfway down the stack)
8.82 KB, text/plain
Details
If I open editor, type some text, choose file/close on the menu, and choose 'don't save' in the dialog that pops up: then I hit a NS_NOTREACHED assert at: ###!!! ASSERTION: ~nsTextEditor: 'Not Reached', file x:\seamonkey\mozilla\editor \base\nsHTMLEditor.cpp, line 344 I'll attach thee stack trace. The assert in question is halfway down the trace. The rest of the trace is ugliness that happens because our Windows assert dialog lets window message leak through and this causes another problem.
assign to akkana for review, set to m19
Assignee: beppe → akkana
Keywords: perf
Target Milestone: --- → M19
Status: NEW → ASSIGNED
assigning to brade -- should go to cmankse, but he leaving fo sabbatical, reviewed by Bijal and beppe
Priority: P3 → P2
Whiteboard: [nsbeta3+][p:2]
Beth sez to give to Kathy.
Assignee: akkana → brade
Status: ASSIGNED → NEW
PDT thinks this is an nsbeta3- because the assertion failure isn't visible to the user and no further bad behavior is described.
Whiteboard: [nsbeta3+][p:2] → [nsbeta3-][p:2]
haven't investigated this at all but bugzilla is forcing me to accept :-/
Status: NEW → ASSIGNED
setting this to future, this can wait till post rtm
Target Milestone: M19 → Future
this is very annoying for developers, and removing the assertion has *no* affect on release builds, so I don't see why we can't take it out.
How about mozilla0.9 instead of Future for the Target Milestone? /be
*** Bug 62499 has been marked as a duplicate of this bug. ***
*** Bug 62499 has been marked as a duplicate of this bug. ***
*** Bug 62499 has been marked as a duplicate of this bug. ***
*** Bug 62499 has been marked as a duplicate of this bug. ***
*** Bug 67937 has been marked as a duplicate of this bug. ***
reassign to kin; he knows what to do! :-)
Assignee: brade → kin
Status: ASSIGNED → NEW
Target Milestone: Future → mozilla0.9
Move to mozilla0.9.1 for now. This bug is due to the fact that the editor holds a weak reference to the Doc to avoid circular dependencies. Also, the document is being deleted before the editor because there are references to both the doc and editor being held by JS, when a GC happens the ref to the doc is getting released before the ref to the editor. The editor ownership model will change when sfraser's EditorDocShell/EditorSession changes are enabled so I'm not sure if this is worth fixing at this point. Perhaps we can just change the annoying not reached assertion to a warning.
Target Milestone: mozilla0.9 → mozilla0.9.1
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Whiteboard: [nsbeta3-][p:2] → [code][perf]
moving to 1.0
Target Milestone: mozilla0.9.2 → mozilla1.0
Assignee: kin → sfraser
OS: Windows NT → All
Hardware: PC → All
Taking.
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Pre-sabbatical bug triage.
Target Milestone: mozilla1.0.1 → mozilla1.2alpha
Target Milestone: mozilla1.2alpha → mozilla1.5alpha
Old, and fixed.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: