###!!! ASSERTION: mStart >= 0: '(sdptr->mStart >= 0)', file nsTextFrame.cpp, line 6545 STEPS TO REPRODUCE 1. Load URL 2. Edit -> Select All (or CTRL+A)

Martijn, do you think you can testcase this?

I've managed to minimise it to this. somewhere in that Arabic text, Mozilla gives an assertion when selecting that text.

Comment on attachment 207134 [details] testcase Martijn, I assume the testcase should be viewed as UTF8, right?

Uriber, Simon, any idea how we can fix this? The relevant part of nsTextFrame (where we assert) is: 6709 // temp fix for 75026 crasher until we fix the bidi code 6710 // the above bidi code cause mStart < 0 in some case 6711 // the problem is we have whitespace compression code in 6712 // nsTextTransformer which cause mEnd > textLength 6713 NS_ASSERTION((sdptr->mStart >= 0) , "mStart >= 0"); 6714 if(sdptr->mStart < 0 ) 6715 sdptr->mStart = 0;

I see no assertion in the testcase. Under what OS and buildconfig does the assertion occur?

I'm using WindowsXP with MingW.

I'm using Linux, both GTK1 and GTK2 builds. Note that just selecting the text with mouse doesn't assert, but Ctrl-A does.

I'm on this. I think we need to map lam alef sequences in the content to lam alef ligatures in the rendered text around http://lxr.mozilla.org/seamonkey/source/layout/generic/nsTextFrame.cpp#2198

This also has the effect of making caret movement treat a lam alef ligature as a single "character", which I *think* is what bug 79286 is about, although it has never been clearly explained. Before I ask for reviews I will do some research on which behaviour Arabic speakers prefer.

Comment on attachment 210271 [details] [diff] [review] improved patch OK, it turns out that moving the caret over lam-alef as a single unit is NOT the behaviour desired by most users. However, I think it's the lesser of two evils, taking into account that this also fixes the serious bug 271057.

Comment on attachment 210271 [details] [diff] [review] improved patch Frankly I don't have a clue about this stuff, so I'm giving a rubber-stamp.

BTW, see http://weblogs.mozillazine.org/roc/archives/2006/02/post_1.html (which I just wrote because I realized more people need to know about this). It's not worth investing much energy in trunk nsTextFrame unless we want the patches on a FF1.5 or FF2 branch.

Fix checked in.