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

VERIFIED FIXED

Status

()

defect
--
critical
VERIFIED FIXED
13 years ago
12 years ago

People

(Reporter: martijn.martijn, Assigned: sicking)

Tracking

(7 keywords)

Dependency tree / graph
Bug Flags:
blocking1.7.14 ?
blocking-aviary1.0.9 ?
blocking1.8.0.3 +
blocking1.8.0.4 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:critical?] midas, )

Attachments

(3 attachments)

Reporter

Description

13 years ago
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.
Reporter

Comment 1

13 years ago
Posted file testcase
Reporter

Comment 2

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

Comment 3

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

Updated

13 years ago
Whiteboard: midas
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.
Group: security
Flags: blocking1.9a1?
Flags: blocking1.8.1?
Flags: blocking1.8.0.3?
Keywords: helpwanted
OS: Windows XP → All
Hardware: PC → All
Whiteboard: midas → [sg:critical?] midas
Very possibly; the setup is different, but the result looks similar...
Depends on: 211348
(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

I'm sorry, it's a year-old regression, not just a couple weeks back.
A baked 1.8.0.3 fixed doesn't seem realistic, please help us make 1.8.0.4
Flags: blocking1.8.0.4?
Flags: blocking1.8.0.3?
Flags: blocking1.8.0.3-
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
Flags: blocking1.8.0.3- → blocking1.8.0.3?
Flags: blocking1.8.0.3? → blocking1.8.0.3+
Bug is misassigned -- who should own it?

/be
I'll have a stab at this one.
Assignee: mozeditor → bugmail
This was also posted to Bugtraq
http://www.securityfocus.com/archive/1/431878/30/0/threaded

The securident PoC page is gone now, though.
The securident PoC code is now on milw0rm
http://www.milw0rm.com/exploits/1716
Flags: blocking1.8.0.5? → blocking1.8.0.3+

Comment 16

13 years ago
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
This has been fixed by the patch in bug 334515
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED

Comment 18

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

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

Comment 20

13 years ago
(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.

> 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?
Reporter

Comment 23

13 years ago
(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.

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 ;-)
Status: RESOLVED → VERIFIED
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
Don't know if another bug ever got filed on the issue in comment 19, but now there's bug 343686
Reporter

Comment 27

13 years ago
Bug 343686 is basically the same as bug 287707.
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.
Flags: blocking1.7.14?
Flags: blocking-aviary1.0.9?

Comment 30

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

Flags: blocking1.9a1?
Flags: blocking1.8.1?
Group: security
You need to log in before you can comment on or make changes to this bug.