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)

x86
Windows 98
defect

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()
nominating for rtm since I see this on many pages. cc'ing some people since beppe is away, i think.
Keywords: crash, rtm
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
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()
Accepting. rtm+ since this is a crasher.
Status: NEW → ASSIGNED
Whiteboard: [rtm+]
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]
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...
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-...
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
We do have a dialog; the crash comes after you dismiss that dialog.
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.
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?
nisheeth?
This works on all 3 platforms on the branch. Moving to Mozilla for testing on the trunk.
Keywords: rtm
Whiteboard: [rtm need info]
Target Milestone: M19 → mozilla0.9
this works on all 3 platforms on 10/25 branch build.
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??
Yes, it's worksforme on the branch. Tested in debug and release builds by 2 separate people.
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.
so, SImon can this bug be closed out now?
wfm in new builds
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
verified in 1/12 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.