Input: The 'x' to clear renders incorrectly

[martinkrulltott]

The 'x' that's used to clear an Input renders incorrectly. On mouse leave the very bottom of the x stays on the screen while the rest of the x is hidden. Vice versa can also be seen, where the x is shown but the very bottom is missing. (Tested in Chrome OSX by @martinkrulltott and Chrome Linux / Pop OS by @janhenrikoverland ).

in action
https://user-images.githubusercontent.com/12590483/108480976-e4d93380-7297-11eb-8cd4-057949bcdd8d.mp4

very bottom is missing

regular / expected style

[Mohammer5]

This isn't really a Q/A issue, right?
It's a bug report, you could just create an issue in Jira.

[Birkbjo]

I'm unsure if this is a UI-bug? It's a browser feature when type='search', so it's not something we support.

[martinkrulltott]

I thought we were supposed to support / use it though, @cooper-joe ?

[Birkbjo]

I mean, it's not something that is implemented by us, it doesn't even show up in Firefox. If it's something we want to support, maybe it's something we should implement and control ourselves, so it's consistent across browsers?

[cooper-joe]

I thought we were supposed to support / use it though, @cooper-joe ?

Yes, using type="search" on a ui input is supported and should be used. Different browsers handle this type declaration differently (for example, Firefox not showing a clear control).

The approach right now, aligned with our approach on accessibility, is to not block native browser functionality. This counts as native browser functionality. So the answer to the question, "does ui support this?" is yes.

This issue doesn't block the native browser functionality, so it's not a functional bug. I'd categorise it as a visual bug where ui is not correctly displaying native browser controls.

maybe it's something we should implement and control ourselves, so it's consistent across browsers?

I think we may want to do this eventually, but this is another discussion.

[varl]

Since I cannot mark a nested comment as the answer I'll quote @cooper-joe in a new comment and mark that as the answer.

[varl]

I thought we were supposed to support / use it though, @cooper-joe ?

Yes, using type="search" on a ui input is supported and should be used. Different browsers handle this type declaration differently (for example, Firefox not showing a clear control).

The approach right now, aligned with our approach on accessibility, is to not block native browser functionality. This counts as native browser functionality. So the answer to the question, "does ui support this?" is yes.

This issue doesn't block the native browser functionality, so it's not a functional bug. I'd categorise it as a visual bug where ui is not correctly displaying native browser controls.

maybe it's something we should implement and control ourselves, so it's consistent across browsers?

I think we may want to do this eventually, but this is another discussion.

What @cooper-joe wrote here is correct. We recommend using the native browser functionality here, even though it is not rendered perfectly in every browser on every platform. That is simply not in the current scope because of our resource constraints.

[martinkrulltott]

I'd categorise it as a visual bug where ui is not correctly displaying native browser controls.

If it's a bug it should be raised in JIRA, even though it might be out of scope right now?
I'm not arguing that this is an important thing to fix, but simply ignoring it doesn't seem like the proper solution or "Answer" to this Q&A ticket.

[Mohammer5]

I'd categorise it as a visual bug where ui is not correctly displaying native browser controls.

I wouldn't necessarily say it's a bug of our UI library. It's the browsers that cause the pixel glitch. And - at least right now - we're not planning on overwriting native browser controls.

If it's a bug it should be raised in JIRA, even though it might be out of scope right now?

We could still create a JIRA issue for this, I'm not sure what the right category would be though, as it's not really a bug on our side, we haven't decided on implementing a feature that would replace this and there's no task to be done (cc @varl). To me, the appropriate category would be "discussion", which is the purpose of this GH discussions board.

I'd probably just consider this "done" / "answered": It's the browsers fault, we use the native browser behavior, so the only thing we could do is to file a bug report int he chrome/chromium report system

[martinkrulltott]

I wouldn't necessarily say it's a bug of our UI library. It's the browsers that cause the pixel glitch.

Attached a video below of a native HTML input vs a ui InputField, both with type="search".

Wherever the bug lies, it's not affecting the native input. Regardless though, IMO, a bug is a bug and should be treated as such.

The video is based on the ItemSelector in Analytics, with the addition of a native input.

<input type="search" />
<InputField
   value={searchTerm}
   onChange={({ value }) => setSearchTerm(value)}
   placeholder={i18n.t('Search by data item name')}
   dataTest={`${dataTest}-filter-input-field`}
   dense
   initialFocus
   type={'search'}
/>

native.input.vs.inputfield.mov

[varl]

Yes, the correct course of action would be to report it in JIRA.

The JIRA issue may be closed with "won't fix" as resolution.

The issue might be fixed regardless when peripheral work is done on native form controls.

If a patch that fixes it is submitted in a PR it would get merged. Contributions are welcome.

[Mohammer5]

Ah I didn't understand that it's a bug that's somehow caused by us 👌

[varl]

https://jira.dhis2.org/browse/LIBS-128