I came across this problem working on the decoder for ISO-8859-6.8x fonts (bug 78201). Arabic lam-alef ligatures are split into two glyphs in this encoding, and this caused layout problems. setting MOZILLA_GFX_DISABLE_FAST_MEASURE=1 in my environment removed the problems. Steps to reproduce: Apply http://bugzilla.mozilla.org/attachment.cgi?id=101636&action=view Install an ISO-8859-6.8x font or fonts (e.g. http://www.langbox.com/AraZilla/linux/arafontfull-1.2-4.i386.rpm) Load the testcase which I will attach shortly. Expected/actual results: described in the testcase.

I need a little bit help here - the fast text measuring code is disabled on non-Linux/x86 platforms (see http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsRenderingContextGTK.cpp#213) and I am mainly doing development on Solaris/SPARC where the problem won't occur...

rbs: Is there any known interaction problem with the |GetTextDimensions()|-code and BiDi text layout ?

smontagu: Can you try to turn-off |NS_RENDERING_HINT_FAST_MEASURE| selectively for the following two codepoints and check if the problem goes away: a) http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsTextFrame.cpp#4651 b) http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsTextFrame.cpp#4958

>Can you try to turn-off |NS_RENDERING_HINT_FAST_MEASURE| selectively for the >following two codepoints and check if the problem goes away: >a) >http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsTextFrame.cpp#4651 Turning off NS_RENDERING_HINT_FAST_MEASURE here makes the problem go away >b) >http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsTextFrame.cpp#4958 Turning it off here causes a hang :-(

Filed bug 173013 ("Need workaround for problem with layout of Arabic lam-alef ligatures and nsRenderingContext{GTK|Xlib}::GetTextDimensions()") to get a workaround per feedback in comment #5 ...

Reassigning to myself for now. rbs, do you have any thoughts on this?

I am not sure what is happening. You might want to debug to see the new interaction that your patch in comment 0 is producing. From there on, there will hopefully be more data as to what is causing the problem.

This was fixed by bug 188759.