FastFind Talkback Incident ID QuickSearch Search By: Stack Signature Comments URL Talkback Reports Mozilla Reports Mozilla Firefox Reports Firefox Thunderbird Reports Thunderbird Camino Reports Camino Incident ID: 404291 Stack Signature nsFontMetricsWin::ResolveForwards b4fde65f Product ID MozillaTrunk Build ID 2004071707 Trigger Time 2004-07-24 12:52:19.0 Platform Win32 Operating System Windows 98 4.10 build 67766446 Module GKGFXWIN.DLL + (0000a427) URL visited http://www.senate.gov/legislative/LIS/roll_call_lists/roll_call_vote_cfm.cfm?congress=108&session=2&vote=00155 User Comments I selected all of the main text, then did a view selection source. Then it crashed. Since Last Crash 225861 sec Total Uptime 225861 sec Trigger Reason Access violation Source File, Line No. c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/gfx/src/windows/nsFontMetricsWin.cpp, line 3960 Stack Trace nsFontMetricsWin::ResolveForwards [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/gfx/src/windows/nsFontMetricsWin.cpp, line 3960] nsRenderingContextWin::GetWidth [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/gfx/src/windows/nsRenderingContextWin.cpp, line 1482] nsTextFrame::PaintUnicodeText [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsTextFrame.cpp, line 2385] nsTextFrame::Paint [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsTextFrame.cpp, line 1481] nsContainerFrame::PaintChild [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 306] nsBlockFrame::PaintChild [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.h, line 248] nsBlockFrame::PaintChildren [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 5412] nsHTMLContainerFrame::PaintDecorationsAndChildren [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsHTMLContainerFrame.cpp, line 141] nsBlockFrame::Paint [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 5269] nsContainerFrame::PaintChild [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 306] nsBlockFrame::PaintChild [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.h, line 248] nsBlockFrame::PaintChildren [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 5412] nsHTMLContainerFrame::PaintDecorationsAndChildren [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsHTMLContainerFrame.cpp, line 141] nsBlockFrame::Paint [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 5269] nsContainerFrame::PaintChild [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 306] nsBlockFrame::PaintChild [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.h, line 248] nsBlockFrame::PaintChildren [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 5444] nsHTMLContainerFrame::PaintDecorationsAndChildren [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsHTMLContainerFrame.cpp, line 141] nsBlockFrame::Paint [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 5269] nsContainerFrame::PaintChild [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 306] nsContainerFrame::PaintChildren [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 230] nsHTMLContainerFrame::Paint [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsHTMLContainerFrame.cpp, line 88] CanvasFrame::Paint [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsHTMLFrame.cpp, line 393] PresShell::Paint [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp, line 5545] nsView::Paint [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsView.cpp, line 264] nsViewManager::RenderDisplayListElement [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp, line 1390] nsViewManager::RenderViews [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp, line 1307] nsViewManager::Refresh [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp, line 873] nsViewManager::DispatchEvent [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp, line 1826] HandleEvent [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsView.cpp, line 79] nsWindow::DispatchEvent [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp, line 1066] nsWindow::DispatchWindowEvent [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp, line 1088] nsWindow::OnPaint [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp, line 5047] nsWindow::ProcessMessage [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp, line 3820] nsWindow::WindowProc [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp, line 1345] KERNEL32.DLL + 0x363b (0xbff7363b) KERNEL32.DLL + 0x24407 (0xbff94407) -- I tried to follow the steps: > I generated the crash by selecting all the text in the middle column > and then doing a "View selection source" from the context menu. I wasn't sure what 'middle' column meant, i picked dole..lincoln (possibly also 'by senator name', and when that didn't crash, i did a select all. but i didn't crash :( [W] UMC: Uninitialized memory copy in nsTextFrame::PrepareUnicodeText(nsTextTransformer&,nsAutoIndexBuffer *,nsAutoTextBuffer *,int *,int) {2 occurrences} Copying 4 bytes from 0x0013d77c (4 bytes at 0x0013d77c uninitialized) Address 0x0013d77c points into a thread's stack Address 0x0013d77c is 84 bytes past the start of local variable 'indexBuffer' in nsTextFrame::GetPointFromOffset(nsIPresContext *,nsIRenderingContext *,int,nsPoint *) Thread ID: 0x1164 Error location nsTextFrame::PrepareUnicodeText(nsTextTransformer&,nsAutoIndexBuffer *,nsAutoTextBuffer *,int *,int)+0x85e [r:\mozilla\layout\html\base\src\nstextframe.cpp:1691 ip=0x0491792b] nsTextFrame::GetPointFromOffset(nsIPresContext *,nsIRenderingContext *,int,nsPoint *)+0x298 [r:\mozilla\layout\html\base\src\nstextframe.cpp:3732 ip=0x04922b12] nsTypedSelection::GetPointFromOffset(nsIFrame *,int,nsPoint *)+0x2b6 [r:\mozilla\content\base\src\nsselection.cpp:6961 ip=0x0460115d] nsTypedSelection::GetCachedFrameOffset(nsIFrame *,int,nsPoint&)+0x18d [r:\mozilla\content\base\src\nsselection.cpp:5229 ip=0x04605412] nsTypedSelection::GetSelectionRegionRectAndScrollableView(short,nsRect *,nsIScrollableView * *)+0x48a [r:\mozilla\content\base\src\nsselection.cpp:7091 ip=0x04601683] nsTypedSelection::ScrollIntoView(short,int)+0x214 [r:\mozilla\content\base\src\nsselection.cpp:7460 ip=0x04602757] nsSelection::ScrollSelectionIntoView(short,short,int)+0x81 [r:\mozilla\content\base\src\nsselection.cpp:2819 ip=0x045f4308] PresShell::ScrollSelectionIntoView(short,short,int)+0x59 [r:\mozilla\layout\html\base\src\nspresshell.cpp:2594 ip=0x04455959] XPTC_InvokeByIndex+0x6e [r:\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp:101 ip=0x024077b7] XPCWrappedNative::CallMethod(XPCCallContext&,CallMode::XPCWrappedNative)+0x122f [r:\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp:2028 ip=0x03bc9a04] XPC_WN_CallMethod(JSContext *,JSObject *,UINT,long *,long *)+0x1c9 [r:\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp:1287 ip=0x03bcfbd8] js_Invoke+0xefd [r:\mozilla\js\src\jsinterp.c:1281 ip=0x03c75f12] [W] UMR: Uninitialized memory read in nsTextFrame::PrepareUnicodeText(nsTextTransformer&,nsAutoIndexBuffer *,nsAutoTextBuffer *,int *,int) {2 occurrences} Reading 4 bytes from 0x0013d780 (4 bytes at 0x0013d780 uninitialized) Address 0x0013d780 points into a thread's stack Address 0x0013d780 is 88 bytes past the start of local variable 'indexBuffer' in nsTextFrame::GetPointFromOffset(nsIPresContext *,nsIRenderingContext *,int,nsPoint *) Thread ID: 0x1164 Error location nsTextFrame::PrepareUnicodeText(nsTextTransformer&,nsAutoIndexBuffer *,nsAutoTextBuffer *,int *,int)+0x897 [r:\mozilla\layout\html\base\src\nstextframe.cpp:1692 ip=0x04917964] nsTextFrame::GetPointFromOffset(nsIPresContext *,nsIRenderingContext *,int,nsPoint *)+0x298 [r:\mozilla\layout\html\base\src\nstextframe.cpp:3732 ip=0x04922b12] nsTypedSelection::GetPointFromOffset(nsIFrame *,int,nsPoint *)+0x2b6 [r:\mozilla\content\base\src\nsselection.cpp:6961 ip=0x0460115d] nsTypedSelection::GetCachedFrameOffset(nsIFrame *,int,nsPoint&)+0x18d [r:\mozilla\content\base\src\nsselection.cpp:5229 ip=0x04605412] nsTypedSelection::GetSelectionRegionRectAndScrollableView(short,nsRect *,nsIScrollableView * *)+0x48a [r:\mozilla\content\base\src\nsselection.cpp:7091 ip=0x04601683] nsTypedSelection::ScrollIntoView(short,int)+0x214 [r:\mozilla\content\base\src\nsselection.cpp:7460 ip=0x04602757] nsSelection::ScrollSelectionIntoView(short,short,int)+0x81 [r:\mozilla\content\base\src\nsselection.cpp:2819 ip=0x045f4308] PresShell::ScrollSelectionIntoView(short,short,int)+0x59 [r:\mozilla\layout\html\base\src\nspresshell.cpp:2594 ip=0x04455959] XPTC_InvokeByIndex+0x6e [r:\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp:101 ip=0x024077b7] XPCWrappedNative::CallMethod(XPCCallContext&,CallMode::XPCWrappedNative)+0x122f [r:\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp:2028 ip=0x03bc9a04] XPC_WN_CallMethod(JSContext *,JSObject *,UINT,long *,long *)+0x1c9 [r:\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp:1287 ip=0x03bcfbd8] js_Invoke+0xefd [r:\mozilla\js\src\jsinterp.c:1281 ip=0x03c75f12] [W] UMC: Uninitialized memory copy in nsTextFrame::PrepareUnicodeText(nsTextTransformer&,nsAutoIndexBuffer *,nsAutoTextBuffer *,int *,int) {1 occurrence} Copying 4 bytes from 0x0013c730 (4 bytes at 0x0013c730 uninitialized) Address 0x0013c730 points into a thread's stack Address 0x0013c730 is 616 bytes past the start of parameter 'indexp' in nsTextFrame::PrepareUnicodeText(nsTextTransformer&,nsAutoIndexBuffer *,nsAutoTextBuffer *,int *,int) Thread ID: 0x1164 Error location nsTextFrame::PrepareUnicodeText(nsTextTransformer&,nsAutoIndexBuffer *,nsAutoTextBuffer *,int *,int)+0x85e [r:\mozilla\layout\html\base\src\nstextframe.cpp:1691 ip=0x0491792b] nsTextFrame::PaintUnicodeText(nsIPresContext *,nsIRenderingContext&,nsStyleContext *,TextPaintStyle::nsTextFrame&,int,int)+0x359 [r:\mozilla\layout\html\base\src\nstextframe.cpp:2245 ip=0x0491dfb5] [W] UMR: Uninitialized memory read in nsTextFrame::PrepareUnicodeText(nsTextTransformer&,nsAutoIndexBuffer *,nsAutoTextBuffer *,int *,int) {1 occurrence} Reading 4 bytes from 0x0013c734 (4 bytes at 0x0013c734 uninitialized) Address 0x0013c734 points into a thread's stack Address 0x0013c734 is 620 bytes past the start of parameter 'indexp' in nsTextFrame::PrepareUnicodeText(nsTextTransformer&,nsAutoIndexBuffer *,nsAutoTextBuffer *,int *,int) Thread ID: 0x1164 Error location nsTextFrame::PrepareUnicodeText(nsTextTransformer&,nsAutoIndexBuffer *,nsAutoTextBuffer *,int *,int)+0x897 [r:\mozilla\layout\html\base\src\nstextframe.cpp:1692 ip=0x04917964] nsTextFrame::PaintUnicodeText(nsIPresContext *,nsIRenderingContext&,nsStyleContext *,TextPaintStyle::nsTextFrame&,int,int)+0x359 [r:\mozilla\layout\html\base\src\nstextframe.cpp:2245 ip=0x0491dfb5]

crashing: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a3) Gecko/20040724 TB407797E, TB407748K, TB407703Y I can reproduce the crash online, and locally on a copy saved as Webpage, complete. Scroll to Grouped By Vote Position, and select both the YEAs ---48, and the NAYs ---50, i.e. select from: Alexander (R-TN) up to, including: Wyden (D-OR I didn´t include the closing bracket, testing is hard, as my old system is slow at rebooting.

contains simple css, don´t know if needed at all, and five tables, size 100 % Tried to reduce table content, or delete last table, but didn´t see bug then. Steps to reproduce: select from: SELECT FROM HERE to, including: SELECT TO HERE and then View Selection Source, and enjoy Talkback coming up. I don´t have the time to reduce it further. Worksforme, if I delete: <tr><td colspan="3" class="contenttext" align="center"><b>NAYs --</b><b>50</b></td></tr> Also wfm, when I tried to reduce the last table by deleting entries from ARIZONA to WEST VIRGINIA.

WFM Mozilla/5.0 (Windows; U; WinNT4.0; de-AT; rv:1.7) Gecko/20040618 Crash Mozilla/5.0 (Windows; U; WinNT4.0; de-AT; rv:1.8a3) Gecko/20040724 => OS All TB408647W as reproduced in comment 1

The error occurs in line 6023A427 mov cx,word ptr [esi] with ESI = 00161000 (which could be *currChar)

removed css, <b>, <span> and one containing table. Didn´t try to shorten tables.

> I tried to follow the steps: >> I generated the crash by selecting all the text in the middle column >> and then doing a "View selection source" from the context menu. > I wasn't sure what 'middle' column meant, i picked dole..lincoln (possibly > also 'by senator name', and when that didn't crash, i did a select all. > but i didn't crash :( I get the crash by selecting all text starting with "U.S. Senate Roll Call Votes 108th Congress - 2nd Session" (near the top) and ending with "Thomas (R-WY), Yea Vote Summary By Senator Name By Vote Position By Home State" (at the very bottom), then doing a view selection source. Win 98, current trunk build.

removed containing table, now 3 tables only. reduced # of lines in the state table, until bug vanished, added one line reduced # of lines in the first table, until bug vanished, added one line Select All, then View Selection Source.

while producing the testcases, they always crashed at first try. After upload as attachment, I opened the attachments to see if they are working from bugzilla, and they did, crash at first time. The last one however didn´t crash, then I retried the obsolete ones, they also didn´t crash. Got the last one crashing at third try, select manually, to get the page scrolling, and then View Selection Source, crash at third try. Reason for crash seems to be the colspan="3", if I remove this, I don´t get a crash. <table valign="TOP" border="0" cellpadding="1" cellspacing="1" width="100%"> <tbody> <tr> <td colspan="3" align="center">NAYs </td> </tr> <tr valign="top"> <td width="33%">Akaka.... no crash using: <td align="center">NAYs </td>

BuildID 2004071609 was crashing on the original website. Select All, View Selection Source, didn´t crash, tested three times. Manually selecting all the names from Grouped By Vote Position: View Selction Source was showing the selected source, then crashed after about 2 seconds. Tested BuildID 2004071408 shortly with the SelectAll method, didn´t see a crash.

Errors URI : http://www.senate.gov/resources/senate_style.css * Line: 0 Context : added for active_legislation Parse Error - --> .advancedActionFailed { FONT-STYLE: italic; FONT-WEIGHT: bold; TEXT-DECORATION: line-through; } Warnings URI : http://www.senate.gov/resources/senate_style.css * Line : 0 font-family: You are encouraged to offer a generic family as a last alternative Valid CSS information * .contenttext { o font-size : 12px; o color : black; o font-family : Arial; } * BODY { o font-size : 12px; o color : black; o font-family : Arial; } * A { o color : #990000; o font-family : Arial; o text-decoration : underline; } * P { o margin-top : 6px; o margin-bottom : 1px; } * HR { o width : 100%; o color : #999999; o height : 1px; } * UL { o margin-top : 4px; o margin-bottom : 1px; } * TH { o font-weight : bold; o font-size : 12px; o margin-bottom : 1px; o font-family : Arial; o text-align : left; } * A:visited { o color : #666666; o text-decoration : underline; } * .contenttitle { o font-weight : bold; o font-size : 14px; o font-family : Arial; } * .contentsubtitle { o font-weight : bold; o font-size : 12px; o font-family : Arial; } * INPUT { o font-size : 10px; o width : 100%; o color : black; o font-family : Arial; } * .teasertext { o font-size : 10px; o color : black; o font-family : Arial; } * .breadcrumb { o font-size : 9px; o color : #999999; o font-family : Arial; } * CAPTION { o font-size : 10px; o color : black; o font-family : Arial; o text-align : center; } * .footer { o font-size : 8pt; o color : black; o font-family : Arial; } * .movebottom { o background-position : 50% 50%; o font-size : 10px; } * .credit { o font-style : italic; } * .advancedAction { o font-style : italic; o font-weight : bold; } * .advancedFailed { o font-weight : bold; o text-decoration : line-through; } * .actionFailed { o font-style : italic; o text-decoration : line-through; } * .action { o font-style : italic; } * .advanced { o font-weight : bold; } * .failed { o text-decoration : line-through; } * .publicLaw { o color : red; } * PRE { o font-size : 11px; o color : black; o font-family : Arial; } * TD { o font-size : 12px; o color : black; o font-family : Arial; } * .heading2 { o font-size : 11pt; o font-family : Arial; o font-weight : normal; } * .heading3 { o font-size : 11pt; o font-family : Arial; o font-weight : bold; } * h3 { o font-size : 12pt; o font-family : Arial; o font-weight : bold; } This are the current problems But Im not the webmaster of the US senate Whith the best regards JulioBell

WFM, Win2K, latest build. According to the stack of comment 0, it is crashing on line 3960 (as of now) http://lxr.mozilla.org/mozilla/source/gfx/src/windows/nsFontMetricsWin.cpp#3960 3957 // see if we can keep the same font for adjacent characters 3958 PRInt32 lastCharLen; 3959 while (currChar < lastChar) { 3960 if (IS_HIGH_SURROGATE(*currChar) && (currChar+1) < lastChar && IS_LOW_SURROGATE(*(currChar+1))) { 3961 nextFont = LocateFont(aDC, SURROGATE_TO_UCS4(*currChar, *(currChar+1)), count); 3962 lastCharLen = 2; 3963 } 3964 else { 3965 nextFont = LocateFont(aDC, *currChar, count); 3966 lastCharLen = 1; 3967 }

(In reply to comment #11) > WFM, Win2K, latest build. WFM Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a3) Gecko/20040725 Win98SE, Athlon XP1600+, 512 MB RAM It was crashing on my Win98, Celeron333, 96 MB, while I made the testcases, had an editor open with mutliple windows, besides Mozilla. After uploading the testcases to bugzilla, I checked them at bugzilla, they were crashing. After reboot, it was hard to reproduce, worked better when scrolling and selecting manually. Maybe it depends on amount of available memory, more helps to avoid the crash. normally the source windows opens, and the selected text is highlighted. In case of crash, the source window opens, text is shown, but not highlighted, and after maybe 2 seconds Mozilla goes down, DocWatson comes up.

(In reply to comment #3) > WFM Mozilla/5.0 (Windows; U; WinNT4.0; de-AT; rv:1.7) Gecko/20040618 > Crash Mozilla/5.0 (Windows; U; WinNT4.0; de-AT; rv:1.8a3) Gecko/20040724 WFM Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.8a3) Gecko/20040724 Does this only happen on Win98 and WinNT4?

Crashed with Mozilla 2004072708/2004072209 on WinNT4 on http://www.mozilla.org/releases/ after view selection source. TB431245E, TB430755Z

I experience this bug with: http://www.bandasfilarmonicas.com/entrevista_luiscardoso.php It happens often when I select a large portion (most of the page) of the page: Talkback ID's: TB952781K, TB952611H and TB952498M. Might be worth to note that this page suffers from bug 58917. Some text is not displayed (removing some font tags make the text display again).

> It happens often when I select a large portion (most of the page) of the page: I meant: It happens often when I select a large portion of the page and then do View Selection Source.

*** Bug 261641 has been marked as a duplicate of this bug. ***

When I do a View Selection Source on the placeholder text ("The image .. cannot be displayed... ") of an invalid image, I get a crash too (almost all of the time). The Talkback data of that crash seems to be similar as this bug. Talkback ID: TB1004416H

(In reply to comment #18) > Created an attachment (id=160574) > Testcase - invalid image (crash on View selection source) > > When I do a View Selection Source on the placeholder text ("The image .. > cannot be displayed... ") of an invalid image, I get a crash too (almost all > of the time). On both 'Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a5) Gecko/20040930 Mnenhy/0.6.0.104' and 'Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a4) Gecko/20040928 Mnenhy/0.6.0.104' I cannot reproduce this. I clicked on this attachment, pressed Ctrl-A to "select all" and did a "View Selection Source" (is this way the one you mean?) several times, and my Mozilla never crashed.

Sorry. I wasn't clear enough. No, it happens when I select a part of the placeholder text (which is a bit hard, I know) and then do View Selection Source.

(In reply to comment #18) > Created an attachment (id=160574) > Testcase - invalid image (crash on View selection source) > > When I do a View Selection Source on the placeholder text ("The image .. > cannot be displayed... ") of an invalid image, I get a crash too (almost all of > the time). I still cannot reproduce this behaviour on Linux (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a5) Gecko/20040930 Mnenhy/0.6.0.104).

(In reply to comment #21) > I still cannot reproduce this behaviour on Linux You're not supposed to reproduce this on Linux. See the stack uploaded here. It's happening in nsFontMetricsWin.cpp (see comment #11)

(In reply to comment #22) > You're not supposed to reproduce this on Linux. See the stack uploaded here. > It's happening in nsFontMetricsWin.cpp (see comment #11) I tested it because "my own" bug #261641 was marked as a duplicate of this bug a few days ago. So it's not sure that this bug #252970 and bug #261641 really are duplicate?

Filled TB1064197Q happend with the URL of bug 252970 but with an other part of the source. The stack seems nothing to do with windows specific source code. See also stacks of the TBs in comment 15. Only one has nsFontMetricsWin::ResolveForwards as the crash point. I guess that all crashes are the same bug and the real reason for the crashes is somewhere else.

Sorry, I used the URL of bug 261641. http://wunschliste.de/index.pl?vote&r=00&abc=B Select a large part of the middle column. The selection should end at the end of a line.

Some TBs after a source view of the url from bug 261641: TB1064197Q: @nsScriptSecurityManager::GetScriptPrincipal TB1064385W, TB1064660H, TB1068188E, TB1068233M, TB1068436K: @nsFontMetricsWin::ResolveForwards Maybe TBs from other OS could help.

wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a5) Gecko/20041022 also tested working with yesterdays nightly, which was crashing on another 'View Selection Source' bug.

still crashing with nightly build 2004102206 on the "Testcase - invalid image (crash on View selection source)" test case when selecting the last dot and doing a "view selection source".

still crashing: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a5) Gecko/20041022 URL from this bug is wfm, but I used URL from bug 130900 http://www.area450.com/hacks/regionhack.htm Just did 'Select All', 'View Selection Source', -> crash, reproducable. Stack Signature: nsFontMetricsWin::ResolveForwards 3aaffa00 http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB1463279Y 54 crashes found, Stack Signature contains 'nsfontmetricswin::resolveforwards' http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=+nsFontMetricsWin%3A%3AResolveForwards&vendor=All&product=All&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=bbid

This might, indeed, be an XP bug. (i.e. I may have been wrong in comment #22) I suspect that layout passes a bogus string length to Gfx in some cases. That is, in ResolveForward, 'currChar < lastChar' is not a guarantee that we're within the range any more... rbs, what do you think? bug 261641 comment #0 has the following: > The bug did not appear on self-build CVS of 20040529. It is present on every > later version.

*** Bug 265643 has been marked as a duplicate of this bug. ***

> This might, indeed, be an XP bug. from comment #29 : Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a5) so this bug is affecting win9x and winnt5.x

*** Bug 273261 has been marked as a duplicate of this bug. ***

(In reply to comment #33) > *** Bug 273261 has been marked as a duplicate of this bug. *** The bug you marked as duplicate affects Linux too, so this bug shouldn't be Windows only OR it is not a duplicate.

This is a topcrasher with recent MozillaTrunk builds. A few Talkback comments also mention that the testcase in bug 213408 is causing this crash (or at least one with the same stack trace)...so there might be clues there. Marking topcrash+ since we have a reproducible testcase.

Re: Comment #30 Indeed jshin, some problems elswehere are causing 'currChar < lastChar' to become meaningless. Comment 35 which mentions bug 213408 now allows to see the source. It appears to be another upshot of those &shy problems (like bug 267669 too).

*** Bug 278042 has been marked as a duplicate of this bug. ***

Talkbacks with ResolveForwards as crash point have been coming (2005-02-03 nightly is the latest),but I couldn't reproduce it with my trunk debug build on Win 2k. I tried all the test cases mentioned here. This bug is rather elusive. There may be something that trigger this bug only in optimized builds.....

Any idea when this appeared, so we can hypothesize a regression and check bonsai? /be

(In reply to comment #39) > Any idea when this appeared, so we can hypothesize a regression and check bonsai? > > /be In comment #9 I saw a 2 day regression timespan, and I´ve made testcases for this bug, but apparently they were crashing because the making of testcases was corrupting my memory. They were crashing, when after upload I checked per download, but didn´t crash after reboot. I retried some times to reproduce the crash, didn´t succeed.

I tested this with today's Firefox nightly on Windows XP SP2, Windows 98, and Windows 2000 and did not crash. I also ran under purify on XP and didn't see anything unusual in the font code.

I can still crash 100% reproducable with "Testcase - invalid image (crash on View selection source)". Just select a part of the text on the invalid image and do view selection source. This does not crash in 2004-08-01 07:08:00 Firefox trunk build. This does crash in 2004-08-02 08:02:00 Firefox trunk build. 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=2004-08-01+07%3A08%3A00&maxdate=2004-08-02+08%3A08%3A00&cvsroot=%2Fcvsroot I know this is not consistent with other obeservations, but the stack signature of this kind of crash is the same as what this bug has.

identical crashes Firefox/Mozilla trunk with current nightlies on testcase 'invalid image': http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB3658380Q http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB3658195X searching this stack signature gives about 32 Talkbacks, about half of them trunk, and a half thereof Mozilla trunk. http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=+nsFontMetricsWin%3A%3AResolveForwards&vendor=All&product=All&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=bbid Other testcases and URLs don´t show the bug anymore. Today I retried 1.8a3: 2004071903 and got a crash at third try at the URL, and a crash after rebooting, and only loading the bug and the testcase at second try. Comment #7 2004-07-25 I made three testcases, multiply tested crashing while made, and crashing on download after uploading to bugzilla. After reboot, I couldn´t reproduce the testcases. So it seems something has been fixed between 1.8a3: 2004071903 and 2004-07-25 Comment #8 found reason for a reproducable crash having colspan="3" Comment #9 found BuildID 2004071408 not crashing, 2004071609 crashing on URL I didn´t find BuildIDs in following comments, seems the crashes stopped 2004-07-25. As comment 42 states, crashes for testcase 'invalid image' started between 2004-08-01 07:08 and 2004-08-02 08:02 Firefox trunk, so that may be another issue different from that causing the original bug. Comment #29 2004-10-22 crashed on testcase of another bug giving same stack signature, but that build didn´t crash using current nightlies at any of the URLs mentioned here. To 'View Selection Source', you must select something before. I can´t start selecting *in* the message 'The image “https://bugzilla.mozilla.org/attachment.cgi?id=160574” cannot be displayed, because it contains errors.', I only can start the selection from the outside of the string, doesn´t matter if left to right or right to left.

pulling from the blocking list since this may not be the problem it was.

With the <isindex> tag it is also crashing with this stack on view selection source. And this time it is easily selectable. This also crashes 100% reproducable for me.

Some of the TB stacktraces with crash in nsFontMetricsWin::ResolveForwards runs through nsTextFrame::GetPointFromOffset. Maybe someone could put some attention on http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/generic/nsTextFrame.cpp&mark=3901,3906&rev=1.494#3894 The first line contains an assignment and not only comparisons.

*** Bug 286316 has been marked as a duplicate of this bug. ***

I still cannot reproduce this bug at all. No even a single crash so far. Can someone setup a JavaScript script that triggers the crash?

Try a test https://bugzilla.mozilla.org/attachment.cgi?id=171007

I get this assertion (which doesn't involve the font code), and there is no crash. ###!!! ASSERTION: invalid offset passed to GetPointFromOffset: '0', file d:/Mozi lla/tip/mozilla/layout/generic/nsTextFrame.cpp, line 3964

The latest nightly trunk builds crash for me on the mentioned testcases. My very recent MingW debug Mozilla build however, doesn't crash.

WIN98SE testcase3 view selection source on something like 'a searchable index. Enter search' http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB5027858Z nsFontMetricsWin::ResolveForwards [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/gfx/src/windows/nsFontMetricsWin.cpp, line 3872] etc... got another crash TB5027893W don´t think is related.

I can reproduce the crash for the invalid image testcase on WinXP with the Mozilla nightly 2005-04-11 - and that's a MSVC build. I cannot reproduce that with my MinGW Mozilla debug build, though. I'll test that with a MSVC Mozilla debug build on a Win2k machine tonight.

I cannot reproduce this with my MSVC6 Mozilla debug build of 2005-04-09 on my Win2k machine, for all three testcases.

cannot reproduce any testcase on Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050604 Firefox/1.0+ ID:2005060406 windows 2000sp4

crash Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050605 TB6411657X http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB6411657X Steps to repeat: 1. Load testcase 3: https://bugzilla.mozilla.org/attachment.cgi?id=175000 You'll see: This is a searchable index. Enter search keywords:[Textarea] <hr> Select part of the text of the text here above and then do "View Selection Source".This should not crash Mozilla. 2. Select something in the line preceding the [textarea], let's say select 'searchable' 3. Right click -> View Selection Source -> crash You won't crash if you select something following the textarea. I didn´t test other testcases, as I remember they never crashed starting with comment #9, ages ago, and I restested all of them some weeks ago. Seems testcase #3 is the only one still crashing. testing that one first time it didn´t crash, as I selected text below the textbox.

I made testcase 4 from the code of testcase 3 by removing all text, so the text you can select is the text which will crash. <html> <head><title>Select some text and right-click "View Selection Source"</title></head> <body><isindex></body> </html> obsolete, as they don't crash anymore: Attachment 154309 [details]: simple testcase Attachment 160574 [details]: Testcase - invalid image (crash on View selection source)

Comment on attachment 160574 [details] Testcase - invalid image (crash on View selection source) It's not easy to select text here, but if you succeed, you'll crash on 'view selection source'

Both testcases attachment 160574 [details] 'invalid image' and testcase 4 attachment 185411 [details] <body><isindex></body> don´t contain text in the HTML source, but show text provided by Mozilla. That text can´t be selected using 'Select All' shown on right-click, but can be selected normally with left-click. 'Select All' shouldn't be available, when it can't be used besides destroying the selection done with the mouse, i.e. 'select All' here acts only as 'deselect All' Maybe that's bug 294383 Steps to repeat crashes: 1. load testcase 'invalid image' or testcase 4: https://bugzilla.mozilla.org/attachment.cgi?id=160574 https://bugzilla.mozilla.org/attachment.cgi?id=185411 2. select some text in the testcase. I had to try multiple times to get text selected on the invalid image. 3. If you don´t see a selection, return to step 2 Right-Click and click 'View Selection Source'

Still no crash for me. I am (and have been) using a debug build all along. > I had to try multiple times to get text selected on the invalid image. It is not difficult if you select backwards from the end of the line.

->jshin. jshin, can you help us with this for 1.8b3?

I can't reproduce it, either. Herman, can you give me all the details of your font setting when you get crash?

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050614 Firefox/1.0+ ID:2005061421 I can reproduce the crashes on Testcase 3 and Testcase 4. Just select the "This is a searchable index." text, and right click > View Selection Source and Firefox crashes.

(In reply to comment #62) > I can't reproduce it, either. Herman, can you give me all the details of your > font setting when you get crash? excerpts from prefs.js, all.js, and complete listing of the windows fonts directory. identical Talkbacks on different testcases: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050616 http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB6732972H http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB6733192W If you want I can attach about 9 screenshots of about:config with filter 'font', size will be about 12 kb for each one. I also could make screenshots of preferences, if wamted. Should I zip the screenshots to one archive? current settings: View -> Character Encoding -> AutoDetect -> Universal View -> Character Encoding -> Western (ISO-8859-1)

I changed the setting to Autodetect: OFF and still get crashes. Testcase 4 I selected 'searchable index' and didn´t crash on ViewSelectionSource. I closed the source window and retried 5 times, without touching the selection, all went well. Then I changed the selection, and crashed on ViewSelectionSource.

so jshin, does changing the setting to Autodetect: OFF make it reproducable for you?

With a fresh/default profile I crashed using Deer Park 2005-06-21-07-trunk on Windows XP sp2 following calebs simple steps in comment #63 for test cases 3 and 4. note: Using File | View Source doesn't crash those test cases. You must use the context menu for View Selection Source. TalkbackID : TB6867422Q

I still can't reproduce the bug. Just in case, can you check the value of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\LanguagePack] SURROGATE in the Windows registry? It shouldn't make a difference, but who knows? If it's not 2,change it to 2 and see if mozilla/firefox still crashes. (http://www.i18nguy.com/surrogates.html)

(In reply to comment #68) > I still can't reproduce the bug. Just in case, can you check the value of > > HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\LanguagePack] > SURROGATE > > in the Windows registry? It shouldn't make a difference, but who knows? > If it's not 2,change it to 2 and see if mozilla/firefox still crashes. > > (http://www.i18nguy.com/surrogates.html) I don't even have that key. (SURROGATE)

(In reply to comment #69) > (In reply to comment #68) > > HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\LanguagePack] > > SURROGATE > I don't even have that key. (SURROGATE) That's normal. What I meant (I was not clear ) was you need to create it and set to 2. Anyway,never mind. I can reproduce the crash the latest nightly I downloaded from ftp.mozillla.org, but my debug build never crashes (I made sure that files in my tree with functions in the stack backtrace are identical to those in the trunk). Perhaps, I have to build an optimized build and see what I can do.

I wanted to build a optimized build with symbols, but the compilation keeps failing when it comes to building gklayout.dll with an exception from 'cvpack' http://groups-beta.google.com/group/netscape.public.mozilla.builds/browse_thread/thread/736f3b8791ed959b/dbebfc5d57c92f37?q=cvpack+firefox&rnum=1&hl=en#dbebfc5d57c92f37 It appears that older versions of cvpack (before VC++ 6.0) had some problems (there are a lot of news postings and web pages about it), but I can't find any solution to my problem (VC++ 6.0 + SP5). There are a couple of questions about the issue on some lists, but no answer. I'll keep looking. Ahah, perhaps, I have to switch my 'ANSI' locale to English from Korean and see if it helps (in the past, I was able to work around apparent 'VC-related' bugs that way)

(In reply to comment #71) > I wanted to build a optimized build with symbols, but the compilation keeps > failing ..... I have > to switch my 'ANSI' locale to English from Korean and see if it helps Unfortunately, this didn't help. Is there anyone who successfully built an optimzed build of firefox with debug symbols (it's pretty certain that debug builds are fine while optimized build crash so that we need to debug with an optimized build)? I tried to debug with assembly, but my knowlege of x86 assembly is minimal...

Try --enable-optimize --disable-debug --enable-debugger-info-modules=all

I can reproduce with the suggested config from bsmedberg, what am I looking for?

fwiw, on Windows, I use --enable-optimize --disable-debug and I define the env variable "set MOZ_DEBUG_SYMBOLS=1" before building

closing down for 1.8b3, let's try and get this in for 1.8b4

'cvpack' still fails with what's suggested in comment #73. I'll try what's suggested in comment #75. re: comment #74 Can you check whether the value (aLength) passed down from layout/html/base/src/nsTextFrame.cpp (nsTextFrame::PaintUnicodeText) is 'valid'? 3857 nsFontMetricsWin::ResolveForwards(HDC aDC, 3858 const PRUnichar* aString, 3859 PRUint32 aLength, 3860 nsFontSwitchCallback aFunc, 3861 void* aData) In ResolveForwards, we do all the right checks, but still |currChar| (ESI in attachment 154298 [details] (comment #4)) points to an 'invalid address' location.

In light of comment #46, wall-painting-patch (attachment 188695 [details] [diff] [review] to bug 300122) may prevent some (not all) crashes dealt with here. We may be able to come up with a similar wall-painting patch for other cases, but we'd better track down the root cause.

I have finally been able to reproduce this in a debug build. To do so, just comment out the conditional debug "memset" that are sprinkled in the |struct nsAutoIndexBuffer|. It turns out that this bug comes all the way from the content model. There are some operations that lead to gibberish in textnodes (which are later fed to the font code). One particular operation that triggers this crash is when inserting a child textnode to a leaf element such as <index>. In principle, this should fail, but it doesn't. [Since the content mode does allow anonymous nodes, it is not clear if it should indeed fail. But from the DOM functions, it can be argued that <isndex>.insertBefore() should fail rather than insert gibberish. Still, layout shouldn't crash either...] I am attaching a simple patch to protect View-Selection-Source for the common cases. A comprehensive fix would be to prevent the gibberish character data.

> One particular operation that triggers this crash is when inserting a child > textnode to a leaf element such as <index>. There is no such thing as a leaf element in the DOM (consider XML, where the concept really just doesn't exist for a non-validating parser).... Do you have a testcase for this "gibberish character data" thing? That really should not be happening.

Comment on attachment 189507 [details] [diff] [review] Patch for view-selection-source I'm not really following what this patch is doing...

It is a "diff -w". It puts an if () {...} around a big chunk of code, see: http://lxr.mozilla.org/mozilla/source/xpfe/browser/resources/content/viewPartia lSource.js#126 Try View Selection Source on testcase 4 to see what I mean. It gives a childless <isindex>. For such cases, the selection can't be re-mapped because the original selection is within anonymous nodes. So the |if| skips the attempt to re-map since it will fail anyway. To see the corrupted text nodes (gibberish) requires disabling the "memset" that I indicated, and then dumping the content model (see also bug 300122). I am curious about it but had to leave the (long) debugging at that point. In the mean time, let's go with this simple patch to cut the obvious cases.

...to be clear, albeit it should now be obvious, the second |if| stops the |drawSelection| function from being attached as a listener because if no selection has been re-mapped, then there will be nothing to draw too.

*** Bug 301504 has been marked as a duplicate of this bug. ***

Sorry, I didn't realize I wasn't cced on this bug. :( > the selection can't be re-mapped Meaning what? That it doesn't correspond to non-anonymous DOM? What does view selection source show with your change? > In the mean time, let's go with this simple patch to cut the obvious cases. I'm sorry, but if we're ending up with garbage in our content model, we should fix that (blocking 1.8b4+ and all), not just paper over it in the UI.

> To see the corrupted text nodes (gibberish) requires disabling the "memset" > that I indicated, and then dumping the content model Doing this in the layout debugger, I assume? Does doing that on "Testcase 4" show the problem?

So my problem is that status whiteboard claims this is a major tbird crasher. So unless tbird has "view selection source", there's something else going on....

The patch is not meant to fix the root cause of the the bug. Until then, the bug isn't fixed. But I have now gathered per you comment that it is not unusual for <isindex> to get children. It remais to identify if the root cause is something related to munging strings or DOM ranges. It is also seem more and more likely that it might just be a text transform bug, in which case it will explain bug 301104 too. (The dump was by brute force printfs...) --------- As for the suggested |if|-patch, it is something that I would add today if I were to re-write View Selection Source. Basically, what happens is this: for display purposes, <isindex> "mutates" itself in the content model as: <isindex> - <anonymous hr/> - <anonymous text> This is a searchable index. Enter searh keywords: </anonymous text> - <anonymous input field/> - <anonymous hr/> 1. Then, the user selects a part of the anonymous text, and clicks on View Selection Source. 2. View Selection Source identifies that the selected text comes from <isindex> and try to do <isindex>.cloneNode(true/*aDeep*/) so that it can re-map the selection to its underlying markup. But the cloning doesn't go deep because what is inside is anonymous, with no associated markup. Hence it returns a childless <isindex/>. 3. Then, comes the ensuing munging to attempt to re-map the selection into that cloned, childless <isindex/>. And it is this munging that creates the circumstances fitted for the crash (for View Selection Source). So the suggested |if|-patch simply skips the munging, which is unnecessary anyway. View Selection Source simply shows "<isindex>"--as you currently see in debug builds. As I indicated, I would add that |if| today because of this added understanding/scenario. It doesn't change anything, but avoid creating the circumstances of the crash. The same situation happens with broken images because <img> "mutates" itself in an anonymous placeholder text to display the message ("The image ... cannot be displayed... "). I don't understand why it is a tbird crasher, either. There aren't any dups from tbird. Neither was tbird mentioned when the bug was originally marked as topcrash+ in comment 35.

Comment on attachment 189507 [details] [diff] [review] Patch for view-selection-source OK, r+sr=bzbarsky, but we need to figure out the real issue too...

Comment on attachment 189507 [details] [diff] [review] Patch for view-selection-source Asking approval for 1.8b4. The patch doesn't fix the real crash. It instead prevents us from triggering a codepath (in the case of the frequently used View Selection Source) that leads to the crash. Hopefully, it will give us a little breathing space until we find the real root cause of the crash in layout.

bz, there it goes. Happy now?

Comment on attachment 190679 [details] [diff] [review] fix the root cause Not sure why it submitted twice. (For those who are curious, the crash came from outdated pointers.)

Comment on attachment 189507 [details] [diff] [review] Patch for view-selection-source This patch has been checked in. When I right click > View Selection Source on testcase 3 and 4, I get "<isindex>" in the source window instead of some actual text, is this designed behaviour?

wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b4) Gecko/20050727 SeaMonkey/1.0a As the workaround 'Patch for view-selection-source' got checked in, and the real patch to 'fix the root cause' is still waiting for review, that bug is still open, I assume. (In reply to comment #94) > When I right click > View Selection Source on testcase 3 and 4, I get > "<isindex>" in the source window instead of some actual text, is this designed > behaviour? Complete source of Attachment 185411 [details] (testcase 4): <html> <head><title>Select some text and right-click "View Selection Source"</title></head> <body><isindex></body> </html> so there is no more to be seen in the <body> than <isindex>.

Comment on attachment 190681 [details] [diff] [review] fix the root cause So... why does this help? That is, do we end up with a reflow _while_ scrolling or something?

Sort of. It is the other way around. Reflows are made to terminate before we effectively begin to scroll. The scroll under consideration, |nsTypedSelection::ScrollIntoView|, is specific to the selection. It doesn't even ultimately call the |PresShell::ScrollFrameIntoView| -- which is what you seemed to have been thinking of. Since the selection usually wants to scroll at a character within the frame, it has its own self-contained code. It works out where it wants to scroll and calls APIs on the scrollable view directly, much like nsPresShell::GotoAnchor() for example, which already calls FlushPendingNotifications() and takes no chances. But the bug is somewhere else--a little earlier to the actual scroll. The crux of the matter is this: the selection wants to scroll at a character within the frame. Hence, it has to measure the text, using content offsets that are supposed to have been set by the most recent reflow. The crash comes from the fact that the frame under consideration is dirty (it has been dirtied by the munge in the case of View Selection Source). Its content offsets are now outdated and point to potential garbage. It must be reflowed before we dare to call nsTextFrame::GetPointFromOffset(). In fact, the munging effectively triggers some CharacterDataChanged() notifications, but their corresponding reflows are agressively optimized out these days. As the selection code has no idea that these have been deferred, it crashes when it attempts to find out where to scroll. [This king of elusive bug might manifest itself no just with GetPointFromOffset(). There are other APIs that also assume that the frame is ready. It wouldn't be a bad thing to sprinkle them with NS_ASSERTION((mState & NS_FRAME_IS_DIRTY) == 0, "clean up your frame")...]

Comment on attachment 190681 [details] [diff] [review] fix the root cause I see. Put the first half of the third paragraph of comment 97 in this code-level comment, please? And please file a followup bugs on adding the asserts you mention.

Comment on attachment 190681 [details] [diff] [review] fix the root cause Asking a=1.8b4 on this top crasher which is now well understood.

Checked in. Filed bug 302728 for follow-up.