331981 - Crash on reload when setting designMode while loading a large piece of junk

Status: VERIFIED FIXED

Description

[Martijn Wargers (zombie)]

See upcoming testcase.

To reproduce:
- Load testcase.
- Click back
- Click on the 'Go' button.

Result: crash

Talkback ID: TB16953744W
nsQueryInterface::operator()   nsCOMPtr<nsIEditor>::nsCOMPtr<nsIEditor>   nsControllerCommandTable::IsCommandEnabled   nsBaseCommandController::IsCommandEnabled   XPTC_InvokeByIndex   XPCWrappedNative::CallMethod

The testcase contains a lot of junk html, but that seems necessary to trigger the crash. I doubt that minimising it will help anything.
It seems to me that you shouldn't be able to set designMode while the document is loading.

This is a regression.
It doesn't crash in a 2005-04-05 build, it does crash in a 2005-04-06 build, so my bet is on bug 283897.

Comment 1

[Martijn Wargers (zombie)]

Attachment: testcase

Comment 2

[Martijn Wargers (zombie)]

When viewing from bugzilla, I crash directly with the testcase.

Comment 3

[Hermann Schwab]

Attachment: Talkback Record of testcase crashing onload

TB16990609W crash loading the testcase
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060328 SeaMonkey/1.5a

Comment 4

[Boris Zbarsky [:bzbarsky, bz on IRC]]

We're crashing because in nsCutCommand::IsCommandEnabled the aCommandRefCon is dead.  The nsBaseCommandController in question has a dead mCommandContext member.  so someone somewhere forgot to unset the context.  By logging pointers, I can tell that the context used to be an nsHTMLEditor set from nsEditingSession::SetContextOnControllerById, called from (eventually) nsHTMLDocument::SetDesignMode.

Note that this testcase asserts for me:

###!!! ASSERTION: bad action nesting!: 'mActionNesting>0', file ../../../../mozilla/editor/libeditor/html/nsHTMLEditRules.cpp, line 386

so maybe that's of help?

In any case, we need to fix this on branches.  We crash when calling QI on the dead editor.

Comment 5

[Simon Fraser [no longer active]]

Dup of bug 211348?

Comment 6

[Boris Zbarsky [:bzbarsky, bz on IRC]]

Very possibly; the setup is different, but the result looks similar...

Comment 7

[Daniel Veditz [:dveditz]]

(In reply to comment #5)
> Dup of bug 211348?

Martijn gives it a very small and very recent regression window which doesn't jibe with being a dupe of 211348

Comment 8

[Daniel Veditz [:dveditz]]

I'm sorry, it's a year-old regression, not just a couple weeks back.

Comment 9

[Daniel Veditz [:dveditz]]

A baked 1.8.0.3 fixed doesn't seem realistic, please help us make 1.8.0.4

Comment 10

[Daniel Veditz [:dveditz]]

This seems to be the same crash described by the vuln posting http://www.securident.com/vuln/ff.txt linked to from http://forums.mozillazine.org/viewtopic.php?t=408603

Re-nominating for 1.8.0.3

Comment 11

[Brendan Eich [:brendan]]

Bug is misassigned -- who should own it?

/be

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'll have a stab at this one.

Comment 13

[Daniel Veditz [:dveditz]]

This was also posted to Bugtraq
http://www.securityfocus.com/archive/1/431878/30/0/threaded

The securident PoC page is gone now, though.

Comment 14

[Daniel Veditz [:dveditz]]

The securident PoC code is now on milw0rm
http://www.milw0rm.com/exploits/1716

Comment 15

[Daniel Veditz [:dveditz]]

Attachment: securident PoC -- may have to click/drag to crash

Comment 16

[Bob Clary [:bc:]]

I can confirm no crash in attachment 216535 [details], attachment 219711 [details] with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3

Comment 17

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

This has been fixed by the patch in bug 334515

Comment 18

[Bob Clary [:bc:]]

I am not crashing in windows or macppc with today's en-us builds, but once the test case is run, any subsequent site loaded into the window is editable. We had a bug like that before, but wasn't it fixed?

Comment 19

[Bob Clary [:bc:]]

(In reply to comment #18)
FWIW, I can edit other pages by using ff108/win on the testcase and then visiting another page.

Comment 20

[Martijn Wargers (zombie)]

(In reply to comment #19)
> (In reply to comment #18)
> FWIW, I can edit other pages by using ff108/win on the testcase and then
> visiting another page.
I can see this too with 2006-04-27 trunk build on windows. This is definately a regression.

Comment 21

[Bob Clary [:bc:]]

Note, I don't see the problem in <http://devedge-temp.mozilla.org/viewsource/2003/midas/01/example1.html>

Comment 22

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

> I can see this too with 2006-04-27 trunk build on windows. This is definately a
> regression.

How can you tell it's a regression since we used to crash on the page?

Comment 23

[Martijn Wargers (zombie)]

(In reply to comment #22)
> How can you tell it's a regression since we used to crash on the page?
Sorry, my testing was flawed. I thought I saw this on every document that had designMode on. Please ignore comment 20.

Comment 24

[Stephen Donner [:stephend]]

Crash is verified FIXED using build 2006-04-29-05 of SeaMonkey trunk under Windows XP; Martijn has filed a plethora of specific bugs about designMode which cover its funky behavior ;-)

Comment 25

[Tracy Walker [:tracy]]

verified testcase doesn't crash: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060504 Firefox/1.5.0.4

Comment 26

[Daniel Veditz [:dveditz]]

Don't know if another bug ever got filed on the issue in comment 19, but now there's bug 343686

Comment 27

[Martijn Wargers (zombie)]

Bug 343686 is basically the same as bug 287707.

Comment 28

[Daniel Veditz [:dveditz]]

There are reports that this does affect the Mozilla 1.7 branch, which would seem to be supported by the fact that this bug was marked depending on bug 211348.

Comment 29

[Daniel Veditz [:dveditz]]

Specifically, the Browser Fun testcase #4 crashes the suite: http://browserfun.blogspot.com/2006/07/mobb-4-mozilla-firefox-designmode.html

Comment 30

[Bob Clary [:bc:]]

http://metasploit.com/users/hdm/tools/browserfun/mobb_004.html
ff2b2 windows, linux, macppc no crash

https://bugzilla.mozilla.org/attachment.cgi?id=216535
ff2b2 windows, linux, macppc no crash

https://bugzilla.mozilla.org/attachment.cgi?id=219711
ff2b2 windows, linux, macppc no crash