No caret appears in an empty <input> if placeholder is defined
Categories
(Core :: Layout: Form Controls, defect, P4)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox78 | --- | fixed |
People
(Reporter: leyyyyy, Assigned: MatsPalmgren_bugz)
References
(Blocks 1 open bug)
Details
(Keywords: parity-chrome, testcase)
Attachments
(3 files)
Screenshot with 'opacity:0.8'
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0
Steps to reproduce:
- Open https://desk.bestr.no/welcome
- Focus username input (for example mouse click)
Actual results:
There is not caret.
Expected results:
Caret should be there.
|
||
Comment 1•5 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
|
Assignee | |
Comment 2•5 years ago
|
||
I can reproduce the bug but data:text/html,<input placeholder=Username> works fine so I suspect the root cause is something in the event handlers on that <input>. A minimal testcase would help understanding the problem.
|
||
Comment 3•5 years ago
|
||
<style>
input::placeholder {
opacity: 1;
background: #fff;
}
</style>
<input type="text" placeholder="Username...">
|
|
||
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
|
|
Assignee | |
Comment 4•5 years ago
|
||
Thanks for the testcase Alice!
This is what I'm seeing on Linux with 'opacity:0.8'. The problem seems to be that we render the frame for the ::placeholder on top of the frame for the value (which I presume paints the caret). Also, it appears the ::placeholder frame is too large since it affects the border.
I wonder if we could simply swap the order of those two child frames...
|
|
Assignee | |
Comment 5•5 years ago
|
||
That seems to fix it...
|
|
Assignee | |
Comment 6•5 years ago
|
||
|
|
Assignee | |
Comment 7•5 years ago
|
||
I spawned off bug 1637804 for the border issue.
|
|
Assignee | |
Updated•5 years ago
|
|
||
Comment 10•5 years ago
|
||
|
||
Comment 11•5 years ago
|
||
| bugherder | ||
Description
•