Bug 42048 – Hebrew with 'charset=iso-8859-8' and 'dir=rtl' displayed incorrectly

• Component: Layout and Rendering
• Status: RESOLVED DUPLICATE

[Opher Shachar]

I'm using Google Chrome to open the attached html page.
The second row in the table is rendered incorrectly in Chrome.

These browsers display the page correctly:
  Firefox 3.x: OK
         IE 7: OK
         IE 8: OK

What steps will reproduce the problem?
1. open attached html file in IE, FF and Chrome
2. the second row in the table is rendered incorrectly in Chrome.

What is the expected result?
The second row in the table should be rendered as in IE and FF.

What happens instead?
Hebrew in the second row in the table is backwards as if Chrome is ignoring 
the 'dir=rtl' attribute.

Please provide any additional information below:
RFC1556 defines 'Visual directionality' (indicated by 'charset=iso-8859-8') 
as:
   Visual directionality is a presentation method that displays text
   according to the primary display direction only, which is left to
   right.  All text is viewed in the same direction which is the primary
   display direction.  The displaying application is not aware of the
   contents direction and displays the text as if it were a uni-
   directional text. ...

When an element has 'dir=rtl' attribute IE and FF treat the "primary display 
direction" as being Right-To-Left. Chrome does not.

Over at Chrome issue tracker http://code.google.com/p/chromium/issues/detail?id=38197#c4 this was confirmed to also be a problem with Safari.
Comment 6 later on requested for the issue to be upstreamed.

[Opher Shachar]

Created attachment 61181 [details]
a html page to produce the problem

[Opher Shachar]

Created attachment 61182 [details]
A screenshot of the page as rendered by IE8 and Chrome

[Jeremy Moskovich]

(I can repro this on a nightly, so marking as new)
Fady: BiDi bug involving tables, any chance you could take a look?

[Ilya Konstantionov]

Created attachment 71883 [details]
Testcase without tables

This bug is not specific to tables. Here's a very simple testcase: view in WebKit, compare to Mozilla & IE.

[Jeremy Moskovich]

Comment on attachment 71883 [details]
Testcase without tables

Ilya: The reason your example doesn't display correctly is because bugzilla outputs a "Content-Type" HTTP header declaring the encoding as UTF-8 which takes precedence over the meta tag you declare.

Your example works fine if loaded locally and FF render this the same as WebKit when loading from bugzilla.

See http://www.w3.org/International/questions/qa-html-encoding-declarations#precedence .

[Alexey Proskuryakov]

I've fixed MIME types in Bugzilla (that's done via attachment Details page)

[Jeremy Moskovich]

Duping to 52128 since that bug's a little cleaner.

Ilya: Sorry, my mistake - your testcase does show the bug.  I'll move it over...

*** This bug has been marked as a duplicate of bug 52128 ***