See upcoming testcase.
I get this assertion in my debug build when hovering over the text:
###!!! ASSERTION: invalid BC damage area: 'PR_FALSE', file c:/mozilla/mozilla/la
yout/tables/nsTableFrame.cpp, line 4577
Created attachment 202242 [details]
Created attachment 234594 [details]
Sometimes we get a zero-width damage area to SetBCDamageArea().
After doing "newRect.width = PR_MAX(1, newRect.width)" it is possible
that it's an invalid damage area (that reaches beyond the last column).
Created attachment 234595 [details] [diff] [review]
This patch fixes the assertion by adjusting 'x'...
An alternative would be to leave 'x' as is unless it's the last col.
Crashed on this too whilst testing a fx 126.96.36.199 debug build on a Win98 box. Machine was too hosed to do very much, but what data I got I shall add as an attachment, in case anyone needs it.
Looking at #3 it looks like this one is fixed, though?
Created attachment 262239 [details]
Stack trace of this crash on fx2003/win98se
When testing the top sites with a debug trunk linux build earlier this week, I got this assertion 24985 times on 23524 pages. At the time, it made this assert the 2nd most common but since bug 394384 was fixed, that makes this the top assertion. An example reproducible with today's build is <http://telemundo.yahoo.com/_ylh=X3oDMTFhZWw1b3JpBF9TAzg5NTQyNjEEcGlkAzIwMjcyNAR0ZXN0AzAEdG1wbANlMV9pbmRleA--/r/tmc>
>Sometimes we get a zero-width damage area to SetBCDamageArea().
Is that the root cause?
to be more clear, I am afraid of wall papering.
>An alternative would be to leave 'x' as is unless it's the last col.
that sounds better to me, but I would like to get the zero width SetBCDamageArea() fixed.
Created attachment 309584 [details]
C++ and JS stack of GMail
So I get this in GMail too. Wonder if we should care more about this assertion?
Comment on attachment 234595 [details] [diff] [review]
There's a better fix in bug 460637.
this is fixed by bug 460637, as the testcase involves hovering it makes no sense to check it in as it is.