Open Bug 324609 Opened 19 years ago Updated 2 years ago

Ellipsis ignores complex clusters causing incorrect rendering in tab titles and tree views

Categories

(Firefox :: Tabbed Browser, defect)

defect

Tracking

()

UNCONFIRMED

People

(Reporter: devel, Unassigned)

References

Details

(Keywords: intl)

Attachments

(2 files)

User-Agent: Mozilla/5.0 (X11; U; Linux i686; my-MM; rv:1.8) Gecko/20060106 Firefox/1.5 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; my-MM; rv:1.8) Gecko/20060106 Firefox/1.5 The ellipsis in tabs does not take into account cluster information in complex scripts e.g. Myanmar. This causes the position of the ellipsis to be wrong. The same affect is also seen in tree views such as the history side bar. The ellipsis algorithm incorrectly computes the length of the string, because it ignores the context and computes length character by character. In general this can cause the ellipsis+text to either be far shorter than it needs to be or longer than it should be. Reproducible: Always Steps to Reproduce: 1.Install pangographite from svn://scripts.sil.org/graphite 2.Install the Padauk Myanmar Unicode font e.g. from http://downloads.mozdev.org/sila/fonts/padaukg.zip 3.Open a page with a Myanmar Unicode title containing virama characters (U+1039) in a version of Mozilla compiled with --enable-pango. The bug affects all versions of mozilla that support the GetClusterInfo method on nsRenderingContext. (Actually it affects other versions, but they don't support Myanmar Unicode anyway) It is likely to affect any complex script using Pango for rendering that has context dependent rendering of characters. Actual Results: The composite cluster gets broken up by the ellipsis causing different glyphs to be rendered than would be rendered if the clusters were taken into account. This can be seen in the ellipsis in Tab titles and in the tree view in the history sidebar. It also affects the titles of messages in the message listing of Thunderbird. The affect can be seen by varying the width of the tab or tree view to change the position of the ellipsis. Expected Results: The clusters should be taken into account so that the glyphs rendered before the ellipsis are the same as if there was no ellipsis. The ellipsis should be positioned so that it neetly fits within the tab, not over or under flowing because the context was not used in measuring the length. Attachments and patch to fix will follow.
Attached file titleEllipsis.html (deleted) —
Open this document in a graphite pango enabled version of Firefox with more than one tab open. Vary the width of the window to move the position of the ellipsis and see the problem. Open the history side bar and see the same problem in the title of the web page in the sidebar. Vary the width of the sidebar to move the position of the ellipsis.
Patch for Firefox 1.5 codebase. The ellipsis handling code is found in nsTextBoxFrame.cpp and nsTreeBodyFrame.cpp, which have almost the same ellipsis algorithm. The patch implements right, left and middle ellipsis context analysis, however, only the right ellipsis has been tested. Does anyone know an easy way to trigger the middle and left ellipsis code?
Middle ellipsis happens in Seamonkey when you hover an anchor with a long URI (there's a middle ellipsis in the status bar)...
In Firefox 1.5 (the build which I used to test the patch) the anchor in the status bar has a right ellipsis. However, I was able to test the middle ellipsis code using a filename in Myanmar language. If a page does not have an HTML title the full path to the file is shown in the Tab title with a middle ellipsis. In this case, the patch appears to be working correctly with the middle ellipsis.
Depends on: grapheme-breaker
Keywords: intl
OS: Linux → All
Hardware: PC → All
This bug was reported using Firefox 3.0 or older, which is no longer supported. The bug has also not been changed in over 500 days and is still in UNCO. Reporter, please retest this bug in Firefox 3.6.10 or later using a fresh profile, http://support.mozilla.com/en-US/kb/managing+profiles. If you still see this problem, please update the bug. If you no longer see the bug, please set the resolution to RESOLVED, WORKSFORME. This is a mass search of unconfirmed bugs that have no activity on them, so if you feel a bug was marked in error, just remove the CLOSEME comment in the whiteboard within the next month.
Whiteboard: [CLOSEME 2010-11-15]
I can still reproduce this in firefox 4.08b8pre on Linux. For example, it occurs in the tab title for http://my.wikipedia.org/wiki/%E1%80%9C%E1%80%B1%E1%80%80%E1%80%BC%E1%80%B1%E1%80%AC%E1%80%84%E1%80%BA%E1%80%B8%E1%80%94%E1%80%BE%E1%80%84%E1%80%B7%E1%80%BA%E1%80%A1%E1%80%AC%E1%80%80%E1%80%AC%E1%80%9E%E1%80%95%E1%80%8A%E1%80%AC I would expect to only see လေ... လေကြော... လေကြောင်း... as I adjust the window width, but I also see လေကြ... လေကြေ... လေကြောင... etc. "လေကြ" is especially confusing since the reordered ​ေ is lost from in front of ကြ. You will need a Myanmar Unicode font to test this. e.g. http://scripts.sil.org/Padauk
Whiteboard: [CLOSEME 2010-11-15]
Version: unspecified → Trunk
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: