I'm pretty shocked that I have never heard of the RLO unicode character before this article. Let's see if it works: ppa.emorhCelgooG => ppa.emorhCelgooG
I discovered this as I was writing a paranoid HTML cleanup library and wanted to prevent the attack where a user sticks a text-direction-change character into the page and reverses the whole thing. As we've all just witnessed, that can't happen in a conforming browser.
But when viewing the page as a text stream, yup, it reverses and then never really unsticks. Everything's working as designed!
(Maybe my library should still restore the page flow after all... I never thought of how it could mess up view source. As attacks go, it's weak sauce... but like I said, it's meant to be really, really paranoid.)
Even more intriguing. What exactly were you writing in Haskell that needed a super-paranoid html sanitizer? Yet another web server/blog/cms? Or something way more cooler?
Yet another blog, except not targeted for release or anything, just to run my own site. To replace the Django blog that runs my site. It's sort of my entertaining diversion, you know? Working with my own fresh, clean code base where I can try some ideas out without having to carry around a couple of man-centuries worth of legacy code every time I step at work. The cleansing library doubles as my HTML formatter, too, doing things like ensuring close italic tags and such. The paranoia is half real, half fun exercise.
Good point. It is probably the right thing to do technically, since the source view can't rely on parsing the markup. I think I'd prefer such non-printable characters to be simply escaped though.
This is an interesting page from 2006: http://digitalpbk.blogspot.com/2006/11/fun-with-unicode-and-... and seems to demonstrate to me that Firefox, Opera, and Internet Explorer all will eagerly display the RLO character, and Chrome and Safari will not.
Is Chrome and Safari broken or being responsible? (Are there settings to change the behaviors in any of these browsers...?)
It behaves funny in a very "simple" way. Selections have this little problem where you move your mouse over the visual representation but the selection is in the logical representation.
So say your logical text is this:
ltr LTR.
where the capital letters are RTL chars (whether because they're actually RTL or because of an RLO in the char stream). That is, the above represents the reading order. Visually this would look like this:
ltr RTL.
assuming that this paragraph directionality is left-to-right; a reader reading this text would read the letters in the order 'l', 't', 'r', ' ', n 'L', 'T', 'R' (which if you note matches the logical order, hence the name).
Now say you mouse down between the 't' the 'r' and drag right until your mouse is between the 'R' and the 'T'. Those are your selection endpoints. But the selection happens on the _logical_ text, so what's selected is the 'r', the space, the 'L', and the 'T' (and even in that order). You can see that in the example above; if you mouse down between the two 'o' chars in "elgooG" and drag right to between the two 'o' chars in "Google", then you get exactly this sort of behavior.
Ah, that makes sense. I didn't think that text selection defines end points and everything between the endpoints (in the physical text) is highlighted. So, if you have:
Hi RLO elgooG
^ select ^
I expected (everything between the logical end points selected):
Hi Google
^^^^^^^ (selected)
In other words, I expected text selection to obey RLO character as well.
Nope - selection is on logical text, not on visual text. For tons of "fun" reasons. If you want an afternoon of madness, read the Chrome or WebKit sources relating to BiDi text.
I think you're confusing your logical and physical, or I'm misunderstanding you.
Moving your mouse happens over the physical text and sets the selection endpoints. Then everything that's logically (as opposed to physically) between those endpoints is highlighted. Your "I expected" diagram is showing the text physically between the endpoints, not the text logically between them...
This is really dangerous. Luckily the status bar reveals the real URL. However it's still dangerous when you use a visually trusted address like Gmail:
