Description of problem: When running pango firefox in a CJK locale, pasting numbers into a editbox makes the cursor movement behave strangely. Also highlighting numeric characters changes their size. How reproducible: everytime Steps to Reproduce: 1. $ LANG=ja_JP.UTF-8 firefox 2. Highlight a number 3. Click on a line with just a number in it. 4. Paste a number into an edit box and keep typing some words. Actual results: 2. The glyphs change size. 3. The cursor goes to the beginning of the line. 4. The number changes size when text is added after it and the cursor falls behind the test. The last character on the line is often not rendered completely. Expected results: 2. no size change 3. the cursor is be at the end of the number 4. editting, cursor movement and rendering to work correctly. Additional info: This is like 138778 but for numeric text.
Getting highly annoying in both firefox and thunderbird: raising priority.
The same is also true for punctuation input into editboxes.
Also the End key brings one to the start of a line if it has only numbers or punctuation in it. Note also how the font of the numbers and/or punctuation changes after input some alphabet after them.
Should be fixed in firefox 1.0.3-1.3.1.
Unfortunately not.
Ok, I should clarify the report a little, since it was pointed out to me that a part of the problem is in pango: In "LANG=ja_JP.UTF-8 gedit" for example if one inputs some numbers and/or punctuation chars at the beginning of a line and then appends other text the change of font of the numbers/punctuations also happens. However cursor placement and the end of line is fine. Not so in firefox/thunderbird: the cursor is placed wrongly and the last character on the line is badly misrendered. This is the issue that needs to be fixed still in moz pango. Scrolling the line in question off screen and back into view shows the last character correctly rendered, however cursor placement remains off.
Bug still exist firefox-1.0.3-4 in dist-FC4. However, I noticed that for firefox-1.0.3-1.4.1 in EL4, I could not reproduce this bug.
Appears to be fixed in mozilla-1.7.7-3 too. :) If this could be fixed next in FC4 firefox and thunderbird that would be great.
Regarding comment #7, keep in mind that EL4 pango is disabled for all languages except Indic, while FC4 pango is enabled on all languages. llch indicated that the EL4 testing was done in ja_JP.UTF-8, which would be pango disabled. If this is the case, then this bug is not fixed for the pango case. In FC4 you can use MOZ_DISABLE_PANGO=1 to test if this is the case. Please verify.
Ooops, scratch comment 8 - mozilla doesn't seem to have pango enabled... doh.
My bad. It slipped my mind that we have special case for EL4. Thanks to warren for pointing out. Tested with firefox-1.0.3-4 (with pango enabled), the bug still exist. However, if I run without pango, everything is good.
Has this bug been reported upstream?
I filed <https://bugzilla.mozilla.org/show_bug.cgi?id=306404>.
This still occurs with Deer Park fwiw.
Firefox (1.5) is still having problem on this. This bug is very obvious and serious when it has these character insert in the sentence ( ) . For instance, for this comment i cannot complete it in the text box directly because of this problem.
Created attachment 123944 [details] bad-moz-pango-tweak.patch This is just a completely naive patch but points at the code/file in question at least: it fixes the rendering in the textboxes but then breaks rendering of numbers and punctuation elsewhere. ;-)
FireFox asdlkfj tyrtrtrerterterterdfgsdfg2233443344234234 12121212
Sorry about that last comment, it was unintentional.
Moving to FC6 and FC5Update because there is no visible progress in this report and we are out of time.
Sorry for taking so long to respond to this bug, I'm not familiar with firefox or pango but after a little debugging I think I know what the problem is, or at least part of it. The font that is selected by pango/firefox for rendering numeric characters in that locale is different from the font selected for rendering latin characters which is easy to see if you type in a string of characters such as "1111a" as the font will change when you type the 'a' character. The nsTextFrame class as part of the text layout process calls nsTextFrame::MeasureText which breaks up the string contained in the layout(firefox uses one layout per line as I understand it) into white space delineated substrings/words and then calls nsFontMetricsPango::GetTextDimensions on each substring/word. nsFontMetricsPango::GetTextDimensions gets the text dimensions for each substring by creating a new layout, setting the text to the substring and getting the total dimensions/extents from that. The problem is that when it does this on a string such as "1 12 123 1234 ab" it looks as if the font used in each layout is dependant on the code points of the characters in each substring, so in that case the width for the first four substrings will be calculated incorrectly because the width of the font used for numeric characters is narrower in than that font used for the latin characters. As the original or displayed layout uses the wider latin font it messes up the cursor position and creates drawing/expose errors in the text area. If someone more familiar with pango would like to comment, I've really only just started on this problem so it would be good to know that I'm on the right track.
I just noticed bug 132527 and comment #11 by Owen Taylor seems very similar to the behaviour I described in comment 28, just making a note of it for future reference.
I can't reproduce this in the context of bugzilla.redhat.com anyway anymore with current fc6 firefox. Still happens on firefox-1.5.0.4-1.2.fc5 though.
also still happens on firefox-1.5.0.6-2.fc5. but not when any bitmaps font are used for rendering. it sounds like this issue is caused by another library, such as pango, cairo and freetype. On FC5, $ rpm -q pango cairo freetype firefox pango-1.12.3-1 cairo-1.0.4-1 freetype-2.1.10-5.2.1 firefox-1.5.0.6-2.fc5 On FC6, $ rpm -q pango cairo freetype firefox pango-1.13.5-1 cairo-1.2.0-2 freetype-2.2.1-3 firefox-1.5.0.5-8
I think the debug info in comment #28 is valid, if pango changes the glyph usage when editing, hence it will change its glyph metric/layout during editing. Tim, did you have any draft patch? Reassigning from Tim to Tagoh-san.
changed the version to fc5, since this no longer appears on the latest firefox and libraries sets.
Unfortunately I still see the problem now again with FC6 final.
Is this still reproducable with firefox-1.5.0.10-5.fc6?
Yes and in F7. :-/ It is easy to reproduce if you run it in a CJK locale.
Fedora Core 6 is no longer supported, could you please reproduce this with the updated version of the currently supported distribution (Fedora 7, 8, or Rawhide)? If this issue turns out to still be reproducible, please let us know in this bug report. If after a month's time we have not heard back from you, we will have to close this bug as CANTFIX. Setting status to NEEDINFO, and awaiting information from the reporter. [This is mass-filed message to all open Fedora Core 6 bugs related to Xorg or Gecko. If you see any other reason, why this bug shouldn't be closed, please, comment on it here.]
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as INSUFFICIENT_DATA. {This is mass-closing of all obsolete bugs; if this bug was in your opinion closed by mistake, please, reopen it with additional information; thanks a lot and I am sorry for bothering you in such case.}
It was noted that this happens in F7 still, possibly F8 too.
Since this bugzilla report was filed, we have seriously upgraded Gecko-related packages, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their distribution available. Please, confirm to us that this bug is reproducible on the latest upgrade of the supported distribution (that's RHEL, or Fedora 7, 8, and Rawhide). Setting the bug to NEEDINFO. If I won't get confirmation of reproducability in 30 days, the bug will be closed as INSUFFICIENT_DATA. [This is mass-changing of bugs which seem to be too old and irrelevant anymore; we are sorry, if this bug should not be incldued.]
At this point, we're going to only be taking security fixes and major stability fixes into this release of Fedora. However, we still want to ensure the bug is fixed in the next version. We'd appreciate if you could test Firefox 3, available at http://www.mozilla.com/en-US/firefox/all-beta.html or now shipping as the default in Fedora rawhide and provide feedback as to whether it still exists so we can file a ticket upstream to try to fix it in Firefox 3 before it is released.
Yes this is fixed in Firefox 3. Moving bug to Fedora 8.
Going to resolve this out as NEXTRELEASE then, since it'll be fixed in F9.