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)
Core
DOM: Editor
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.
Reporter | ||
Comment 1•19 years ago
|
||
Reporter | ||
Comment 2•19 years ago
|
||
When viewing from bugzilla, I crash directly with the testcase.
Comment 3•19 years ago
|
||
TB16990609W crash loading the testcase
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060328 SeaMonkey/1.5a
Updated•19 years ago
|
Whiteboard: midas
![]() |
||
Comment 4•19 years ago
|
||
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
Updated•19 years ago
|
Whiteboard: midas → [sg:critical?] midas
Comment 5•19 years ago
|
||
Dup of bug 211348?
![]() |
||
Comment 6•19 years ago
|
||
Very possibly; the setup is different, but the result looks similar...
Depends on: 211348
Comment 7•19 years ago
|
||
(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•19 years ago
|
||
I'm sorry, it's a year-old regression, not just a couple weeks back.
Comment 9•19 years ago
|
||
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-
Comment 10•19 years ago
|
||
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?
Updated•19 years ago
|
Flags: blocking1.8.0.3? → blocking1.8.0.3+
Comment 11•19 years ago
|
||
Bug is misassigned -- who should own it?
/be
Comment 13•19 years ago
|
||
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•19 years ago
|
||
The securident PoC code is now on milw0rm
http://www.milw0rm.com/exploits/1716
Comment 15•19 years ago
|
||
Updated•19 years ago
|
Flags: blocking1.8.0.5? → blocking1.8.0.3+
Comment 16•19 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
Assignee | ||
Comment 17•19 years ago
|
||
This has been fixed by the patch in bug 334515
Comment 18•19 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•19 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•19 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.
Comment 21•19 years ago
|
||
Note, I don't see the problem in <http://devedge-temp.mozilla.org/viewsource/2003/midas/01/example1.html>
Assignee | ||
Comment 22•19 years ago
|
||
> 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•19 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.
Assignee | ||
Updated•19 years ago
|
Keywords: fixed1.8.0.4
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
Comment 25•19 years ago
|
||
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•19 years ago
|
||
Don't know if another bug ever got filed on the issue in comment 19, but now there's bug 343686
Reporter | ||
Comment 27•19 years ago
|
||
Bug 343686 is basically the same as bug 287707.
Comment 28•19 years ago
|
||
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 29•19 years ago
|
||
Specifically, the Browser Fun testcase #4 crashes the suite: http://browserfun.blogspot.com/2006/07/mobb-4-mozilla-firefox-designmode.html
Comment 30•19 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
Keywords: fixed1.8.1 → verified1.8.1
![]() |
||
Updated•19 years ago
|
Flags: blocking1.9a1?
![]() |
||
Updated•19 years ago
|
Flags: blocking1.8.1?
Updated•18 years ago
|
Group: security
You need to log in
before you can comment on or make changes to this bug.
Description
•