"failed to find text segment" assertion during resize reflow

VERIFIED WORKSFORME

Status

()

Core
Layout
P3
normal
VERIFIED WORKSFORME
18 years ago
18 years ago

People

(Reporter: Chris Waterson, Assigned: Chris Waterson)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2+], URL)

(Assignee)

Description

18 years ago
To reproduce:

1. With viewer at it's "initial" size, visit www.cnet.com

2. After the page loads, gradually resize the page, making it larger. You'll 
eventually hit a series of assertions, starting with:

  nsTextFrame::MeasureText() line 3776 + 40 bytes 

which is:

  NS_ASSERTION(lastSegment < textRun.mNumSegments, "failed to find segment"); 

From buster, "It usually indicates that some frame isn't returning a legit 
nsReflowStatus when it is reflowed. The block code goes crazy trying to split a 
frame that can't be split."

Robert, is this yours?
(Assignee)

Comment 1

18 years ago
nominating as nsbeta2, per buster.
Keywords: nsbeta2

Comment 2

18 years ago
minor miscommunication:  the follow-on assertions in nsBlockFrame that happen 
later typically "indicates that some frame isn't returning a legit 
nsReflowStatus when it is reflowed. The block code goes crazy trying to split a 
frame that can't be split."  
The assertion in nsTextFrame is probably the root cause of the later assertions.
Not sure if this is mine or not. My real changes here are commented out because 
they trashed mailnews; what's left should act the same as what was there before. 
If you like, you can just back out my changes to MeasureText, since 
justification doesn't depend on them at all.

[I do think that my original changes addressed a real problem: if 
textRun.mBreaks[lastSegment] > numCharsFit then that segment does not fit, even 
if things mostly work as long as we pretend that it does. Another project for a 
rainy, post-thesis day would be to figure out what's really going on there.]

For this bug, it would seem that the rendering context's GetWidth is returning a 
bogus numCharsFit, that doesn't agree with textRun.mBreaks. Of course, it could 
be the textRun that's confused.

Comment 4

18 years ago
Putting on [nsbeta2+] radar for beta2 fix. 
Whiteboard: [nsbeta2+]
I can't commit to handling this for nsbeta2. Someone else better take it, that'd 
be buster I guess.
(Assignee)

Comment 6

18 years ago
stealing
Assignee: roc+moz → waterson
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

18 years ago
Target Milestone: --- → M17
(Assignee)

Comment 7

18 years ago
Well, I'm not seeing this anymore, and www.cnet.com is working fine now. 
Unfortunately, I didn't save the original web page that was causing the 
problem, so marking WORKSFORME.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME

Comment 8

18 years ago
Based on Chris W's comments, marking verfiied works for me.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.