346094 - crash when setting repeat {display: table;} [@ nsHTMLReflowState::Init]

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Steve Speicher]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060719 Minefield/3.0a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060719 Minefield/3.0a1

Given a simple/typical use of repeat, mixed in a table.  Attempting to use a <table> and the first row as headers.  By adding the style rule:
  xforms|repeat {display: table;}
causing browser to crash (Firefox 1.5.0.5 w/ 0.6 and Minefield trunk build 2006-07-20)

Reproducible: Always

Comment 1

[Steve Speicher]

Attachment: test case

Comment 2

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060726 Minefield/3.0a1
Should the testcase crash on load? It does not crash for me.

Comment 3

[aaronr]

(In reply to comment #2)
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060726
> Minefield/3.0a1
> Should the testcase crash on load? It does not crash for me.
> 

I'm guessing that you don't build XForms and that is probably why you don't see the crash.    I've recreated this on yesterday's trunk.  The crash is deep in gklayout.  I'll see if I can create a testcase that traps w/o XForms.

Comment 4

[Adam Guthrie]

Attachment: stack from Talkback

Comment 5

[aaronr]

(In reply to comment #3)
> (In reply to comment #2)
> > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060726
> > Minefield/3.0a1
> > Should the testcase crash on load? It does not crash for me.
> > 
> 
> I'm guessing that you don't build XForms and that is probably why you don't see
> the crash.    I've recreated this on yesterday's trunk.  The crash is deep in
> gklayout.  I'll see if I can create a testcase that traps w/o XForms.
> 

No luck.  But it is releated to how we implement xf:input somehow.

Comment 6

[Martijn Wargers (dead)]

Attachment: testcase

I get this crash (talkback ID: TB23001123G ) with this testcase. No xforms involved here, but you need to have caret browsing turned on to get the crash.
This doesn't crash on branch, but that's probably because the marquee that is being used in the testcase, has changed on trunk.

Comment 7

[Martijn Wargers (dead)]

Bug 228557 seems related. If desired, I can try to reduce the marquee binding also.

Comment 8

[Bernd]

the testcase causes:

###!!! ASSERTION: reflowing in the middle of frame construction: 'mPresContext->
mLayoutPhaseCount[eLayoutPhase_FrameC] == 0', file d:\moz_src\mozilla\layout\bas
e\nsPresContext.h, line 845
###!!! ASSERTION: Frame construction error, a table cell always has an inner cel
l frame: 'firstKid', file d:/moz_src/mozilla/layout/tables/nsTableCellFrame.cpp,
 line 793

so it seems that the reflow interrupts the frame construction and the table cell does not get the inner block.

Comment 9

[Bernd]

removing the xbl would be a benefit

Comment 10

[Martijn Wargers (dead)]

Attachment: binding

I doesn't seem I can remove the binding, I need this javascript in the constructor:
 document.getAnonymousElementByAttribute(this, 'class', 'innerDiv').style.padding = 0;
Maybe this bug depends on bug 267833?

Comment 11

[Martijn Wargers (dead)]

Attachment: testcase

Comment 12

[Martijn Wargers (dead)]

Ok, I don't get the testcase that I just attached to crash online, you need to download that testcase locally to get the crash. Usually, it crashes when pressing the 'Go' button a few times.

Boris, maybe this bug depends on bug 267833? (seems like it does to me)

Comment 13

[Boris Zbarsky [:bzbarsky]]

> ###!!! ASSERTION: reflowing in the middle of frame construction:

With what stack?  We should sort this out before bothering with anything else.

For what it's worth, I don't get a crash on the latest testcase in this bug (saved locally, reloaded a bunch).  I do get a GTK2 widget assert....

Comment 14

[Bernd]

stack for attachment 237121 [details]

 	ntdll.dll!7c911230() 	
 	[Unten angegebene Rahmen sind möglicherweise nicht korrekt und/oder fehlen, keine Symbole geladen für ntdll.dll]	
>	xpcom_core.dll!Break(const char * aMsg=0x0012b8ec)  Zeile 471	C++
 	xpcom_core.dll!NS_DebugBreak_P(unsigned int aSeverity=0x00000001, const char * aStr=0x026dd124, const char * aExpr=0x026dd1c0, const char * aFile=0x026dcadc, int aLine=0x0000034d)  Zeile 350 + 0xc Bytes	C++
 	gklayout.dll!nsAutoLayoutPhase::Enter()  Zeile 844 + 0x2a Bytes	C++
 	gklayout.dll!nsAutoLayoutPhase::nsAutoLayoutPhase(nsPresContext * aPresContext=0x0413a528, nsLayoutPhase aPhase=eLayoutPhase_Reflow)  Zeile 820	C++
 	gklayout.dll!PresShell::ProcessReflowCommands(int aInterruptible=0x00000000)  Zeile 6518	C++
 	gklayout.dll!PresShell::FlushPendingNotifications(mozFlushType aType=Flush_OnlyReflow)  Zeile 5175	C++
 	gklayout.dll!nsTypedSelection::ScrollIntoView(short aRegion=0x0001, int aIsSynchronous=0x00000001)  Zeile 7389	C++
 	gklayout.dll!nsFrameSelection::ScrollSelectionIntoView(short aType=0x0001, short aRegion=0x0001, int aIsSynchronous=0x00000001)  Zeile 2526	C++
 	gklayout.dll!PresShell::ScrollSelectionIntoView(short aType=0x0001, short aRegion=0x0001, int aIsSynchronous=0x00000001)  Zeile 2703	C++
 	gklayout.dll!PresShell::CompleteMove(int aForward=0x00000000, int aExtend=0x00000000)  Zeile 3445 + 0x14 Bytes	C++
 	gklayout.dll!nsEventStateManager::SetContentCaretVisible(nsIPresShell * aPresShell=0x041dbf68, nsIContent * aFocusedContent=0x00000000, int aVisible=0x00000001)  Zeile 5259	C++
 	gklayout.dll!nsEventStateManager::ResetBrowseWithCaret()  Zeile 5323	C++
 	gklayout.dll!nsEventStateManager::PreHandleEvent(nsPresContext * aPresContext=0x0413a528, nsEvent * aEvent=0x0012c4cc, nsIFrame * aTargetFrame=0x04b1faa8, nsEventStatus * aStatus=0x0012c2e0, nsIView * aView=0x03bc7be8)  Zeile 864	C++
 	gklayout.dll!PresShell::HandleEventInternal(nsEvent * aEvent=0x0012c4cc, nsIView * aView=0x03bc7be8, nsEventStatus * aStatus=0x0012c2e0)  Zeile 6158 + 0x36 Bytes	C++
 	gklayout.dll!PresShell::HandleEvent(nsIView * aView=0x03bc7be8, nsGUIEvent * aEvent=0x0012c4cc, nsEventStatus * aEventStatus=0x0012c2e0)  Zeile 5952 + 0x17 Bytes	C++
 	gklayout.dll!nsViewManager::HandleEvent(nsView * aView=0x03bc7be8, nsPoint aPoint={...}, nsGUIEvent * aEvent=0x0012c4cc, int aCaptured=0x00000000)  Zeile 1668	C++
 	gklayout.dll!nsViewManager::DispatchEvent(nsGUIEvent * aEvent=0x0012c4cc, nsEventStatus * aStatus=0x0012c408)  Zeile 1621 + 0x22 Bytes	C++
 	gklayout.dll!HandleEvent(nsGUIEvent * aEvent=0x0012c4cc)  Zeile 174	C++
 	gkwidget.dll!nsWindow::DispatchEvent(nsGUIEvent * event=0x0012c4cc, nsEventStatus & aStatus=nsEventStatus_eIgnore)  Zeile 1108 + 0xc Bytes	C++
 	gkwidget.dll!nsWindow::DispatchWindowEvent(nsGUIEvent * event=0x0012c4cc)  Zeile 1129	C++
 	gkwidget.dll!nsWindow::DispatchFocus(unsigned int aEventType=0x00000069, int isMozWindowTakingFocus=0x00000001)  Zeile 6320 + 0x11 Bytes	C++
 	gkwidget.dll!nsWindow::ProcessMessage(unsigned int msg=0x00000007, unsigned int wParam=0x00060516, long lParam=0x00000000, long * aRetValue=0x0012c8d0)  Zeile 4841 + 0x19 Bytes	C++
 	gkwidget.dll!nsWindow::WindowProc(HWND__ * hWnd=0x00060696, unsigned int msg=0x00000007, unsigned int wParam=0x00060516, long lParam=0x00000000)  Zeile 1297 + 0x1d Bytes	C++
 	user32.dll!77d18734() 	
 	user32.dll!77d18816() 	
 	user32.dll!77d1b4c0() 	
 	user32.dll!77d1b50c() 	
 	ntdll.dll!7c91eae3() 	
 	user32.dll!77d194be() 	
 	user32.dll!77d1bfe9() 	
 	user32.dll!77d1b3f9() 	
 	user32.dll!77d1b393() 	
 	gkwidget.dll!nsWindow::DefaultWindowProc(HWND__ * hWnd=0x00060696, unsigned int msg=0x00000006, unsigned int wParam=0x00000001, long lParam=0x001a02d2)  Zeile 1318	C++
 	user32.dll!77d18734() 	
 	user32.dll!77d18816() 	
 	gkwidget.dll!nsBaseWidget::QueryInterface(const nsID & aIID={...}, void * * aInstancePtr=0x00060696)  Zeile 66 + 0x84 Bytes	C++
 	user32.dll!77d1c63f() 	
 	user32.dll!77d1c665() 	
 	gkwidget.dll!nsWindow::WindowProc(HWND__ * hWnd=0x041dc4e4, unsigned int msg=0x0012ccac, unsigned int wParam=0x03082ed8, long lParam=0x00000000)  Zeile 1304 + 0x1f Bytes	C++
 	nspr4.dll!PR_GetCurrentThread()  Zeile 175	C
 	gkwidget.dll!0308b5c7() 	
 	gkwidget.dll!03029def() 	
 	4d890cec()	

Comment 15

[Bernd]

this happens as NS_FOCUS_EVENT with NS_GOTFOCUS is translated and calls ResetBrowseWithCaret which at the very end leads to https://bugzilla.mozilla.org/show_bug.cgi?id=252970#c97

Comment 16

[Boris Zbarsky [:bzbarsky]]

Er... I see no frame construction code on that stack.

Comment 17

[Bernd]

its only that mPresContext->mLayoutPhaseCount[eLayoutPhase_FrameC] is one when we enter reflow

Comment 18

[Boris Zbarsky [:bzbarsky]]

Yes, but the ONLY way that can be the case is if we're in frame construction code right now.  So what code is that?  More to the point, what's spinning the native event queue under frame construction code (which is what your stack is showing)?

timeless, David, I seem to recall you had ways of going up the stack past the nsWindow::WindowProc thing on Windows, right?

Comment 19

[Jesse Ruderman]

> what's spinning the native event queue under frame construction code?

Should there be an assertion to catch bugs like that earlier?  (Similar in spirit to the "reflowing in the middle of frame construction" assertion we do hit eventually in this bug.)

Comment 20

[Boris Zbarsky [:bzbarsky]]

> Should there be an assertion to catch bugs like that earlier?

Yeah, I'd love to put an assertion into the Windows code.  Too bad it's not in our CVS.  ;)

I suppose we could try asserting in widget, but it'd take some apis to do that....

Comment 21

[Bernd]

wfm with my pretty old debug build. Is this still an issue?

Comment 22

[Martijn Wargers (dead)]

The testcases I attached became worksforme between 2006-11-06 and 2006-11-07:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-11-06+04&maxdate=2006-11-07+09&cvsroot=%2Fcvsroot
I think that was fixed by the backout from bug 144000.

I've tried to test the crash with the xforms example, but I can't really test.
I'm not sure which xforms extension I should use.

Comment 23

[Bernd]

Closing the bug as WFM. I did see the crash with the test cases and now it is gone.

Comment 24

[Jesse Ruderman]

The backed-out patch in bug 144000 just places the caret/selection somewhere, which is something that content can do.  If you make your testcase do that, can you still get the crash?

Comment 25

[Martijn Wargers (dead)]

Well, I tried something similar in bug 351485 and failed. I guess I could try it again for this bug.