In the URL, the letters should be orderer "a b", because the PDF,RLE sequence in the middle has the net effect of not changing the embedding level of any character. However, the URL is rendered as "b a". The reason is that BidiResolver::embed() always behaves as if the embedding operation creates a run boundary (and so terminates the current run and sets the "last" and "last strong" directions for the next run).
<rdar://problem/6304805>
Created attachment 24550 [details] Fix for the HTML/CSS flavor of this bug, including change log and regression test The bug affects both the use of Unicode bidi control characters (such as in the URL) and the use of the CSS 'direction' and 'unicode-bidi' properties. This patch fixes the bug only for the latter case. I suggest doing this first, and keeping the bug open.
Comment on attachment 24550 [details] Fix for the HTML/CSS flavor of this bug, including change log and regression test r=me, with no hesitation.
Fix for the HTML/CSS flavor landed in <http://trac.webkit.org/changeset/37828>.
As mentioned in Comment 04, the fix for this bug has landed. Is there anything further required here? Can this be marked as "RESOLVED FIXED"? Thanks!
The comment says that the fix for one version of the bug has landed, and implies that the version of the bug as reproduced by the markup in the URL isn’t fixed. Testing with that markup now, it appears to be fixed as well, so I think it’s OK to mark the bug as a whole as resolved.
Yes - it is matching across all browser based on following and showing just & symbol across all browsers (Safari 15.5, Chrome Canary 105 and Firefox Nightly 103): data:text/html,<div style="direction: rtl; text-align: left;">‫a‬‫b‬</div>
The & symbol is just because something must have changed in how data: URLs typed in the address field are handled. I tested by pasting everything after the comma into an HTML file and opening it in the browser.
Adding JSFiddle to make it easier for anyone to test this in future - https://jsfiddle.net/0Lk8qdhc/