Closed Bug 331981 Opened 19 years ago Closed 19 years ago

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

Categories

(Core :: DOM: Editor, defect)

defect
Not set
critical

Tracking

()

VERIFIED FIXED

People

(Reporter: martijn.martijn, Assigned: sicking)

References

()

Details

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

Attachments

(3 files)

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.
Attached file testcase
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
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+
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
Closed: 19 years ago
Resolution: --- → FIXED
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.
> 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.
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
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?
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.

Attachment

General

Created:
Updated:
Size: