User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 Build ID: 20120215223356 Steps to reproduce: Clicked on "See more" link to see complete text of a comment on Facebook. The comment was in Persian language. Actual results: For some of the comments the last paragraph is not shown in right-to-left style. The characters are reversed and I have to read the text from left to right. Even refreshing the page cannot help. The expected behavior is attached as a screenshot (captured on Chrome 17) and saved as "Chrome.png" Expected results: All paragraphs must be shown in right-to-left style. The expected behavior is attached as a screenshot (captured on Firefox 10.0.2) and saved as "Firefox.png"
Hello Isaac and thanks for your bug report. I think that the issue you are facing is known to us and was fixed in Firefox 10. Can you please check if this occur on Beta/Aurora builds? ref: dupe of bug 704837?
Thanks for the reply. The issue is solved on Aurora (Firefox 12). The issue is still present on Beta (Firefox 11). So I guess this bug report should be closed appropriately (I am not familiar with Bugzilla and would be grateful if somebody take care of it). Is it possible to apply this fix to Firefox 11? I even believe this issue should be solved in the next patch for Firefox 10. As we know, Facebook is very popular all around the world and "right-to-left language people" will be disappointed by this bug.
Could you please provide a link to a (publicly-accessible) page where this issue happens? I'd like to be able to reproduce it and confirm the fix (and possibly nominate it for the Beta channel), so I tried looking at a few Facebook pages where there were Arabic/Persian comments using Firefox 10 (release) and FF 11 (Beta), but did not see an example of this problem.
I've posted some comments on a note on Facebook. Here is the URL to the note: https://www.facebook.com/note.php?note_id=357674600930454 Apparently this issue only happens for the long comments where you should click on "See more" to see the rest of a comment. Apparently this issue only happens for comments on the notes. The comments on posts/pictures/etc are shown correctly in my experience.
Thanks, that's very helpful. Confirming that this bug affects FF10 and 11 (beta), but is fixed in 12 (aurora). If we can identify the fix, I think we need to seriously consider taking it on the beta channel, as this is a pretty bad regression. .elbadaernu yllaitnesse devlovni txet eht sredner gub sihT
Broken up to: http://hg.mozilla.org/mozilla-central/rev/402b394b6623 (2012-01-26) Fixed on m-c: http://hg.mozilla.org/mozilla-central/rev/c07595bee6cf (2012-01-27) So this was fixed by something within the range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=402b394b6623&tochange=c07595bee6cf My initial guess is that it might be bug 718236.
Component: Untriaged → Layout: Text
Product: Firefox → Core
QA Contact: untriaged → layout.fonts-and-text
(In reply to Jonathan Kew (:jfkthame) from comment #6) > My initial guess is that it might be bug 718236. I tried applying the patch from bug 718236 to mozilla-beta, but this did _not_ fix the problem. Further investigation needed...
(In reply to Jonathan Kew (:jfkthame) from comment #7) > Further investigation needed... Bug 704837 is a good bet. Very similar issue which supposed to get fixed on Firefox 10.
Tracking for FF11, although it's not yet clear that this was a regression first seen in FF10. Adding the regressionwindow-wanted keyword and including QA on the CC list to find out when this first regressed. Once we find a regression window, it may be possible to pull together a low-risk backout instead of a forward fix. Please keep in mind that if there's a desire to land this for FF11, we'd be much more likely to approve if nominated before tomorrow evening's (2/28) beta 5 go-to-build.
(In reply to Jonathan Kew (:jfkthame) from comment #7) > I tried applying the patch from bug 718236 to mozilla-beta, but this did > _not_ fix the problem. Further investigation needed... OTOH, reverting the patch in trunk does cause the bug to reappear. Note also that the bug seems to be only reproducible when the UI language of Facebook is LTR. A minimized testcase would help a great deal.
The original regression appears here (from m-c nightlies): OK: http://hg.mozilla.org/mozilla-central/rev/161c6106d787 (2011-11-07) Bad: http://hg.mozilla.org/mozilla-central/rev/81dedcc49ac0 (2011-11-08) From the pushlog range http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=161c6106d787&tochange=81dedcc49ac0, the likeliest culprit looks to me like bug 698706. But that was itself fixing a regression from bug 613149...
So after further builds and testing, it looks like bug 718236 _does_ resolve this - I must have messed something up earlier (comment 7). Simon has a tryserver build in progress that we'll double-check shortly, but I think we should take bug 718236 on beta ASAP to fix this issue for FF11. (Try builds will be at http://firstname.lastname@example.org.)
I checked behavior of tryserver builds on Mac, Win & Linux, and all worked properly, with no reversed text.
Clearing regressionwindow-wanted, see comment 11. This was a regression from bug 698706, and the suggested fix is to take bug 718236 on beta.
Bug 718236 has just been landed on mozilla-beta, which should fix this for Firefox 11. Resolving this as a dupe of 718236.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 718236
You need to log in before you can comment on or make changes to this bug.