Closed Bug 322945 Opened 19 years ago Closed 2 years ago

Bidirectional source text with right-to-left characters is displayed garbled

Categories

(Toolkit :: View Source, defect)

Product:
Toolkit
Component:
View Source
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
mozilla1.9.1

People

(Reporter: andreasprilopwww, Unassigned)

References

(
URL
)

Details

(Keywords: helpwanted, testcase, Whiteboard: [Waiting for tree to reopen after FFv3.0 release])

Attachments

(1 file)

Patch
470 bytes, patch
dbaron
: review+
dbaron
: superreview+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.3) Gecko/20040919
Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.3) Gecko/20040919

Mozilla applies the bidirectional algorithm to display the source text
resulting in garbled (messed up) source when the text contains
actual right-to-left characters such as Arabic or Hebrew.


Reproducible: Always

Steps to Reproduce:
1. Go to http://www.unics.uni-hannover.de/nhtcapri/temp/messy.html
2. View page source

Actual Results:  
The lines containing Hebrew characters are displayed garbled.


Expected Results:  
Apply the bidi algorithm only to *segments* of the source
as explained in
http://www.unicode.org/reports/tr9/#HL4
Also seen on Win98:
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060107 SeaMonkey/1.5a

<p title="&#1489;&#1497;&#1514;<"&#1488;&#1500;&#1507;</p> is displayed correctly, but line-breaking it in the source, it is shown wrong: try to line-break between '"' and'>', and it wraps like this:

<p title="&#1489;&#1497;&#1514;<
"&#1488;&#1500;&#1507;</p>

testcase:
view-source:http://www.unics.uni-hannover.de/nhtcapri/temp/messy.html
http://www.unics.uni-hannover.de/nhtcapri/temp/messy.html
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
<p title="&#1489;&#1497;&#1514;">&#1488;&#1500;&#1507;</p> wraps <p title="&#1489;&#1497;&#1514;"
>&#1488;&#1500;&#1507;</p>

As this textarea also shows problems, here latin characters used instead of RTL characters, but testcase seen only on RTL characters:
<p title="RTL">RTL</p>
<p title=""RTL
RTL<</p>
adding 
.attribute-value {unicode-bidi: embed;}
to viewSource.css would solve this.
(In reply to comment #3)
> adding 
> .attribute-value {unicode-bidi: embed;}
> to viewSource.css would solve this.

I added this line to viewsource.css in 
C:\Programme\Gemeinsame Dateien\mozilla.org\GRE\1.8_2006010700\res

reloaded the source view and it was fixed.

Bug also seen in
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20051224 Firefox/1.5
Severity: normal → major
Keywords: helpwanted
OS: Solaris → Other
Hardware: Sun → All
> adding 
> .attribute-value {unicode-bidi: embed;}
> to viewSource.css would solve this.

Where is the file "viewSource.css" located under Solaris?
(For user - not admin)
> adding 
> .attribute-value {unicode-bidi: embed;}
> to viewSource.css would solve this.

I found that I can add this line also to the file userContent.css
and the page source view is now okay.
Thank you!

(In reply to comment #3)
> adding 
> .attribute-value {unicode-bidi: embed;}
to viewSource.css would solve this problem in view-source of navigator.

It doesn't solve the problem in view-source of composer:
in the middle, <" is wrong, should be ">
 
<p title="&#1489;&#1497;&#1514;">&#1488;&#1500;&#1507;</p>

Should another bug filed for this?

Selection is also funny, start at end or start of line and slowly select towards other end. When the first RTL Letter is reached, selection jumps right to the last one, so all of them are selected. Going on, the first is unselected, the next etc. When the last one is unselected, they all get selected again, and selection proceeds normally in the rest of the line.
(In reply to comment #7)
> > adding 
> > .attribute-value {unicode-bidi: embed;}
> > to viewSource.css would solve this.
> 
> I found that I can add this line also to the file userContent.css

Does this also fix the problem seen in Composer?
Ctrl+E opens testcase in Composer, click on <HTML> Source in the footer, or from the View menu -> HTML Source.

>> I found that I can add this line also to the file userContent.css
> 
> Does this also fix the problem seen in Composer?

No. The problem (messy/garbled source) is still present
in Composer.
Composer doesn't use any kind of styling for the source text view. If this bug is fixed, fixing bug 58730 (or its blocker, bug 47040) will automatically make the fix apply to composer.
(In reply to comment #8)
> Selection is also funny, start at end or start of line and slowly select
> towards other end. When the first RTL Letter is reached, selection jumps right
> to the last one, so all of them are selected. Going on, the first is
> unselected, the next etc. When the last one is unselected, they all get
> selected again, and selection proceeds normally in the rest of the line.

This is normal behaviour for selecting bidirectional text. See http://blogs.msdn.com/michkap/archive/2006/01/10/511194.aspx
Attached patch Patch — — Splinter Review 
Well, who can review this change then?
Comment on attachment 208500 [details] [diff] [review]
Patch

Thank you for the patch. I guess you should also patch toolkit/components/viewsource/content/viewSource.css
Hm, i thought the one in toolkit/ is just a addition to the one in layout?
Sorry, my bad.
Attachment #208500 - Flags: review?(dbaron)
Assignee: mrbkap → smontagu
Comment on attachment 208500 [details] [diff] [review]
Patch

r=dbaron, although you probably want the same thing on a whole bunch of other things as well -- I imagine things could get pretty messy with RTL tag names, attribute values, and entity names in XML.
Attachment #208500 - Flags: review?(dbaron) → review+
Attachment #208500 - Flags: superreview?(smontagu)
Comment on attachment 208500 [details] [diff] [review]
Patch

sorry, I'm not a super-reviewer
Attachment #208500 - Flags: superreview?(smontagu)
Assignee: smontagu → mrbkap
OS: Other → All
Version: unspecified → Trunk
Comment on attachment 208500 [details] [diff] [review]
Patch

See your previous comment 17...
Attachment #208500 - Flags: superreview?(dbaron)
Attachment #208500 - Flags: superreview?(dbaron) → superreview+
Assignee: mrbkap → nobody
Component: ViewSource → View Source
Product: Mozilla Application Suite → Firefox
QA Contact: doronr → view.source
Whiteboard: [Waiting for tree to reopen after FFv3.0 release]
Target Milestone: --- → Firefox 3.1
Assignee: nobody → bugzilla
Product: Firefox → Toolkit

The bug assignee didn't login in Bugzilla in the last 7 months.
:Honza, could you have a look please?
For more information, please visit auto_nag documentation.

Assignee: bugzilla → nobody
Flags: needinfo?(odvarko)

I can't reproduce the problem on my machine (Win10) and also the unicode-bidi: embed; CSS prop seeems to be already applied on .attribute-value. So, looks like this has been fixed in the past 17 years.

Closing, but feel free to reopen if you still experience this problem.

Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(odvarko)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: