WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED CONFIGURATION CHANGED
19839
A PDF,RLE sequence that should be a no-op affects bidi reordering
https://bugs.webkit.org/show_bug.cgi?id=19839
Summary
A PDF,RLE sequence that should be a no-op affects bidi reordering
mitz
Reported
2008-07-01 00:52:43 PDT
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).
Attachments
Fix for the HTML/CSS flavor of this bug, including change log and regression test
(89.21 KB, patch)
2008-10-21 23:20 PDT
,
mitz
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
mitz
Comment 1
2008-10-20 14:04:48 PDT
<
rdar://problem/6304805
>
mitz
Comment 2
2008-10-21 23:20:00 PDT
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.
Sam Weinig
Comment 3
2008-10-23 14:42:43 PDT
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.
mitz
Comment 4
2008-10-23 14:57:23 PDT
Fix for the HTML/CSS flavor landed in <
http://trac.webkit.org/changeset/37828
>.
Ahmad Saleem
Comment 5
2022-06-22 16:11:32 PDT
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!
mitz
Comment 6
2022-06-22 16:27:54 PDT
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.
Ahmad Saleem
Comment 7
2022-06-22 16:33:49 PDT
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>
mitz
Comment 8
2022-06-22 17:18:50 PDT
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.
Ahmad Saleem
Comment 9
2022-06-23 13:21:13 PDT
Adding JSFiddle to make it easier for anyone to test this in future -
https://jsfiddle.net/0Lk8qdhc/
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug