fillText ignores canvas RTL unless canvas is member of the DOM

• Component: Canvas
• Status: NEW ---

[Richard Davey]

Demo: http://codepen.io/photonstorm/pen/peLyyX?editors=1010

Issue:

The canvas fillText function ignores the canvas dir and canvas.style.direction properties unless the canvas itself has been added to the DOM.

For example this works fine:

```
var str1 = "این یک آزمایش است.";

var canvas = document.createElement('canvas');
canvas.dir = 'rtl';

document.body.appendChild(canvas);

var ctx = canvas.getContext('2d');
ctx.font = '48px serif';
ctx.fillStyle = '#ff00ff';
ctx.fillText(str1, 500, 100);
```

The Arabic text will respect the canvas dir attribute and render correctly. However if you do not add the canvas to the document body, it will ignore the dir property entirely, making this fail:

```
//  However if the canvas is NOT added to the document.body then it's clear that
//  fillText ignores the RTL setting entirely, as seen below:

var canvas3 = document.createElement('canvas');
var ctx3 = canvas3.getContext('2d');

//  Both of the following are ignored, because the canvas isn't in the DOM
canvas3.dir = 'rtl';
canvas3.style.direction = 'rtl';

canvas3.width = 600;
canvas3.height = 600;

ctx3.font = '48px serif';
ctx3.fillStyle = '#00ff00';

ctx3.textAlign = 'end';
ctx3.fillText(str1, 500, 300);

ctx.drawImage(canvas3, 0, 0);
```

You can see all of this, plus more examples here: http://codepen.io/photonstorm/pen/peLyyX?editors=1010

I don't know if this behaviour matches the spec or not as I couldn't find anything specific to this issue in it, but it doesn't really make sense (on a logical level, maybe on a technical one it does).

[Radar WebKit Bug Importer]

<rdar://problem/31255558>

[Said Abou-Hallawa]

Created attachment 305532 [details]
test case

[Said Abou-Hallawa]

Created attachment 305534 [details]
test case

[Matan Rosenberg]

Hey. Just wondering that is the status of this issue - is it going to be fixed sometime soon?

Thanks!

[Ahmad Saleem]

I am still able to reproduce this bug using attached test case in Safari Technology Preview 178. Second and Third line has incorrect . and ( compared to Chrome Canary 119 and Firefox Nightly 119, which match each other.