It hits ASSERT(run.charactersLength() >= run.length()) in textWidth(). for example: http://build.webkit.org/builders/GTK%20Linux%2064-bit%20Debug%20WK1/builds/4983 http://build.webkit.org/builders/EFL%20Linux%2064-bit%20Release%20WK1/builds/2321
Some
It is not obvious from code what the difference is between Mac and other platforms.
Non-Mac platforms don't define ENABLE_8BIT_TEXTRUN to 1, so the TextRun constructor implicitly converts the character data to a WTF::String. The length parameter that's passed to the TextRun constructor is then ignored, and the length of the complete string is used.
(In reply to comment #3) > The length parameter that's passed to the TextRun constructor is then ignored, and the length of the complete string is used. The length parameter is actually used as the xpos value rather than the length. Anyway, enabling the 8-bit text runs works for the GTK port. Modifying the TextRun construction in the textWidth function would likely work equally well. The 8-bit TextRun was introduced in bug #96979, but was only enabled for the Mac port because code of other platforms needed additional modifications to properly support the introduced optimization. https://bugs.webkit.org/show_bug.cgi?id=96979#c9 The GTK port doesn't seem affected when running the tests with the support for 8-bit text runs enabled, so simply enabling the feature define would work. I'd also like to see people test out the feature on other ports and provide the proper changes so the define can be removed entirely.
Ah ok. Thanks for looking into this. We should really make String(const char*) explicit to avoid bugs like this.
ENABLE_8BIT_TEXTRUN guards were removed by https://trac.webkit.org/changeset/163478 So let's go ahead.
Created attachment 223334 [details] Patch
Comment on attachment 223334 [details] Patch Clearing flags on attachment: 223334 Committed r163537: <http://trac.webkit.org/changeset/163537>
All reviewed patches have been landed. Closing bug.