406462 - User interface mangled by BiDi characters in Unicode

Status: RESOLVED FIXED

(Bugzilla :: User Interface, defect)

Description

[lɛʁi לערי ריינהארט]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.3) Gecko/20070427 Firefox/2.0.0.3
Build Identifier: 

« (Show Votes) » is displayed imediatelly after the summary of the corresponding bug.

If that summary contains characters from the Unicode Block "General Punctuation" as the « OVERRIDE » character of the opposite direction the « (Show Votes) » will be displayed in « mirrored » writing.

This could either be avoided by implementing Bug 320273 – BiDi: request for a "BiDi balancing function" to avoid BiDi overlapping between objects

*or*

by moving « (Show Votes) » to a cell (normaly at the right (in LTR languages).


Best regards Reinhardt [[user:Gangleri]]

Reproducible: Always

Steps to Reproduce:
Log in to the http://landfill.bugzilla.org/gangleri/ test installation or create a  bug report with a similar summary.



Bug 320273 – BiDi: request for a "BiDi balancing function" to avoid BiDi overlapping between objects
Unicode Block "General Punctuation"
http://www.fileformat.info/info/unicode/block/general_punctuation/index.htm

http://landfill.bugzilla.org/gangleri/show_bug.cgi?id=3367

Bugzilla – Bug 3367 using a Unicode Character 'RIGHT-TO-LEFT OVERRIDE' - U+202E in bug summary ⇥⇤ using a Unicode Character 'RIGHT-TO-LEFT OVERRIDE' - U+202E in bug summary

Comment 1

[lɛʁi לערי ריינהארט]

Attachment: screen dump mozilla.org · Unicode Character 'RIGHT-TO-LEFT OVERRIDE' - U+203E issue · 02.jpg

my votes after I coted for the bug

Comment 2

[lɛʁi לערי ריינהארט]

Attachment: screen dumps/screen dump mozilla.org · Unicode Character 'RIGHT-TO-LEFT OVERRIDE' - U+203E issue · 03.jpg

my votes when I vote for the bug (before submitting the votes)

Comment 3

[Max Kanat-Alexander]

We supposedly strip all of those characters out of displayed HTML, so I have no idea why this would be happening. Maybe we need to update our regex now that we're using 8-bit strings.

Comment 4

[A. Shimono [:himorin]]

Attachment: upgrade for regex

(In reply to comment #3)
> We supposedly strip all of those characters out of displayed HTML, so I have no
> idea why this would be happening. Maybe we need to update our regex now that
> we're using 8-bit strings.

use attachment diff.

Comment 5

[Marc Schumann [:Wurblzap]]

Comment on attachment 291396 [details] [diff] [review]
upgrade for regex

Fixes the user list at editusers.cgi as far as I can see.

In Unicode mode, the while loop isn't necessary any more, though, and the comment about it should be removed with it. This can be done on check-in, I'd say.

Comment 6

[Max Kanat-Alexander]

We could make that into a [] character class instead of a parens-and-or thing, too, right?

Comment 7

[Frédéric Buclin]

Marc, could you commit this patch as you say there are some things to fix?

Comment 8

[A. Shimono [:himorin]]

(In reply to comment #6)
> We could make that into a [] character class instead of a parens-and-or thing,
> too, right?

ah, yeah.
you can do like this,
> while ($var =~ s/[\x{202a}-\x{202e}]//g) {

Comment 9

[Marc Schumann [:Wurblzap]]

Checking in Bugzilla/Template.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Template.pm,v  <--  Template.pm
new revision: 1.84; previous revision: 1.83
done

Unfortunately, this doesn't fix the display on show_bug at comment titles (and maybe on other places), as seen here on this bug: date and time of affected comments mixed up with the commenter's name.