Closed Bug 98544 Opened 23 years ago Closed 23 years ago

Browser crashes after I type some text,add styles and hit delete button

Categories

(Core :: DOM: Editor, defect, P1)

Product:
Core
Component:
DOM: Editor
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 84645
Milestone:
mozilla0.9.5

People

(Reporter: sujay, Assigned: attinasi)

References

Details

(Keywords: crash, dataloss, Whiteboard: [QAHP])

win trunk 0322 Another unikway to crash the browser Steps: 1 Launch composer 2 type a few characters, then click once on the button to increase font size and type some text again. Do this till the font size reaches max size(in 3 clicks) 3 Now,hit ENTER and type some characters again and now click on the B button to make text bold. 4 Observe that as soon as u do this, some characters get added in front of the caret and they stay there 5 Now, click with the mouse after the rightmost character in the first line 6 Observe that the caret goes somewhere in the middle of the first line.. 7 Now, click the Del key(by the num pad) and keep it pressed to delete everything after the caret... Soon the browser should crash !! This is really happening...I can reproduce it for you if you want to. will attach stack trace after 'cyclone' is up. ------- Additional Comments From brade@netscape.com 2001-03-26 07:40 ------- I see this on my Macintosh debug build from today. Adding keyword dataloss since some of the characters I typed are not shown in the output. I'm not sure who this bug should go to. Maybe Joe? ------- Additional Comments From jfrancis@netscape.com 2001-03-26 10:35 ------- snarfing bug; driving world nuts by declaring it moz09. ------- Additional Comments From jfrancis@netscape.com 2001-04-16 17:41 ------- looks like a layout prob. but i won't dump it on them until i can point them (roughly at least) at the cause. ------- Additional Comments From kin@netscape.com 2001-04-16 19:21 ------- This is definitely a layout problem. And can be reproduced with any inline style containing a BR and another nested inline style. 1. Start composer. 2. Hit the bold button. 3. Hit the return key. 4. Type 'a' 5. Hit the italics button. 6. Type 'b' You'll notice that 2 'b' chars draw! In step 6 above, the editor is basically inserting a text node into the DOM tree, removing it, and then putting it under an inline style node. The problem is that the original frame generated from the first insertion is still in the frame tree! That's why the 2 'b' chars appear. The danger is that this dangling frame already has some of it's data null'd out. So any other operations that affect the frame could cause a crash. ------- Additional Comments From Marc Attinasi 2001-04-16 23:04 ------- Like kin said, the text frame is not getting removed from the frame tree. This is because the previousSibling cannot be found (in fact, the firstChild is a BR and has no next siblings at all!). Unfortunately, the nextSibling has already been null'd out so it is just a matter of time before something evil happens. Appears to me that there is something whacked in the frame tree before the attempt to remove the text frame - looking at where it is getting corrupted now. Sorry to say, this is very unlikely to make Moz0.9, which is sure to drive the world nuts (again). ------- Additional Comments From Marc Attinasi 2001-04-17 21:53 ------- CC'ing waterson because I feel more comfortable when he is associated with my layout bugs. ------- Additional Comments From Chris Waterson 2001-04-17 22:09 ------- It is interesting to note that this doesn't work on a blank page: 1. Press return. 2. Press backspace. Specifically, we don't appear to delete the <br>. Related? ------- Additional Comments From jfrancis@netscape.com 2001-04-18 01:14 ------- chris: I'm pretty sure that's my prob, not marc's. Filed bug #76455 on myself. ------- Additional Comments From jeziorek 2001-04-20 15:57 ------- It doesn't look to me that this bug will make 0.9. Could we move it away? ------- Additional Comments From Marc Attinasi 2001-04-20 16:50 ------- OK, moving to 0.9.1 - sorry, I wanted to get this fixed sooner. ------- Additional Comments From Marc Attinasi 2001-05-08 16:15 ------- CC'ing Alex so he can help out on it... ------- Additional Comments From Alexandru Savulov 2001-05-11 16:47 ------- Created an attachment (id=34153) created a new method in nsIDebugFrame::RootFrameList ------- Additional Comments From Alexandru Savulov 2001-05-11 17:16 ------- forget attachment with id=34153. already patched in bug 80396 ------- Additional Comments From karnaze@netscape.com 2001-05-15 13:16 ------- Moving to m0.9.3 ------- Additional Comments From karnaze@netscape.com 2001-05-15 13:18 ------- sujay, kin, we're not seeing a crash, can you help. ------- Additional Comments From shrirang khanzode 2001-05-15 13:29 ------- I can still reproduce this crash on 0515 trunk on windows based on my initial steps.. ------- Additional Comments From shrirang khanzode 2001-05-15 13:41 ------- new steps to reproduce the crash: launch composer , type one word+click on button in toolbar 'A' to increase font size once, type some moretext(keep all this in a single word), again increase font size once, type text,increase font size for the third time and type some text. Now , hit ENTER type some text 'abcde', hit B to make text bold. As soon as you do this, you should see an extra stray character appear in front of the actual last character u added. Now, click with mouse after the last character in the first line (the caret will place itself somewhere in between the text in the first line) Now, just keep the delete key pressed to delete all test that follows the caret and observe the browser crash. hope this helps! ------- Additional Comments From kin@netscape.com 2001-05-15 14:23 ------- Follow the steps I outlined above (it's shorter) to get the dangling frame, then just do an Undo. You will definitely crash. Do we really want to push this crasher out to 0.9.3? ------- Additional Comments From rbs@maths.uq.edu.au 2001-05-23 17:59 ------- I am crashing at this end. Here is the stack trace: nsFrame::GetOffsetFromView(const nsFrame * const 0x04309d1c, nsIPresContext * 0x067f5830, nsPoint & {...}, nsIView * * 0x0012eaf0) line 2083 + 17 bytes nsCaret::GetViewForRendering(nsIFrame * 0x04309d1c, nsICaret::EViewCoordinates eRenderingViewCoordinates, nsPoint & {...}, nsRect & {...}, nsIView * & 0x00000000) line 749 nsCaret::DrawCaret() line 906 nsCaret::StartBlinking() line 455 nsCaret::SetCaretVisible(nsCaret * const 0x067c1370, int 1) line 208 + 8 bytes PresShell::SetCaretEnabled(PresShell * const 0x067f7190, int 1) line 2933 + 36 bytes nsHTMLEditRules::AfterEdit(nsHTMLEditRules * const 0x0648a1a4, int 8, short 1) line 323 nsHTMLEditor::EndOperation(nsHTMLEditor * const 0x0648a8a0) line 3538 + 62 bytes nsAutoRules::~nsAutoRules() line 109 nsPlaintextEditor::DeleteSelection(nsPlaintextEditor * const 0x0648a8a0, short 1) line 944 + 22 bytes nsHTMLEditorLog::DeleteSelection(nsHTMLEditorLog * const 0x0648a8a0, short 1) line 142 + 14 bytes nsTextEditorKeyListener::KeyPress(nsTextEditorKeyListener * const 0x064962b0, nsIDOMEvent * 0x02cf2f94) line 241 nsEventListenerManager::HandleEvent(nsEventListenerManager * const 0x067c7d30, nsIPresContext * 0x067f5830, nsEvent * 0x0012f79c, nsIDOMEvent * * 0x0012f488, nsIDOMEventTarget * 0x067f25c0, unsigned int 2, nsEventStatus * 0x0012f708) line 1548 + 41 bytes nsDocument::HandleDOMEvent(nsDocument * const 0x067f2590, nsIPresContext * 0x067f5830, nsEvent * 0x0012f79c, nsIDOMEvent * * 0x0012f488, unsigned int 2, nsEventStatus * 0x0012f708) line 2874 nsGenericElement::HandleDOMEvent(nsGenericElement * const 0x067f4270, nsIPresContext * 0x067f5830, nsEvent * 0x0012f79c, nsIDOMEvent * * 0x0012f488, unsigned int 1, nsEventStatus * 0x0012f708) line 1702 + 39 bytes PresShell::HandleEventInternal(nsEvent * 0x0012f79c, nsIView * 0x062e5240, unsigned int 1, nsEventStatus * 0x0012f708) line 5512 + 47 bytes PresShell::HandleEvent(PresShell * const 0x067f7184, nsIView * 0x062e5240, nsGUIEvent * 0x0012f79c, nsEventStatus * 0x0012f708, int 0, int & 1) line 5439 + 25 bytes nsView::HandleEvent(nsView * const 0x062e5240, nsGUIEvent * 0x0012f79c, unsigned int 8, nsEventStatus * 0x0012f708, int 0, int & 1) line 377 nsView::HandleEvent(nsView * const 0x062e60d0, nsGUIEvent * 0x0012f79c, unsigned int 8, nsEventStatus * 0x0012f708, int 0, int & 1) line 350 nsView::HandleEvent(nsView * const 0x067f7830, nsGUIEvent * 0x0012f79c, unsigned int 28, nsEventStatus * 0x0012f708, int 1, int & 1) line 350 nsViewManager::DispatchEvent(nsViewManager * const 0x067f79d0, nsGUIEvent * 0x0012f79c, nsEventStatus * 0x0012f708) line 2056 HandleEvent(nsGUIEvent * 0x0012f79c) line 68 nsWindow::DispatchEvent(nsWindow * const 0x062e6444, nsGUIEvent * 0x0012f79c, nsEventStatus & nsEventStatus_eIgnore) line 702 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f79c) line 723 nsWindow::DispatchKeyEvent(unsigned int 131, unsigned short 0, unsigned int 46) line 2350 + 15 bytes nsWindow::OnKeyDown(unsigned int 46, unsigned int 16723) line 2391 nsWindow::ProcessMessage(unsigned int 256, unsigned int 46, long 1095958529, long * 0x0012fba4) line 2969 + 32 bytes nsWindow::WindowProc(HWND__ * 0x0036035c, unsigned int 256, unsigned int 46, long 1095958529) line 957 + 27 bytes USER32! 77e148dc() USER32! 77e14aa7() USER32! 77e266fd() nsAppShellService::Run(nsAppShellService * const 0x010c44a0) line 418 main1(int 1, char * * 0x00484470, nsISupports * 0x00000000) line 1128 + 32 bytes main(int 1, char * * 0x00484470) line 1426 + 37 bytes mainCRTStartup() line 338 + 17 bytes KER ------- Additional Comments From rbs@maths.uq.edu.au 2001-05-23 18:03 ------- 'frame' is not null but its __vfptr is null in the debugger. So it seems from the code below that a child frame is outliving its parent. Something very weird. NS_IMETHODIMP nsFrame::GetOffsetFromView(nsIPresContext* aPresContext, nsPoint& aOffset, nsIView** aView) const { NS_PRECONDITION(nsnull != aView, "null OUT parameter pointer"); nsIFrame* frame = (nsIFrame*)this; *aView = nsnull; aOffset.MoveTo(0, 0); do { nsPoint origin; frame->GetOrigin(origin); aOffset += origin; frame->GetParent(&frame); if (nsnull != frame) { CRASH HERE===> frame->GetView(aPresContext, aView); } } while ((nsnull != frame) && (nsnull == *aView)); return NS_OK; } ------- Additional Comments From Alexandru Savulov 2001-05-24 10:06 ------- I'm working on it. Discovered that if one follows Kin's steps, there is a text-frame in the frames tree that has a bad parent (created after italic + "b"). This frame cannot be deleted afterwards in a subsequent call to nsCSSFrameConsturctor::ContentInserted (inserts a inline-frame for the <i> that will require the creation of a new text-frame inside for the text) and so, there will be two frames pointing to the same content. If one deletes the italic text, the wild-frame will point to a deleted content and there we are... This happens only when there is a <br> right after <b>. ------- Additional Comments From Chris Waterson 2001-05-24 13:53 ------- Can we create a DOM-only test case for this? That's usually a good first step to minimizing this stuff... ------- Additional Comments From Alexandru Savulov 2001-05-24 15:46 ------- We already considered the ideea of creating a DOM-only test case, but it does not work. One must follow Kin's steps to get to the problem.
Target Milestone: --- → mozilla0.9.5
*** Bug 73170 has been marked as a duplicate of this bug. ***
Keywords: crash, dataloss, nsbeta1
Whiteboard: [QAHP]
attachment from duplicate bug: http://bugzilla.mozilla.org/attachment.cgi?id=34153&action=view
Priority: -- → P1
I would be willing to bet a doughnut that this is a dup of bug 84645.
So, in my tree (which has fixes for bug 84645), I cannot reproduce the crash, nor can I reproduce the bizarre behavior described in steps (4) and (6) of the bug. When attempting step (7), I get this assertion: ###!!! ASSERTION: NS_ENSURE_TRUE(NS_SUCCEEDED(res)) failed: '(!((res) & 0x80000000))', file nsWSRunObject.cpp, line 599 ###!!! Break: at file nsWSRunObject.cpp, line 599 And no text is deleted. Using the cursor keys (<- and ->), I can eventually position the cursor s.t. the DEL key will join the lines and delete characters. So, I claim that this bug is a dup of bug 84645, and will be fixed by that patch. The goofiness with joining lines is probably that age-old chestnut that has to do with the cursor getting placed after the <br> in the content model, which I've seen perenially in mail compose for several months. *** This bug has been marked as a duplicate of 84645 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
FYI the assertion that happens when trying to join lines with DELETE sounds like bug 93477.
I *think* the remaining issues are covered in Kin's bug (#93477)
verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.