179393 - images between two input fields are displayed in the wrong order

Status: VERIFIED WORKSFORME

(Core :: Layout: Text and Fonts, defect)

Description

[Dirk ten Brinke]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021108
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021108

As you can see on http://www.borg-ogc.com/dev.php on the right side of the
screen(right frame) there is a login table by the name of 'access', and within 2
words, 2 input fields and 1 submit button.
Before going any furter I should mention a certain serverside function I wrote.
The texts 'e mail' and 'password' are converted with a function written in php.
Each character in the string 'e mail' and 'password' are converted to small gif
images I made with the corresponding character. This works ok all over the site.

Except the converted word 'password' (i can put in any other word if you like).
As you might have noticed already, the images are displayed as 'drowssap' and
thus displayed in the wrong order!

Just concluded the following: This only happens when the 'dir="rtl"' tag is
added to BOTH of the input fields, then the images between them are displayed
RightToLeft too, and not just the input fields. If I turn of any of the
'dir="rtl"' then all is just fine.

So I figure the Mozilla code should stop his RTL feature sooner ;-)


Reproducible: Always

Steps to Reproduce:
1. Make a form with two input fields
2. Set BOTH input fields with the dir=rtl attribute
3. Put several images between the two input fields

Actual Results:  
Images are display from right to left.

Expected Results:  
Display images from left to right.

I don't know when and if you will look at http://www.borg-ogc.com/dev.php but
that page is my development page, and thus may change at any time.
If you do and you cannot locate the bug, or the page is gone, or anything, just
mail me at [e-mail] and I will make it happen for you again ASAP.

Comment 1

[Boris Zbarsky [:bzbarsky]]

> 2. Set BOTH input fields with the dir=rtl attribute

This makes BIDI reordering kick in on the images, looks like....  Happens on
Linux as well (linux trunk build 2002-11-01-21).

Comment 2

[Boris Zbarsky [:bzbarsky]]

Attachment: testcase

Comment 3

[Simon Montagu :smontagu]

CSS 2 (http://www.w3.org/TR/REC-CSS2/visuren.html#propdef-unicode-bidi) says:

|In this process, non-textual entities such as images are treated as neutral
|characters, unless their 'unicode-bidi' property has a value other than
|'normal', in which case they are treated as strong characters in the
|'direction' specified for the element

This is not as clearly defined as it might be, as I recently posted to www-style
(http://lists.w3.org/Archives/Public/www-style/2002Oct/0095.html), but certainly
adding a rule like |img { unicode-bidi: embed; }| to Boris' testcase corrects
the rendering.

I think we need more investigation and testcases here.

Comment 4

[Hixie (not reading bugmail)]

I don't see why the test case is considered incorrect behaviour.

Comment 5

[Simon Montagu :smontagu]

If it comes to that, I don't see why the original page uses dir=rtl for input
fields intended for entry of email addresses and passwords.

Dirk, can you explain the reason for this?

Comment 6

[Dirk ten Brinke]

Greetings, I presume this is the correct way to reply to the mailinglist. This
is my first attempt to assist in the BugZilla project.


In reply to #5
The only reason I have for using 'dir="rtl"' is purely typographicly. As you can
see, all the menu options and other texts are aligned to the right. Thus I
figured to use the 'dir="rtl"' attribute to have the input fields right
alignment too.
(feel free to give other solutions)
I can understand your question, I can easely resolve the problem by turning
'dir="rtl"' off. But it's both not relevant to the actualy bug and not according
to my site's design ;-)


In reply to #4
"I don't see why the test case is considered incorrect behaviour."

Please reread the full bug report, original test case URL and submitted test
case. Look and read carefully. I think you have missed the point and moved the
problem on too soon.


In reply to #3
I don't think more test cases are needed. I don't know anything about the actual
Mozilla code, or CSS, or where ever the problem lies.
But it seems clear to me the whatever parses 'dir="rtl"' does not parse it
correctly. It should stick to the input fields, and not ghost in between them.
Maybe it is in some way related to the form tag, or the two input fields are
binded somehow and thus giving anything between the 'dir="rtl"' code too.


Final note
I have no idea what the actual source code of Mozilla looks like or does. But I
am willing to look at it myself to see if I can find anything. Have no clue on
how to do that just yet though. Will look on the Mozilla page for development
source codes and programs et cetera.

Comment 7

[Simon Montagu :smontagu]

If you just want right-aligned text, dir="rtl" is not what you should be using.
That would be suitable for an entry field which is primarily intended for text
in a right-to-left language like Hebrew or Arabic. 

One way to achieve the results you want would be to add the following to your
CSS stylesheet:

.rightalign {
 text-align: right;
}

and then use class="rightalign" instead of dir="rtl".

Comment 8

[Simon Montagu :smontagu]

I am going to mark this WORKSFORME, since the behaviour was triggered by using
dir=rtl with no intention of triggering Bidi reordering. I'm still not 100% sure
that our reordering of lines containing form controls and dir=rtl is correct in
all cases, but we can have that discussion somewhere else (e.g. in bug 150568)

Comment 9

[Dirk ten Brinke]

In reply to #7
Yeah, I just thought of this last night. Was not too sure if it worked with
input fields. Guess it does then.
Will be looking at bug # posted in #8 now.

Thx.

Comment 10

[Hixie (not reading bugmail)]

VERIFIED

Comment 11

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

Attachment: screen dump relating to rendering of "non-textual entities" - difference between Firefox and IE

(In reply to comment #3)
> CSS 2 (http://www.w3.org/TR/REC-CSS2/visuren.html#propdef-unicode-bidi) says:
> 
> |In this process, non-textual entities such as images are treated as neutral
> |characters, unless their 'unicode-bidi' property has a value other than
> |'normal', in which case they are treated as strong characters in the
> |'direction' specified for the element

Sorry for posting this here. It was the first report I found about "non-textual entities".

At http://yi.wikipedia.org/wiki/Image:Redirect_arrow_rtl_without_text.png you will find a testcase where Firefox fails to render to a clickable "download" link but IE succeeds. *note:* IE will create a clickable link but does *not* show the image. See the included screen dump.
Please confirm that it is not possible to click on the link. Please tray to create a simpler testcase because the configuration of the site will change. It might be possible that the source code of the page the url from above is eroneous.

MediaWiki uses a syntax [foo bar] to generate "external links" <a foo>bar <img>protocol</img></a> and adds images beside bar. Displaying images beside bar can be disabeled for the whole wiki. There are neither restictions / assumptions about the LTR / RTL / BiDi directional property of bar nor about these properties at the left nor right.
I see the following requirements:
- bar should be rendered as extra "segment (?)" (neither bidirectional overlapping with characters from left nor from the right)
- if bar consists of LTR characters only then the image should be at the right
- if bar consists of RTL characters only then the image should be at the left
- if bar is BiDi the directional properties for the image object could / should be "inherited" from the left and right context.
For the last case there should be a way to do the following:
[span/class dir="inherit"] [segment start]bar[/segment] <space> [image] [/span/class].

More url's are available at
http://test.leuksman.com/index.php?title=FiverAlpha:Bugzilla/mozilla/00179393&oldid=10711

http://test.leuksman.com/index.php?title=714&oldid=10707 provides some testcases for foo if foo is a valid protocol (http, https, mailto, irc ...).

If this comment does not make much sense here I would be happy to know if other reports relate to this. Thanks for your efforts in advance.

Best regards reinhardt [[user:gangleri]]

*note* this case is more complicated then
Bugzilla Bug 319331 mailto link generated with BiDi user name and email address gets mangled with timestamp

Comment 12

[Simon Montagu :smontagu]

That might be bug 178991