Crash trying to edit framed pages in Composer

VERIFIED WORKSFORME

Status

()

Core
Editor
P3
critical
VERIFIED WORKSFORME
18 years ago
17 years ago

People

(Reporter: Blake Ross, Assigned: Simon Fraser)

Tracking

({crash})

Trunk
mozilla0.9
x86
Windows 98
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

18 years ago
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

18 years ago
nominating for rtm since I see this on many pages.  cc'ing some people since 
beppe is away, i think.
Keywords: crash, rtm
(Reporter)

Comment 2

18 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

18 years ago
Is this just a crash, or an assertion? And, please test the branch.
Assignee: beppe → sfraser

Comment 4

18 years ago
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

18 years ago
Accepting. rtm+ since this is a crasher.
Status: NEW → ASSIGNED
Whiteboard: [rtm+]

Comment 6

18 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

18 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

18 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

18 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

18 years ago
We do have a dialog; the crash comes after you dismiss that dialog.
(Assignee)

Comment 11

18 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

18 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

18 years ago
nisheeth?
(Assignee)

Comment 14

18 years ago
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

Comment 15

18 years ago
this works on all 3 platforms on 10/25 branch build.

Comment 16

18 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

18 years ago
Yes, it's worksforme on the branch. Tested in debug and release builds by 2 
separate people.

Comment 18

18 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

18 years ago
so, SImon can this bug be closed out now?
(Reporter)

Comment 20

18 years ago
wfm in new builds
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME

Comment 21

18 years ago
verified in 1/12 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.