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

RESOLVED WORKSFORME

Status

()

--
critical
RESOLVED WORKSFORME
12 years ago
7 years ago

People

(Reporter: sspeiche, Unassigned)

Tracking

({crash, testcase})

Trunk
crash, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(5 attachments)

(Reporter)

Description

12 years ago
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
(Reporter)

Comment 1

12 years ago
Created attachment 230893 [details]
test case

Updated

12 years ago
Keywords: crash, testcase
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

12 years ago
(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.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 4

12 years ago
Created attachment 231023 [details]
stack from Talkback

Updated

12 years ago
Severity: normal → critical
Summary: crash when setting repeat {display: table;} → crash when setting repeat {display: table;} [@ nsHTMLReflowState::Init]

Updated

12 years ago
Assignee: xforms → nobody
Component: XForms → Layout
OS: Windows XP → All
QA Contact: spride → layout
Hardware: PC → All

Comment 5

12 years ago
(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.
Created attachment 237121 [details]
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.
Bug 228557 seems related. If desired, I can try to reduce the marquee binding also.
Blocks: 228557

Comment 8

12 years ago
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

12 years ago
removing the xbl would be a benefit
Created attachment 244669 [details]
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?
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)
> ###!!! 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

12 years ago
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

12 years ago
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
Er... I see no frame construction code on that stack.

Comment 17

12 years ago
its only that mPresContext->mLayoutPhaseCount[eLayoutPhase_FrameC] is one when we enter reflow
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

12 years ago
> 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.)
> 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

12 years ago
wfm with my pretty old debug build. Is this still an issue?
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

12 years ago
Closing the bug as WFM. I did see the crash with the test cases and now it is gone.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME

Comment 24

12 years ago
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?
Well, I tried something similar in bug 351485 and failed. I guess I could try it again for this bug.
(Assignee)

Updated

7 years ago
Crash Signature: [@ nsHTMLReflowState::Init]
You need to log in before you can comment on or make changes to this bug.