Bug 64108 – [RTL] in-field icons are drawn on the wrong side in RTL text fields

• Status: NEW
• Component: Forms

[Ryosuke Niwa]

When the input element's direction is RTL, icons should be rendered on the opposite side.  e.g. speech icon on the left instead of right, and clear (x) mark on the left instead of right, etc...

[Levi Weintraub]

This was what I was talking about, thanks Ryosuke :)

[Xiaomei Ji]

related chromium bug:
http://code.google.com/p/chromium/issues/detail?id=87045

[Jeremy Moskovich]

The speech decorations are added in TextFieldInputType::createShadowSubtree() .

First the TextControlInnerElement is appended to the container and then the speech element.

A possible fix here would be to add the speech decoration before the TextControlInnerElement in the case of RTL.

dglazkov, tkent: Am I missing anything? Does that sound OK to you?

[Dimitri Glazkov (Google)]

(In reply to comment #3)
> The speech decorations are added in TextFieldInputType::createShadowSubtree() .
> 
> First the TextControlInnerElement is appended to the container and then the speech element.
> 
> A possible fix here would be to add the speech decoration before the TextControlInnerElement in the case of RTL.
> 
> dglazkov, tkent: Am I missing anything? Does that sound OK to you?

direction change is something that's dynamic, right? Would this mean that we'd have to rebuild the shadow tree every time it changes?

[Ryosuke Niwa]

(In reply to comment #4)
> direction change is something that's dynamic, right? Would this mean that we'd have to rebuild the shadow tree every time it changes?

Yes.  Because the text direction can be changed by CSS, it would mean that we'd have to re-order elements after every style-recalc but mutating DOM itself can cause a style-recalc as well.

So I think what we need to do instead is to use some CSS tricks to re-order elements based on the text direction.

[Ryosuke Niwa]

(In reply to comment #5)
> Yes.  Because the text direction can be changed by CSS, it would mean that we'd have to re-order elements after every style-recalc but mutating DOM itself can cause a style-recalc as well.
> 
> So I think what we need to do instead is to use some CSS tricks to re-order elements based on the text direction.

Wait a minute, all these elements are inline so if the shadow root had the same text direction as the shadow host, this would automatically work, no?

[Jeremy Moskovich]

rniwa: yep, in fact if I change html.css to:

input::-webkit-textfield-decoration-container {
    direction: rtl;
...

Then the microphone decoration is placed correctly.

rniwa, dglazkov: Do you have any idea why direction isn't propagated from the input element to the container, even if I add the following to the default style sheet the container direction stays at it's initial value: input[dir=rtl]::-webkit-textfield-decoration-container {direction: rtl;}

[Jeremy Moskovich]

Correction, adding that line to the default stylesheet does fix the issue, now just to move to the correct position when the Microphone Icon is on the left...

[Ryosuke Niwa]

(In reply to comment #8)
> Correction, adding that line to the default stylesheet does fix the issue, now just to move to the correct position when the Microphone Icon is on the left...

Sorry, I don't really understand what you mean here.  Could you clarify?

[Jeremy Moskovich]

rniwa: What I mean is that if I add

input[dir=rtl]::-webkit-textfield-decoration-container {direction: rtl;}

to html.css, this causes the shadow dom container to inherit dir=rtl and correctly orders the field decorations in RTL. e.g. the Microphone icon comes out on the left.

The only problem I'm having with this is that it causes the 'X' to draw on top of the magnifying glass for <input type=search>.  Once I fix that I'll post a patch.

[Jeremy Moskovich]

Created attachment 100485 [details]
Screenshot with patch

[Jeremy Moskovich]

This has something to do with the styling of the results [magnifying glass] button element, if I substitue the speech element [InputFieldSpeechButtonElement instead of a SearchFieldResultsButtonElement] in SearchInputType::createShadowSubtree, everything is drawn correctly.

[Kent Tamura]

Is NSSearchField flipped in RTL environment?
The search field rendering in Mac is very special.  The magnifier location seems to be determined by NSSearchField::searchButtonRectForBounds().

[Jeremy Moskovich]

Created attachment 101114 [details]
Patch

[Jeremy Moskovich]

Comment on attachment 101114 [details]
Patch

Splitting off to a separate bug.

[Jeremy Moskovich]

Moving Microphone icon issue discussion to 64668 and leaving this as a master bug.

[Ahmad Saleem]

InputFieldSpeechButtonElement <-- It is gone via below:

https://github.com/WebKit/WebKit/commit/2b450c7100036302f28fd23a3b5d36bf3d023be2

While 'SearchFieldResultsButtonElement' do exist.