If JavaScript is used to set the text of a div to an empty string, and the resulting reflow means that a vertical scrollbar that is present is no longer needed, Mozilla crashes in GKHTML.DLL. Details in the attachment.

The test case also crashes Build 2000100504 Talkback on Win 98. Suggest STATUS: NEW

Confirming crash and assigning.

I'm not sure jst is the right person for this. Might be mikey. Setting Priority -> P1, Severity -> critical, keywords -> crash, rtm the variable "text" is null and being dereferenced at this line: if ((textLength > 0) && (text[textLength - 1] == '\n')) { here's the stack trace: nsTextFrame::PaintAsciiText() line 2512 + 21 bytes nsTextFrame::Paint() line 1255 nsContainerFrame::PaintChild() line 211 nsBlockFrame::PaintChildren() line 6408 nsBlockFrame::Paint() line 6286 nsContainerFrame::PaintChild() line 211 nsBlockFrame::PaintChildren() line 6408 nsBlockFrame::Paint() line 6286 nsContainerFrame::PaintChild() line 211 nsBlockFrame::PaintChildren() line 6408 nsBlockFrame::Paint() line 6286 nsContainerFrame::PaintChild() line 211 nsContainerFrame::PaintChildren() line 155 nsHTMLContainerFrame::Paint() line 108 PresShell::Paint() line 4125 + 34 bytes nsView::Paint() line 284 nsViewManager2::RenderDisplayListElement() line 859 nsViewManager2::RenderViews() line 806 nsViewManager2::Refresh() line 686 nsViewManager2::DispatchEvent() line 1352 HandleEvent() line 68 nsWindow::DispatchEvent() line 681 + 10 bytes nsWindow::DispatchWindowEvent() line 707 nsWindow::OnPaint() line 3698 + 28 bytes nsWindow::ProcessMessage() line 2805 + 17 bytes nsWindow::WindowProc() line 950 + 27 bytes USER32! 77e719d0() USER32! 77e71982() NTDLL! 77f763a3()

Mac Mozilla installer build 2000101808 running under Mac OS 9.0.4 will not crash while running the testcase, so I guess this is a Win 2000-only bug. FWIW, I tried the testcase for around five minutes or so.

Nope, this one is not mine, but I do have "a fix" for this crasher. The problem is that nsTextFrame seems to assume that there's always data in the textfragment in the textnode, but that's not true, it's perfectly legal to have no string buffer at all in a textfragment and that's what's happening in this case. This patch (diff -w) fixes the problem but I don't know if this is the real fix. Index: html/base/src/nsTextFrame.cpp =================================================================== RCS file: /cvsroot/mozilla/layout/html/base/src/nsTextFrame.cpp,v retrieving revision 1.276.2.1 diff -u -w -r1.276.2.1 nsTextFrame.cpp --- nsTextFrame.cpp 2000/10/09 08:44:29 1.276.2.1 +++ nsTextFrame.cpp 2000/10/20 02:16:53 @@ -2497,7 +2497,10 @@ text = paintBuf; } else { - text = frag->Get1b() + mContentOffset; + text = frag->Get1b(); + + if (text) { + text += mContentOffset; textLength = mContentLength; // See if we should skip leading whitespace @@ -2513,6 +2516,7 @@ textLength--; } NS_ASSERTION(textLength >= 0, "bad text length"); + } } nscoord width = mRect.width; The weird thing is that mContentLength is 14 in the case where we crash, and thus textLength is > 0 and that's why we even reference the null pointer. Over to waterson.

Nom. nsbeta1. DOM crasher. Even though it's specific to one platform, this is the kind of thing that scares developers off from being able to use features of a standard (crashing when you use the feature).

QA contact Update

Doesn't seem to crash anymore.

I can still get this to crash (with an access violation) in 2001030804, but it takes a lot more persistence or a slightly different approach (see below), and it now crashes in GKLAYOUT.DLL instead of GKHTML.DLL. I wondered if the fact that it crashes in a different DLL meant that the original problem had been fixed, and I was bumping up against another bug, but changing the test case to delete the node rather than emptying it (as described in the attachment) still seems to fix the problem. Persistence is required if you move the mouse vertically as described in the test case. Sometimes I can scribble the mouse up and down madly for two or three minutes before it crashes. On the other hand, moving the mouse to the left into the browser window and over the text, then to the right out of the window usually causes a crash within five repetitions.

Ok, I'll look into it. (There was a bit of DLL shuffling, which is why the DLL name changed.)

Allready nominated for nsbeta1. Feature can not be used because of crash. Adding keyword mozilla0.9.1. Remove if disagree.

Updating QA contact to Shivakiran Tummala.

i could not reproduce the crash on windows 2000

I can no longer reproduce this problem (2001101003 on Windows 2000). As far as I'm concerned, this bug can be closed.

Marking WORKSFORME per QA and reporter's comments (also works here in a build as old as 2001091903 win2k) Thanks for the followup

as per the reporters comments and my investigation of this bug. i am verifying this bug. adding keyword vtrunk

verified fixed, 2001-12-14-09