1286538 - Fix devtools-searchinput-clear position in RTL locales

Status: RESOLVED DUPLICATE of bug 1294486

(DevTools :: Inspector, defect, P3)

Description

[magicp]

Attachment: fix-devtools-searchinput-clear-position-in-rtl-locales.png

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20160712030234

Steps to reproduce:

1. Start Nightly in RTL locales (e.g. Arabic)
2. Go to any sites (e.g. about:home)
3. Open DevTools > Inspector > Rules (or Computed)
4. Type any words in devtools-filterinput


Actual results:

devtools-searchinput-clear position is wrong. devtools-searchinput-clear overlaps filter icon.


Expected results:

Don't overlap devtools-searchinput-clear over filter icon in RTL locales

Comment 1

[magicp]

Regression range:
https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=de45c37454922316fb452f90b11f3b24ef6956dc&tochange=54bf7536f7006f279889b0abf9ab7deeb532e63c

Comment 2

[Patrick Brosset <:pbro>]

Pretty easy one to fix, and it will be a nice use of the new CSS logical properties [1].
The button is absolutely positioned using 'right', which of course is always going to be on the right side, in LTR and RTL.
Instead, we can use the 'offset-inline-end'.

[1] https://developer.mozilla.org/fr/docs/Web/CSS/CSS_Logical_Properties

Comment 3

[Rahul Bhattacharjee]

Hello Patrick,

I would like to work in this bug can you please help me get started.

Comment 4

[Patrick Brosset <:pbro>]

(In reply to Rahul Bhattacharjee from comment #3)
> I would like to work in this bug can you please help me get started.
Thanks for wanting to fix this!
I see you're new to bugzilla, so here are some pointers to get started:
- Please first go through our contribution guide: https://developer.mozilla.org/en-US/docs/Tools/Contributing
- Once you're comfortable building firefox, making changes and reloading these changes, you'll be able to start working on a fix for this
- To investigate the issue, I recommend using the "Browser Toolbox", as described here: https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox
It will let you inspect the toolbox with another toolbox, this way you will be able to find the text field and check which CSS rules are applied to it, and why is the clear icon on the wrong side.
- Knowing the CSS class that's applied to the clear icon, you can then search for it in the devtools code, and make your change, and then test it.

Note that there are a lot of search boxes in devtools, one in the inspector, one in the rule-view, one in the computed-view, one in the console, in the debugger, and netmonitor (maybe more). They all look the same, but only the one in the rule-view, and in the computed-view actually have this problem.
The one in the console for example works great in RTL locales, the clear icon is on the correct side.

The difference there, is that most of our search boxes are still using XUL markup, which handle this correctly, while other search boxes are in HTML. So we essentially have 2 implementations of this, and we need to fix the HTML one.

I hope this is enough to get started, I'll assign the bug to you. Don't hesitate to let me know if you're blocked or need more help, I can point you to file names directly if you want.

Comment 5

[Rahul Bhattacharjee]

Thanks(In reply to Patrick Brosset <:pbro> from comment #4)
> (In reply to Rahul Bhattacharjee from comment #3)
> > I would like to work in this bug can you please help me get started.
> Thanks for wanting to fix this!
> I see you're new to bugzilla, so here are some pointers to get started:
> - Please first go through our contribution guide:
> https://developer.mozilla.org/en-US/docs/Tools/Contributing
> - Once you're comfortable building firefox, making changes and reloading
> these changes, you'll be able to start working on a fix for this
> - To investigate the issue, I recommend using the "Browser Toolbox", as
> described here:
> https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox
> It will let you inspect the toolbox with another toolbox, this way you will
> be able to find the text field and check which CSS rules are applied to it,
> and why is the clear icon on the wrong side.
> - Knowing the CSS class that's applied to the clear icon, you can then
> search for it in the devtools code, and make your change, and then test it.
> 
> Note that there are a lot of search boxes in devtools, one in the inspector,
> one in the rule-view, one in the computed-view, one in the console, in the
> debugger, and netmonitor (maybe more). They all look the same, but only the
> one in the rule-view, and in the computed-view actually have this problem.
> The one in the console for example works great in RTL locales, the clear
> icon is on the correct side.
> 
> The difference there, is that most of our search boxes are still using XUL
> markup, which handle this correctly, while other search boxes are in HTML.
> So we essentially have 2 implementations of this, and we need to fix the
> HTML one.
> 
> I hope this is enough to get started, I'll assign the bug to you. Don't
> hesitate to let me know if you're blocked or need more help, I can point you
> to file names directly if you want.

Thanks For assigning me this bug. I am setting up the environment, but unfortunately my internet is quite slow, so I will be need time. After I setup up the environment, I will be start working on it.
Thanks again.

Comment 7

[Patrick Brosset <:pbro>]

[good first bug] whiteboard -> keyword mass change

Comment 8

[Sumeet Yadav]

Hello Patrick . I want to work

Comment 9

[Sumeet Yadav]

Hello Patrick . I want to work on this bug and i am  new as a contributor .

Comment 10

[Rahul Bhattacharjee]

(In reply to Sumeet Yadav from comment #9)
> Hello Patrick . I want to work on this bug and i am  new as a contributor .

Hey I am currently working, I was busy since last 1 and half month due to my exams. I am new too so it's taking time for me to build.

Comment 11

[magicp]

On 51.0a1, this bug has already been fixed in Bug 1294486.

Comment 12

[Rahul Bhattacharjee]

Hi, few days back I tried to regenerate the bug but I was unable to do it, then I saw this bug is already fixed. So, would you like to close this bug.

Comment 13

[Patrick Brosset <:pbro>]

Sorry for the delay. Indeed this was fixed by bug 1294486 as magicp said in comment 11. So I'm closing this one as a duplicate now.