Closed Bug 139568 Opened 22 years ago Closed 20 years ago

[FIX]ASSERT: nsFrameManager::GenerateStateKey didn't find content by type!: 'index > -1', file nsFrameManager.cpp, line 2261

Categories

(Core :: Layout, defect, P2)

x86
All
defect

Tracking

()

RESOLVED FIXED
mozilla1.8beta1

People

(Reporter: akkzilla, Assigned: bzbarsky)

References

(Depends on 1 open bug, )

Details

(Keywords: assertion, testcase, Whiteboard: [gmail])

Attachments

(2 files)

Load the indicated url.  See two of the indicated assertions.

Kin says he knows why it's happening and that it happens when going to a page
that has form elements without a <form> tag.  There are lots of documents like
that on the web.
Status: NEW → ASSIGNED
Changing priority to P2.
Priority: -- → P2
Blocks: 147322
The problem here is that the nsContentList is not updated by the time we get
here.  This is baaad.  This happens on Yahoo and Hotmail mail, for example.
Depends on: 144072
this happens on the layout regression tests too .....
http://lxr.mozilla.org/seamonkey/source/layout/html/tests/block/bugs/18445.html
Blocks: 152015
Keywords: testcase
Depends on: 166636
Blocks: 140697
Bulk moving P1-P5 un-milestoned bugs to future. 
Target Milestone: --- → Future
Attached file Testcase (click test)
Here's another testcase (from bug 194582)
Also happens in DOM TS data files on WinXP -> OS All

Asserts in http://dom-ts.bclary.com/build/ecmascript/level1/html/files/textarea.html

Does not Assert
http://dom-ts.bclary.com/build/ecmascript/level1/html/files/textarea.xhtml

Does not Assert
http://dom-ts.bclary.com/build/ecmascript/level1/html/files/textarea.xml

stack

NTDLL! 77f75a58()
nsDebugImpl::Assertion(nsDebugImpl * const 0x002e6d80, const char * 0x0162f5c0,
const char * 0x0162f5b4, const char * 0x0162f568, int 1496) line 272
nsDebug::Assertion(const char * 0x0162f5c0, const char * 0x0162f5b4, const char
* 0x0162f568, int 1496) line 109
nsContentUtils::GenerateStateKey(nsIContent * 0x03144328,
nsIStatefulFrame::SpecialStateID eNoID, nsACString & {...}) line 1496 + 32 bytes
nsGenericHTMLElement::GetLayoutHistoryAndKey(nsIHTMLContent * 0x03144328,
nsILayoutHistoryState * * 0x0012f680, nsACString & {...}) line 2281 + 15 bytes
nsGenericHTMLElement::RestoreFormControlState(nsIHTMLContent * 0x03144328,
nsIFormControl * 0x03144348) line 2303 + 37 bytes
nsHTMLTextAreaElement::DoneAddingChildren(nsHTMLTextAreaElement * const
0x0314435c) line 700 + 44 bytes
SinkContext::AddLeaf(const nsIParserNode & {...}) line 1567
HTMLContentSink::AddLeaf(HTMLContentSink * const 0x03b947c0, const nsIParserNode
& {...}) line 3213 + 18 bytes
CNavDTD::AddLeaf(const nsIParserNode * 0x03143d40) line 3787 + 25 bytes
CNavDTD::OpenContainer(const nsCParserNode * 0x03143d40, nsHTMLTag
eHTMLTag_textarea, int 1, nsEntryStack * 0x00000000) line 3423 + 12 bytes
CNavDTD::HandleDefaultStartToken(CToken * 0x03a4a510, nsHTMLTag
eHTMLTag_textarea, nsCParserNode * 0x03143d40) line 1457 + 20 bytes
CNavDTD::HandleStartToken(CToken * 0x03a4a510) line 1835 + 20 bytes
CNavDTD::HandleToken(CNavDTD * const 0x02f7f8c8, CToken * 0x00000000, nsIParser
* 0x03b945e8) line 1019 + 12 bytes
CNavDTD::BuildModel(CNavDTD * const 0x02f7f8c8, nsIParser * 0x03b945e8,
nsITokenizer * 0x031ed0c8, nsITokenObserver * 0x00000000, nsIContentSink *
0x03b947c0) line 511 + 20 bytes
nsParser::BuildModel(nsParser * const 0x03b945e8) line 1894 + 34 bytes
nsParser::ResumeParse(int 1, int 0, int 1) line 1761 + 12 bytes
nsParser::OnDataAvailable(nsParser * const 0x03b945ec, nsIRequest * 0x02f90a18,
nsISupports * 0x00000000, nsIInputStream * 0x03168d60, unsigned int 0, unsigned
int 938) line 2426 + 21 bytes
nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x03164f50,
nsIRequest * 0x02f90a18, nsISupports * 0x00000000, nsIInputStream * 0x03168d60,
unsigned int 0, unsigned int 938) line 343 + 46 bytes
nsHTTPCompressConv::do_OnDataAvailable(nsIRequest * 0x02f90a18, nsISupports *
0x00000000, unsigned int 0, char * 0x02f7f220, unsigned int 938) line 368 + 43 bytes
nsHTTPCompressConv::OnDataAvailable(nsHTTPCompressConv * const 0x0317e770,
nsIRequest * 0x02f90a18, nsISupports * 0x00000000, nsIInputStream * 0x0317e828,
unsigned int 0, unsigned int 451) line 291 + 31 bytes
nsStreamListenerTee::OnDataAvailable(nsStreamListenerTee * const 0x039b2f20,
nsIRequest * 0x02f90a18, nsISupports * 0x00000000, nsIInputStream * 0x03b1d6cc,
unsigned int 0, unsigned int 451) line 97 + 51 bytes
nsHttpChannel::OnDataAvailable(nsHttpChannel * const 0x02f90a20, nsIRequest *
0x03abd6b0, nsISupports * 0x00000000, nsIInputStream * 0x03b1d6cc, unsigned int
0, unsigned int 451) line 3457 + 63 bytes
nsInputStreamPump::OnStateTransfer() line 433 + 65 bytes
nsInputStreamPump::OnInputStreamReady(nsInputStreamPump * const 0x03abd6b4,
nsIAsyncInputStream * 0x03b1d6cc) line 336 + 11 bytes
nsInputStreamReadyEvent::EventHandler(PLEvent * 0x03abd794) line 119
PL_HandleEvent(PLEvent * 0x03abd794) line 673 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x009bd7e8) line 608 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00040110, unsigned int 49376, unsigned int 0,
long 10213352) line 1414 + 9 bytes
USER32! 77d43a50()
USER32! 77d43b1f()
USER32! 77d43d79()
USER32! 77d43ddf()
nsAppShellService::Run(nsAppShellService * const 0x00a59db8) line 524
main1(int 1, char * * 0x002e2638, nsISupports * 0x0099f2f0) line 1303 + 32 bytes
main(int 1, char * * 0x002e2638) line 1716 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e814c7()
Blocks: 233952
OS: Linux → All
this happens @gmail.com
Assignee: john → nobody
Status: ASSIGNED → NEW
QA Contact: chrispetersen → core.layout
Target Milestone: Future → ---
In my opinion this code all needs a careful look, especially at the assumptions
it's making...
Whiteboard: [gmail]
At this point we probably _could_ flush here (with bug 144072 fixed).  But even
then, the testcase would still assert (since it happens on a _remove_ from the
document).

So maybe the right thing to do is to fix the code to flush content and then
remove the assert...
Keywords: assertion
So maybe the really right thing to do here is to bail out if aContent is not in
a document?  After we've flushed content?
If it's interresting for you, I hit this problem when visiting
http://www.alzasoft.cz/Default.asp?CatID=18842837&TYPTREE=1


CSS Error (http://www.alzasoft.cz/Css/Default.css :6.118): Error in parsing
value for property 'cursor'.  Declaration dropped.
CSS Error (http://www.alzasoft.cz/Css/Default.css :53.69): Expected color but
found '#00000'.  Error in parsing value for property 'color'.  Declaration dropped.
CSS Error (http://www.alzasoft.cz/Css/Default.css :86.48): Error in parsing
value for property 'cursor'.  Declaration dropped.
++WEBSHELL == 11
++DOMWINDOW == 11
++WEBSHELL == 12
++DOMWINDOW == 12
###!!! ASSERTION: nsFrameManager::GenerateStateKey didn't find content by type!
See bug 139568: 'index > -1', file nsContentUtils.cpp, line 1509
Break: at file nsContentUtils.cpp, line 1509
###!!! ASSERTION: nsFrameManager::GenerateStateKey didn't find content by type!
See bug 139568: 'index > -1', file nsContentUtils.cpp, line 1509
Break: at file nsContentUtils.cpp, line 1509
###!!! ASSERTION: nsFrameManager::GenerateStateKey didn't find content by type!
See bug 139568: 'index > -1', file nsContentUtils.cpp, line 1509
Break: at file nsContentUtils.cpp, line 1509

Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject'
warning: attempted to CreateNative() width a non-superwin and non gtk container
parent

Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject'
warning: attempted to CreateNative() width a non-superwin and non gtk container
parent
For application/x-shockwave-flash found plugin
/home/mmokrejs/.mozilla/plugins/libflashplayer.so
LoadPlugin() /home/mmokrejs/.mozilla/plugins/libflashplayer.so returned b35b91f0
About to create new ws_info...
About to create new xtbin of 468 X 60 from 0xb3513348...
About to show xtbin(0xb301e528)...
completed gtk_widget_show(0xb301e528)
CSS Error (http://www.alzasoft.cz/Default.asp?CatID=18842837&TYPTREE=1 :0.12):
Error in parsing value for property 'cursor'.  Declaration dropped.
++WEBSHELL == 13
++DOMWINDOW == 13
CSS Error (http://www.alzasoft.cz/Default.asp?CatID=18842837&TYPTREE=1 :0.12):
Error in parsing value for property 'cursor'.  Declaration dropped.
--DOMWINDOW == 12
--DOMWINDOW == 11
WARNING: NS_ENSURE_TRUE(mSaveLayoutState || !aState) failed, file nsSHEntry.cpp,
line 191
Document http://www.alzasoft.cz/Default.asp?CatID=18842837&TYPTREE=1 loaded
successfully


Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a5) Gecko/20041029
Martin, we know that this happens and exactly why it happens. The question is
what this code _should_ be doing.

In general, pasting lots of irrelevant debug info into a bug is not at all
helpful...
Attached patch PatchSplinter Review
This is the right thing to do.	If this causes pageload issues, I'll remove the
flush, but the assert should go no matter what; it's bogus...
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #172218 - Flags: superreview?(jst)
Attachment #172218 - Flags: review?(jst)
Summary: ASSERT: nsFrameManager::GenerateStateKey didn't find content by type!: 'index > -1', file nsFrameManager.cpp, line 2261 → [FIX]ASSERT: nsFrameManager::GenerateStateKey didn't find content by type!: 'index > -1', file nsFrameManager.cpp, line 2261
Target Milestone: --- → mozilla1.8beta
Comment on attachment 172218 [details] [diff] [review]
Patch

>Index: content/base/src/nsContentUtils.cpp
>===================================================================

>   if (htmlDocument) {
>+    // Flush our content model so it'll be up to date
>+    aContent->GetDocument()->FlushPendingNotifications(Flush_Content);

GetCurrentDoc()?
Er, yes.  ;)
Comment on attachment 172218 [details] [diff] [review]
Patch

   nsCOMPtr<nsIHTMLDocument>
htmlDocument(do_QueryInterface(aContent->GetDocument()));

We probably want GetCurrentDoc() there too.

r+sr=jst
Attachment #172218 - Flags: superreview?(jst)
Attachment #172218 - Flags: superreview+
Attachment #172218 - Flags: review?(jst)
Attachment #172218 - Flags: review+
Fixed, with those changes.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
(In reply to comment #17)
> Fixed, with those changes.

Well, firefox 1.0.6-r5 on Gentoo still has this bug, and since it was fixed 9
months ago should it not have found its way into this version ?
Firefox 1.0.x is using Gecko from April 2004 (that's 18 months ago) with
security fixes only since then.  Since this was not a security fix, it wouldn't
appear in the 1.0.x series.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: