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.
When viewing from bugzilla, I crash directly with the testcase.
TB16990609W crash loading the testcase Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060328 SeaMonkey/1.5a
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.
OS: Windows XP → All
Hardware: PC → All
Dup of bug 211348?
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 220.127.116.11 fixed doesn't seem realistic, please help us make 18.104.22.168
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 22.214.171.124
Flags: blocking126.96.36.199- → blocking188.8.131.52?
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
13 years ago
Depends on: 334515
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:184.108.40.206) Gecko/20060426 Firefox/220.127.116.11
This has been fixed by the patch in bug 334515
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?
(In reply to comment #18) FWIW, I can edit other pages by using ff108/win on the testcase and then visiting another page.
(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.
Note, I don't see the problem in <http://devedge-temp.mozilla.org/viewsource/2003/midas/01/example1.html>
> 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?
(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.
13 years ago
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:18.104.22.168) Gecko/20060504 Firefox/22.214.171.124
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.
Specifically, the Browser Fun testcase #4 crashes the suite: http://browserfun.blogspot.com/2006/07/mobb-4-mozilla-firefox-designmode.html
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
You need to log in before you can comment on or make changes to this bug.