On the test page you will see three sentences. The third sentence should be written from Right To Left. It is not. It is displayed 'normally' or LTR To be fair, Nova does not handle this properly, nor does IE4. This bug is valid for all current (Mar10) builds of Seamonkey.
setting QAC to myself
nglayout and 5.0 will not be supporting full BIDI layout. So I'm marking this bug as LATER.
resetting later resolution accidentally removed
reopen to reassign
I presume BDO ~ BiDi; mkaply is this yours or fixed or ...
This will be fixed in the Bidi code coming soon....
Can I get this HTML page on an external server somewhere to test with the IBMBIDI changes?
sorry, the url link was just old; all these tests are of course available outside the firewall.
This bug will be fixed when IBMBIDI is turned on in the build.
*** Bug 9100 has been marked as a duplicate of this bug. ***
Fixed in current build
Chaning QA contact. HTML issue.
BDO element is not working on the Mac July 10th branch or trunk builds (2001071005). http://mozilla.org/quality/browser/standards/html/bdo.html Third paragraph should flow from right to left but doesn't.
I think this is Mac-only (actually, it's probably Bidi-unaware-only). Marking pp.
Is this element not working only when bi-directional text is turned on? cc: montse
Moving to Bidi component. Should QA change also?
any update to this bug? With bi-di support now, can this be fixed soon?
Montse or Mike - any updates to this? How often is this element used on web pages?
There is no work being done on Mac Bidi support right now. I don't believe the skills exist.
Per lchiang's request, let me add some comments. AFAIK, BDO element is used primarily in the following types of situations. 1. The document contains multilingual text and Bidi Algorithm will apply to such a text. 2. Under some circumstances, e.g. MIME compliant mail agents might have already applied RtoL formatting. If the bidi-alorithm is applied again, this will produce incorrect order. The web author can retain full control of text directionality with the BDO element. I am thinking that the possibility of using BDO in web pages might be small. For e-mail agents, the situation may not be that uncommon, e.g. English msgs with Hebrew embedded. So the question to me is that do we handle Hebrew/English mail messages OK most of the time? Given that this bug is for Mac only and the fact that the BDO element is designed to handle a small percentage of cases, I am not sure if fixing this is of urgent nature.
is this really mac only? If it is how did bug 9100 get duped to this bug?
Don't know if it's Mac-only, but <bdo> is functional in Mozilla 0.9.5 for win32.
BDO is not working for me on Mozilla 2001121303 on Windows ME. Testcase: http://mozilla.org/quality/browser/standards/html/bdo.html Actual results: The third sentence is written from left to right. Expected results: The third sentence should be written from right to left. Even though Latin characters have inherent left-to-right directionality, BDO is supposed to override it. http://www.w3.org/TR/html4/struct/dirlang.html#h-8.2.4 8.2.4 Overriding the bidirectional algorithm: the BDO element dir = LTR | RTL [CI] This mandatory attribute specifies the base direction of the element's text content. This direction overrides the inherent directionality of characters ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This may be the same as bug 9100.
change platform to ALL. Looks like a regression. N6.2 is fine on WinNT4J but trunk build is bad now. reassign to smontagu
Let's keep this one as mac-only. The all-platform regression is bug 115921, which dbaron checked in the fix for today.
ftang or zach, can you test http://mozilla.org/quality/browser/standards/html/bdo.html and http://bugzilla.mozilla.org/showattachment.cgi?attach_id=61906 on a current Mac build and close this bug if they appear correctly?
*** Bug 119130 has been marked as a duplicate of this bug. ***
In the Mac OSX and Mac 0S Classic Jan 30th builds , the bdo test renders correctly now. http://mozilla.org/quality/browser/standards/html/bdo.html
That's good. I wonder which change fixed this. Perhaps the bug can be marked WFM by the owner unless we know specifically the fix which addressed this. Thanks.
This will have been fixed by the fix to bug 116976 and/or bug 116982 (depending on Mac system).