1502490 - Setting backgroundColor of input element to white in onkeyup or oninput makes text dissapear

Status: NEW

(Core :: Web Painting, defect, P4)

Description

[christopher.schoelzel]

Attachment: bug_minimal.html

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0

Steps to reproduce:

To reproduce this bug you need an input element with no custom css style that sets it's background color to white in an onkeyup or oninput event.

The smallest example is a document with just the following element in the body (see attachment):

  <input type="text" oninput="this.style.backgroundColor='white'"/>

Steps to reproduce:

1. Click on the input field.
2. Wait a few seconds.
3. Press any key (e.g. "a").

The described behavior does not happen every time, but waiting a few seconds before inputting the first key seems to be a quite reliable way to trigger it.


Actual results:

No text appears in the input field and it remains in the default firefox layout (thin border with blue highlight on hover).

Interestingly, if you use any other color than "white" (or "#fff", or "rgb(255, 255, 255)", ...) - for example "#fefefe" - the element will behave as expected.


Expected results:

The key that was pressed (e.g. "a") should appear in the input field and the layout should change to the default for elements with custom style (inset border, no hover effects).

Possible workaround for developers: Set the background-color to white (or any other color) through any CSS content in the document. The bug only happens with "vanilla" input fields that have no preexisting css style.

Comment 1

[Mats Palmgren (inactive)]

Attachment: Testcase #2

Typing in any of these <input>s seems to work fine for me in Nightly on Linux.

Comment 2

[Mats Palmgren (inactive)]

I can reproduce it in all <input>s in Nightly on OSX though.
Resizing the window makes the <input>s render properly again.
We should probably schedule a reflow for background changes
that affects themeing - I'm guessing we just repaint...

Comment 3

[Mats Palmgren (inactive)]

Actually, it seems a repaint *should* be enough in this case...
If I set "layout.display-list.retain" to false in about:config (and restart)
then the problem does not occur on OSX at least.

Christopher, can you confirm that on Windows too?

Comment 4

[christopher.schoelzel]

Yes, the behavior on Windows (7) is the same as on OSX. Resizing the window makes the previously hidden input appear correctly and the problem does not occur at all when "layout.display-list.retain" is set to false.

Comment 5

[Emilio Cobos Álvarez [:emilio]]

Miko, you might find this one interesting :)

This affects WR + Linux as well, fwiw.