Bug 64108 - [RTL] in-field icons are drawn on the wrong side in RTL text fields
Summary: [RTL] in-field icons are drawn on the wrong side in RTL text fields
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on: 35258 51499 59703 59874 64668
Blocks:
  Show dependency treegraph
 
Reported: 2011-07-07 10:42 PDT by Ryosuke Niwa
Modified: 2023-05-07 04:14 PDT (History)
9 users (show)

See Also:


Attachments
Screenshot with patch (31.63 KB, image/png)
2011-07-12 07:51 PDT, Jeremy Moskovich
no flags Details
Patch (42.65 KB, patch)
2011-07-17 04:48 PDT, Jeremy Moskovich
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ryosuke Niwa 2011-07-07 10:42:04 PDT
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...
Comment 1 Levi Weintraub 2011-07-07 10:45:40 PDT
This was what I was talking about, thanks Ryosuke :)
Comment 2 Xiaomei Ji 2011-07-07 11:34:19 PDT
related chromium bug:
http://code.google.com/p/chromium/issues/detail?id=87045
Comment 3 Jeremy Moskovich 2011-07-10 08:17:44 PDT
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?
Comment 4 Dimitri Glazkov (Google) 2011-07-10 09:02:13 PDT
(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?
Comment 5 Ryosuke Niwa 2011-07-10 12:47:48 PDT
(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.
Comment 6 Ryosuke Niwa 2011-07-10 13:28:07 PDT
(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?
Comment 7 Jeremy Moskovich 2011-07-11 01:56:02 PDT
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;}
Comment 8 Jeremy Moskovich 2011-07-11 03:05:03 PDT
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...
Comment 9 Ryosuke Niwa 2011-07-11 09:19:13 PDT
(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?
Comment 10 Jeremy Moskovich 2011-07-12 07:33:31 PDT
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.
Comment 11 Jeremy Moskovich 2011-07-12 07:51:53 PDT
Created attachment 100485 [details]
Screenshot with patch
Comment 12 Jeremy Moskovich 2011-07-14 07:35:59 PDT
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.
Comment 13 Kent Tamura 2011-07-14 17:59:51 PDT
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().
Comment 14 Jeremy Moskovich 2011-07-17 04:48:26 PDT
Created attachment 101114 [details]
Patch
Comment 15 Jeremy Moskovich 2011-07-17 04:49:07 PDT
Comment on attachment 101114 [details]
Patch

Splitting off to a separate bug.
Comment 16 Jeremy Moskovich 2011-07-17 04:55:21 PDT
Moving Microphone icon issue discussion to 64668 and leaving this as a master bug.
Comment 17 Ahmad Saleem 2023-05-07 04:14:12 PDT
InputFieldSpeechButtonElement <-- It is gone via below:

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

While 'SearchFieldResultsButtonElement' do exist.