Closed
Bug 56597
Opened 24 years ago
Closed 24 years ago
Crash trying to edit framed pages in Composer
Categories
(Core :: DOM: Editor, defect, P3)
Tracking
()
VERIFIED
WORKSFORME
mozilla0.9
People
(Reporter: bugzilla, Assigned: sfraser_bugs)
References
()
Details
(Keywords: crash)
Overview Description:
I crash when trying to edit a certain page in Composer; I've seen this with
multiple pages.
Steps to Reproduce:
1) Go to http://www.thecompanytheatre.com/
2) File | Edit Page
Actual Results: Crash.
Reproducibility: 100% win98se new *trunk* build (not tested on branch)
Additional Information:
In a debug build, I get the following assertion:
###!!! ASSERTION: Should never have an editor here: '!mEditor', file C:\mozilla\
editor\base\nsEditorShell.cpp, line 424
which has a stack trace of
KERNEL32! bff768a0()
nsDebug::Assertion(const char * 0x02989b6c, const char * 0x02989b60, const char
* 0x02989b34, int 424) line 256 + 13 bytes
nsEditorShell::PrepareDocumentForEditing(nsIDocumentLoader * 0x045939b0, nsIURI
* 0x04593730) line 424 + 44 bytes
nsEditorShell::OnEndDocumentLoad(nsEditorShell * const 0x04542848,
nsIDocumentLoader * 0x045939b0, nsIChannel * 0x045931b0, unsigned int 0) line
5214 + 27 bytes
nsWebShell::OnEndDocumentLoad(nsWebShell * const 0x04591258, nsIDocumentLoader
* 0x045939b0, nsIChannel * 0x045931b0, unsigned int 0) line 978
nsDocLoaderImpl::FireOnEndDocumentLoad(nsDocLoaderImpl * 0x045939b0, nsIChannel
* 0x045931b0, unsigned int 0) line 805
nsDocLoaderImpl::DocLoaderIsEmpty(unsigned int 0) line 612
nsDocLoaderImpl::OnStopRequest(nsDocLoaderImpl * const 0x045939b4, nsIChannel *
0x0476b5f0, nsISupports * 0x00000000, unsigned int 0, const unsigned short *
0x00000000) line 555
nsLoadGroup::RemoveChannel(nsLoadGroup * const 0x04593950, nsIChannel *
0x0476b5f0, nsISupports * 0x00000000, unsigned int 0, const unsigned short *
0x00000000) line 566 + 39 bytes
PresShell::RemoveDummyLayoutRequest() line 5337 + 44 bytes
PresShell::ReflowCommandRemoved(nsIReflowCommand * 0x047141e0) line 5290
PresShell::ProcessReflowCommands(int 1) line 5110
ReflowEvent::HandleEvent() line 4995
HandlePLEvent(ReflowEvent * 0x04714180) line 5005
PL_HandleEvent(PLEvent * 0x04714180) line 576 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00f7c190) line 509 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x000009b8, unsigned int 55656, unsigned int 0,
long 16236944) line 1054 + 9 bytes
KERNEL32! bff7363b()
KERNEL32! bff94407()
007a8a32()
Reporter | ||
Comment 1•24 years ago
|
||
nominating for rtm since I see this on many pages. cc'ing some people since
beppe is away, i think.
Reporter | ||
Comment 2•24 years ago
|
||
OK, this happens on any page with a frameset, making this a definite rtm-
blocker...
This also happens on betanews.com, which is odd, cause it doesn't have frames.
It does have <iframe>'s, but a testcase with just an <iframe> didn't crash.
Summary: Crash trying to edit page in Composer → Crash trying to edit framed pages in Composer
Assignee | ||
Comment 3•24 years ago
|
||
Is this just a crash, or an assertion? And, please test the branch.
Assignee: beppe → sfraser
I just tried this on the Netscape_20000922_BRANCH. You can continue passed the
assertion reported above, you'll get the dialog that you can't edit that
page, but then you get an assertion and then a crash after you dismiss the
dialog.
Here's the 2nd assertion:
NTDLL! 77f762e8()
nsDebug::Assertion(const char * 0x047862fc, const char * 0x100c6454, const char
* 0x047862d4, int 349) line 256 + 13 bytes
nsDebug::NotReached(const char * 0x047862fc, const char * 0x047862d4, int 349)
line 414 + 22 bytes
nsHTMLEditor::~nsHTMLEditor() line 349 + 21 bytes
nsHTMLEditorLog::~nsHTMLEditorLog() line 51 + 22 bytes
nsHTMLEditorLog::`scalar deleting destructor'() + 15 bytes
nsEditor::Release(nsEditor * const 0x056c8060) line 951 + 158 bytes
nsHTMLEditor::Release(nsHTMLEditor * const 0x056c8060) line 355 + 12 bytes
nsHTMLEditorLog::Release(nsHTMLEditorLog * const 0x056c8060) line 54 + 12 bytes
nsCOMPtr<nsIHTMLEditor>::~nsCOMPtr<nsIHTMLEditor>() line 490
nsEditorShell::~nsEditorShell() line 275 + 163 bytes
nsEditorShell::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsEditorShell::Release(nsEditorShell * const 0x0560ff00) line 278 + 157 bytes
nsCOMPtr<nsIDocumentLoaderObserver>::~nsCOMPtr<nsIDocumentLoaderObserver>() line
490
nsWebShell::OnEndDocumentLoad(nsWebShell * const 0x05604ca8, nsIDocumentLoader *
0x0560e380, nsIChannel * 0x05687770, unsigned int 0) line 1144 + 17 bytes
nsDocLoaderImpl::FireOnEndDocumentLoad(nsDocLoaderImpl * 0x0560e380, nsIChannel
* 0x05687770, unsigned int 0) line 805
nsDocLoaderImpl::DocLoaderIsEmpty(unsigned int 0) line 612
nsDocLoaderImpl::DocLoaderIsEmpty(unsigned int 0) line 615
nsDocLoaderImpl::OnStopRequest(nsDocLoaderImpl * const 0x056bae74, nsIChannel *
0x05750260, nsISupports * 0x00000000, unsigned int 0, const unsigned short *
0x00000000) line 555
nsLoadGroup::RemoveChannel(nsLoadGroup * const 0x056bae10, nsIChannel *
0x05750260, nsISupports * 0x00000000, unsigned int 0, const unsigned short *
0x00000000) line 566 + 39 bytes
PresShell::RemoveDummyLayoutRequest() line 4921 + 44 bytes
PresShell::ReflowCommandRemoved(nsIReflowCommand * 0x05761060) line 4874
PresShell::ProcessReflowCommands(int 1) line 4694
ReflowEvent::HandleEvent() line 4579
HandlePLEvent(ReflowEvent * 0x05762cb0) line 4589
PL_HandleEvent(PLEvent * 0x05762cb0) line 580 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00aa8260) line 513 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x000f08b6, unsigned int 49424, unsigned int 0,
long 11174496) line 1049 + 9 bytes
USER32! 77e7124c()
00aa8260()
And here's where we eventually crash:
PresShell::~PresShell() line 1281 + 15 bytes
PresShell::`scalar deleting destructor'() + 15 bytes
PresShell::Release(PresShell * const 0x05657420) line 1199 + 158 bytes
nsCOMPtr<nsIPresShell>::~nsCOMPtr<nsIPresShell>() line 490
ReflowEvent::HandleEvent() line 4581 + 8 bytes
HandlePLEvent(ReflowEvent * 0x05762cb0) line 4589
PL_HandleEvent(PLEvent * 0x05762cb0) line 580 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00aa8260) line 513 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x000f08b6, unsigned int 49424, unsigned int 0,
long 11174496) line 1049 + 9 bytes
USER32! 77e7124c()
00aa8260()
Assignee | ||
Comment 5•24 years ago
|
||
Accepting. rtm+ since this is a crasher.
Status: NEW → ASSIGNED
Whiteboard: [rtm+]
Comment 6•24 years ago
|
||
PDT says rtm need info, editing frames not seen as critical functionality, would
consider a Really Small fix, but not worth much risk.
Whiteboard: [rtm+] → [rtm need info]
Reporter | ||
Comment 7•24 years ago
|
||
huh? Agreed that editing framed pages isn't a big deal (it's not even
supported), but we can't let the user crash if he clicks Edit Page in a page
that happens to be framed. This is a definite RTM blocker, if just to disabled
the menu item for framed pages...
Comment 8•24 years ago
|
||
I think the PDT's intent was that it would have to be a minimal change, for a
high benefit/risk ratio. No heroics or unnecessary logic, just stop the crash.
Note that this is rtm need info, not rtm-...
Comment 9•24 years ago
|
||
setting to m19, selecting to edit framed pages is a frequent activity. Simon, I
thought we had a pop-up dialog that stated we could not edit framed pages?
Target Milestone: --- → M19
Reporter | ||
Comment 10•24 years ago
|
||
We do have a dialog; the crash comes after you dismiss that dialog.
Assignee | ||
Comment 11•24 years ago
|
||
This looks hard. The crash is not in editor code, but occurs as layout tries to
send events to, and reflow a window which has been destroyed, since the editor,
after detecting the frameset, calls baseWindow->Destroy(); to close the window,
in its OnEndDocumentLoad method.
Assignee | ||
Comment 12•24 years ago
|
||
cc nisheeth. The dummy layout request and async reflow seems to be playing a role
here. Do we correctly cancel async reflow requests for windows that are being
torn down?
Reporter | ||
Comment 13•24 years ago
|
||
nisheeth?
Assignee | ||
Comment 14•24 years ago
|
||
This works on all 3 platforms on the branch. Moving to Mozilla for testing on the
trunk.
Comment 15•24 years ago
|
||
this works on all 3 platforms on 10/25 branch build.
Comment 16•24 years ago
|
||
When the above comments say "this works on 3 platforms" do you mean "this
crashes on 3 platforms" or this is "currently fixed on 3 platforms?"
I didn't see a fix... and then I saw repeated "works" comments :-/.
Is this bug works-for-me on branch??
Assignee | ||
Comment 17•24 years ago
|
||
Yes, it's worksforme on the branch. Tested in debug and release builds by 2
separate people.
Comment 18•24 years ago
|
||
I also could not reproduce this crash in my Mac, Linux, and Win32 debug
Netscape_20000922_BRANCH builds from Tuesday (10/24/00), though I am still
seeing the assertions thrown.
Comment 19•24 years ago
|
||
so, SImon can this bug be closed out now?
Reporter | ||
Comment 20•24 years ago
|
||
wfm in new builds
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•