Closed Bug 88849 Opened 24 years ago Closed 24 years ago

Crash after pressing left arrow key in textbox.- Trunk & N610 [@ nsBlockFrame::CreateContinuationFor]

Categories

(Core :: Layout: Form Controls, defect, P1)

Product:
Core
Component:
Layout: Form Controls
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.2

People

(Reporter: thorgal, Assigned: attinasi)

References

(
URL
)

Details

(Keywords: crash, testcase, topcrash, Whiteboard: PDT+)

Crash Data

Attachments

(4 files)

Testcase as html-file
253 bytes, text/html
Details
Stack from a linux 20010701 14:13 cvs build using the testcase.
3.07 KB, text/plain
Details
Minimal Test Case (Slightly more minimal than Bug 89259)
187 bytes, text/html
Details
Patch to prevent the crash by checking if a frame is a rowFrame before casting to it
1.09 KB, patch
Details | Diff | Splinter Review
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2+) Gecko/20010701 BuildID: 2001070121 After pressing SHIFT and LEFT ARROW key in one of the three textboxes on this page mozilla crashes. Reproducible: Always Steps to Reproduce: 1.Visit above URL 2.Enter one of the three text input boxes 3.Press Shift and LeftArrow. Actual Results: Crash. Expected Results: Nothing or cursor should be moved to the left of text input box. Also happens in 0.9.2 under Linux and Windows.
Confirmed on 2001070108 W2k
Here it is : <table> <tr></tr> <form> <tr><td> <input> </td></tr> </form> </table> The problem occurs if - <FORM> starts in <TABLE> - <FORM> isn't the first element in <TABLE>
Keywords: testcase
Keywords: crash
Attached file Testcase as html-file —
win2k stack trace : nsBlockFrame::CreateContinuationFor(nsBlockReflowState & {...}, nsLineBox * 0x00000000, nsIFrame * 0x03a1278c, int & 0) line 3616 + 15 bytes nsTableRowGroupFrame::FindLineContaining(nsTableRowGroupFrame * const 0x03982dbc, nsIFrame * 0x03a1278c, int * 0x0012e09c) line 1620 + 14 bytes nsFrame::GetFrameFromDirection(nsFrame * const 0x0394fc20, nsIPresContext * 0x0380d5a0, nsPeekOffsetStruct * 0x0012e2d8) line 3759 + 40 bytes nsFrame::PeekOffset(nsFrame * const, nsIPresContext *, nsPeekOffsetStruct *) line 3286 + 23 bytes
Severity: major → critical
Yup, crashed on 0.9.2 linux, and i got a talkback for you TB32438438X
Updating summary (it happens with only the left key also)
Summary: Crash after pressing SHIFT-LEFTARROW in textbox. → Crash after pressing left arrow key in textbox.
*** Bug 89259 has been marked as a duplicate of this bug. ***
Guys please see bug 89259 It has a much better testcase, it crashes on ANY key I duped that one to here, if it's different, please reopen Also, i filed talkback on that one It's TB32517396G
*** Bug 89351 has been marked as a duplicate of this bug. ***
Adding signature and cc'ing talkback folks. Adding talkback keyword topcrash for talkback tracking.
Keywords: topcrash
Summary: Crash after pressing left arrow key in textbox. → Crash after pressing left arrow key in textbox. [@ nsBlockFrame::CreateContinuationFor]
Taking this bug. Rod is on sabbatical and I can dup it on Windows and Linux (but not Mac for some reason)
Assignee: rods → attinasi
It looks like the second FORM is getting put into the generated TBODY instead of into the TABLE and that is illegal and unexpected in the table code. Talking to Harish, he says that it should be fixed and that he thinks he knows how to do it, so sending it to him. FYI: I noticed that if the form that is opened before the TABLE is closed outside the table instead of inside of it, then the problem of the FORM being put into the TBODY goes away as well.
Assignee: attinasi → harishd
Priority: -- → P1
Target Milestone: --- → mozilla0.9.2
<HTML> <BODY> <TABLE> <TBODY> <FORM><INPUT name=LoginID value="0"> </BODY> </HTML> This causes a crash too!. Note: According to spec. TBODY can contain nothing other than TR. <!ELEMENT TBODY O O (TR)+ --table body --> However, we have always allowed FORMs to contain anywhere in the document for backwards compatibility. And apparently, the above test case does not crash Netscape 6.1 PR1. This is a regression but I'm positive it's not in the parser because nothing much has changed in this area since PR1.
Status: NEW → ASSIGNED
*** Bug 90653 has been marked as a duplicate of this bug. ***
stact right before crashing: nsTextFrame::PeekOffset(nsTextFrame * const 0x02930fa4, nsIPresContext * 0x03bc1300, nsPeekOffsetStruct * 0x0012e360) line 3933 nsSelection::MoveCaret(unsigned int 39, int 0, nsSelectionAmount eSelectCharacter) line 1571 + 41 bytes nsSelection::CharacterMove(nsSelection * const 0x03bce7b0, int 1, int 0) line 2941 + 16 bytes nsTextInputSelectionImpl::CharacterMove(nsTextInputSelectionImpl * const 0x03bcec98, int 1, int 0) line 833 + 34 bytes nsSelectionMoveCommands::DoCommand(nsSelectionMoveCommands * const 0x0417cc00, const nsAString & {???}, nsISupports * 0x03bcef20) line 381 + 39 bytes nsControllerCommandManager::DoCommand(nsControllerCommandManager * const 0x0417bb00, const nsAString & {???}, nsISupports * 0x03bcef20) line 183 + 31 bytes nsEditorController::DoCommand(nsEditorController * const 0x03bcf2b0, const nsAString & {???}) line 192 nsXBLPrototypeHandler::ExecuteHandler(nsXBLPrototypeHandler * const 0x04149240, nsIDOMEventReceiver * 0x03acd2d0, nsIDOMEvent * 0x0492de04) line 310 DoKey(nsIAtom * 0x02f97a30, nsIXBLPrototypeHandler * 0x04149240, nsIDOMEvent * 0x0492de04, nsIDOMEventReceiver * 0x03acd2d0) line 92 nsXBLKeyHandler::KeyPress(nsXBLKeyHandler * const 0x03acd360, nsIDOMEvent * 0x0492de04) line 107 + 40 bytes nsEventListenerManager::HandleEvent(nsEventListenerManager * const 0x03ab10c0, nsIPresContext * 0x03bc1300, nsEvent * 0x0012f7dc, nsIDOMEvent * * 0x0012f2c0, nsIDOMEventTarget * 0x048db390, unsigned int 7, nsEventStatus * 0x0012f748) line 1592 + 41 bytes nsGenericElement::HandleDOMEvent(nsGenericElement * const 0x03ab1840, nsIPresContext * 0x03bc1300, nsEvent * 0x0012f7dc, nsIDOMEvent * * 0x0012f2c0, unsigned int 1, nsEventStatus * 0x0012f748) line 1674 nsHTMLInputElement::HandleDOMEvent(nsHTMLInputElement * const 0x03ab1840, nsIPresContext * 0x03bc1300, nsEvent * 0x0012f7dc, nsIDOMEvent * * 0x00000000, unsigned int 1, nsEventStatus * 0x0012f748) line 1079 + 29 bytes PresShell::HandleEventInternal(nsEvent * 0x0012f7dc, nsIView * 0x04232f90, unsigned int 1, nsEventStatus * 0x0012f748) line 5630 + 47 bytes PresShell::HandleEvent(PresShell * const 0x03b74114, nsIView * 0x04232f90, nsGUIEvent * 0x0012f7dc, nsEventStatus * 0x0012f748, int 0, int & 1) line 5557 + 25 bytes nsView::HandleEvent(nsView * const 0x04232f90, nsGUIEvent * 0x0012f7dc, unsigned int 8, nsEventStatus * 0x0012f748, int 0, int & 1) line 377 nsView::HandleEvent(nsView * const 0x04233030, nsGUIEvent * 0x0012f7dc, unsigned int 8, nsEventStatus * 0x0012f748, int 0, int & 1) line 350 nsView::HandleEvent(nsView * const 0x03b72920, nsGUIEvent * 0x0012f7dc, unsigned int 28, nsEventStatus * 0x0012f748, int 1, int & 1) line 350 nsViewManager::DispatchEvent(nsViewManager * const 0x03b6e220, nsGUIEvent * 0x0012f7dc, nsEventStatus * 0x0012f748) line 2056 HandleEvent(nsGUIEvent * 0x0012f7dc) line 68 nsWindow::DispatchEvent
** Please ignore the previous stack ** Here is the stack right before crashing: nsBlockFrame::CreateContinuationFor(nsBlockReflowState & {...}, nsLineBox * 0x00000000, nsIFrame * 0x02b42188, int & 1237660) line 3627 nsTableRowGroupFrame::FindLineContaining(nsTableRowGroupFrame * const 0x02b41fa8, nsIFrame * 0x02b42188, int * 0x0012db88) line 1620 + 14 bytes nsFrame::GetFrameFromDirection(nsFrame * const 0x02b42bf4, nsIPresContext * 0x0498fbd0, nsPeekOffsetStruct * 0x0012e360) line 3755 + 40 bytes nsTextFrame::PeekOffset(nsTextFrame * const 0x02b42bf4, nsIPresContext * 0x0498fbd0, nsPeekOffsetStruct * 0x0012e360) line 3933 + 23 bytes nsSelection::MoveCaret(unsigned int 39, int 0, nsSelectionAmount eSelectCharacter) line 1571 + 41 bytes nsSelection::CharacterMove(nsSelection * const 0x038b0690, int 1, int 0) line 2941 + 16 bytes nsTextInputSelectionImpl::CharacterMove(nsTextInputSelectionImpl * const 0x03a0bda8, int 1, int 0) line 833 + 34 bytes nsSelectionMoveCommands::DoCommand(nsSelectionMoveCommands * const 0x0467cfe0, const nsAString & {???}, nsISupports * 0x038b0780) line 381 + 39 bytes nsControllerCommandManager::DoCommand(nsControllerCommandManager * const 0x0467bed0, const nsAString & {???}, nsISupports * 0x038b0780) line 183 + 31 bytes nsEditorController::DoCommand(nsEditorController * const 0x03a09ca0, const nsAString & {???}) line 192 nsXBLPrototypeHandler::ExecuteHandler(nsXBLPrototypeHandler * const 0x0464eb80, nsIDOMEventReceiver * 0x038b1970, nsIDOMEvent * 0x04d2e354) line 310 DoKey(nsIAtom * 0x030a2040, nsIXBLPrototypeHandler * 0x0464eb80, nsIDOMEvent * 0x04d2e354, nsIDOMEventReceiver * 0x038b1970) line 92 nsXBLKeyHandler::KeyPress(nsXBLKeyHandler * const 0x038b1920, nsIDOMEvent * 0x04d2e354) line 107 + 40 bytes nsEventListenerManager::HandleEvent(nsEventListenerManager * const 0x038af830, nsIPresContext * 0x0498fbd0, nsEvent * 0x0012f7dc, nsIDOMEvent * * 0x0012f2c0, nsIDOMEventTarget * 0x04cd8110, unsigned int 7, nsEventStatus * 0x0012f748) line 1592 + 41 bytes nsGenericElement::HandleDOMEvent(nsGenericElement * const 0x038affb0, nsIPresContext * 0x0498fbd0, nsEvent * 0x0012f7dc, nsIDOMEvent * * 0x0012f2c0, unsigned int 1, nsEventStatus * 0x0012f748) line 1674 nsHTMLInputElement::HandleDOMEvent(nsHTMLInputElement * const 0x038affb0, nsIPresContext * 0x0498fbd0, nsEvent * 0x0012f7dc, nsIDOMEvent * * 0x00000000, unsigned int 1, nsEventStatus * 0x0012f748) line 1079 + 29 bytes PresShell::HandleEventInternal(nsEvent * 0x0012f7dc, nsIView * 0x04731b70, unsigned int 1, nsEventStatus * 0x0012f748) line 5630 + 47 bytes PresShell::HandleEvent(PresShell * const 0x03955d34, nsIView * 0x04731b70, nsGUIEvent * 0x0012f7dc, nsEventStatus * 0x0012f748, int 0, int & 1) line 5557 + 25 bytes nsView::HandleEvent(nsView * const 0x04731b70, nsGUIEvent * 0x0012f7dc, unsigned int 8, nsEventStatus * 0x0012f748, int 0, int & 1) line 377 nsView::HandleEvent(nsView * const 0x04731c00, nsGUIEvent * 0x0012f7dc, unsigned int 8, nsEventStatus * 0x0012f748, int 0, int & 1) line 350 nsView::HandleEvent(nsView * const 0x03939ba0, nsGUIEvent * 0x0012f7dc, unsigned int 28, nsEventStatus * 0x0012f748, int 1, int & 1) line 350 nsViewMan
I think the could be here NS_IMETHODIMP nsTableRowGroupFrame::FindLineContaining(nsIFrame* aFrame, PRInt32* aLineNumberResult) { NS_ENSURE_ARG_POINTER(aFrame); NS_ENSURE_ARG_POINTER(aLineNumberResult); nsTableRowFrame* rowFrame = (nsTableRowFrame*)aFrame; <<<<< PROBLEM <<<<<< *aLineNumberResult = rowFrame->GetRowIndex(); return NS_OK; } In my stack aFrame was nsFormFrame but we're type casting it to nsTableRowFrame.
Back to layout.
Assignee: harishd → attinasi
Status: ASSIGNED → NEW
Thanks Harish. I'll stomp out this casting error - good catch!
Status: NEW → ASSIGNED
Has anyone been able to reproduce this with recent Talkback enabled builds? Talkback data shows this last occurred with MozillaTrunk build 2001070421 and Netscape6.10 branch build 2001070105. The Talkback data also shows that there were many different URLs users crashed at, so maybe it would be a good idea to get this fixed for the next milestone/release?
Summary: Crash after pressing left arrow key in textbox. [@ nsBlockFrame::CreateContinuationFor] → Crash after pressing left arrow key in textbox.- Trunk & N610 [@ nsBlockFrame::CreateContinuationFor]
Yes, I still crash on that testcase in a 7/14 branch nightly.
(Nit: typo in comment, "should") Another 6.1 topcrash goes away. Thanks! sr=blake
typo fixed - thanks
r=karnaze
Probably need |frameType.get()| to avoid bustage on some compilers. Also, stylistically, why not put the error-handling case out-of-line? E.g., if (frameType.get() != nsLayoutAtoms::tableRowFrame) { /* warn, etc. */ return NS_ERROR_FAILURE; } /* Do the mainline, good stuff. */ return NS_OK; Other than that, looks good to me. [s]r=waterson
Will-do Chris - thanks for the comments, I applied them all.
Fix checked into trunk. Should be press this for the branch too? /cvsroot/mozilla/layout/html/table/src/nsTableRowGroupFrame.cpp,v <-- nsTableRowGroupFrame.cpp new revision: 3.245; previous revision: 3.244
Yes, definitely. They're salivating over topcrash fixes. E-mail pdt2@netscape.com.
PDT+, please check in ASAP so we have this in tomorrow's branch build. Thanks for finding the fix for this topcrash bug!
Whiteboard: PDT+
Marc, I checked this into the branch because I wasn't sure if you were around tonight.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Good call Blake - thanks.
verified fixed on buildID: 20010718 - branch Linux Redhat 7.1
Status: RESOLVED → VERIFIED
Crash Signature: [@ nsBlockFrame::CreateContinuationFor]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: